24 days ago
Workspace: my personal workspace (Hobby plan, single member/Admin). Project: desirable-appreciation.
I'm experiencing a recurring OAuth permission error when Claude's MCP connector tries to access this project: "You don't have the required role (viewer) on this resource." This has happened 4 times so far (September 10, 12, 13, and 15, 2026), each time only resolved by fully disconnecting and reconnecting the Claude integration, then recurring again within 1-3 days.
This doesn't match my actual account configuration: my workspace role is Admin (sole member of a personal workspace). The Claude OAuth app's authorized grant shows workspace:member access scope, applied to "All workspaces" (current and future), authorized about 1 month ago with no changes since. No project-level role override exists; project access is inherited entirely from workspace role.
Given the grant on file is broader than Viewer and hasn't changed, I don't believe this is a permissions issue on my end. I suspect it may be a refresh-token handling issue on the OAuth session (possibly related to refresh token rotation/revocation behavior), but I don't have access to my own OAuth grant history or audit logs to confirm (Hobby plan, 48-hour retention).
Separately, I also have three manually-created personal API tokens named for Claude (Claude2, Claude-API-Access, claude) that may be legacy from an earlier setup, I'm not certain if any of these are still in use or could be conflicting with the OAuth connector.
Could you check the OAuth session/token refresh history for this connection on your end?
3 Replies
24 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 24 days ago
24 days ago
This looks like a token refresh scope regression. A few things to try:
- Delete the legacy tokens — Go to Account → API Tokens and delete Claude2, Claude-API-Access, and claude. Even if unused, they could interfere with OAuth token resolution if the connector is somehow picking them up.
- Revoke and recreate the OAuth grant — In Account → Authorized Apps, revoke Claude's access entirely, then re-authorize. This forces a fresh token set with current scopes.
- Check for project-level overrides — Even though you said none exist, verify in Project Settings → Members that no one (including yourself) has a viewer-only role override at the project level that might be masking the workspace role.
- Clear Claude's MCP cache — If Claude Desktop or the MCP connector caches tokens locally, fully clear its auth state (usually in ~/.claude/ or equivalent) and reconnect.
If it recurs again after all that, it's almost certainly a backend issue with how Railway's OAuth refresh rotates scopes on Hobby plan tokens — and you'd need to escalate to Railway support directly since audit logs are unavailable on your plan.
23 days ago
Thanks for this, really helpful. Revoked and re-authorized the OAuth grant through Claude's connector settings, then ran a fresh test right after and got a clean response across all 4 services, no permission error. Haven't gotten to deleting the three legacy API tokens yet, will do that as a follow-up. Keeping an eye on it since the pattern before was working right after a reset, then breaking again in 1-3 days, will report back either way.
23 days ago
Quick update: went ahead and deleted the three legacy API tokens (Claude2, Claude-API-Access, claude) too. So both fixes are now in place, OAuth re-auth and token cleanup. Still monitoring over the next few days to see if the permission error stays gone.