[BUG] Claude Code MCP client ignores scopes_supported from OAuth protected resource metadata, preventing refresh token issuance

Resolved 💬 21 comments Opened Sep 17, 2025 by phernandez Closed Jun 25, 2026
💡 Likely answer: A maintainer (localden, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code's MCP client fails to include OAuth scopes in authorization requests, even when the MCP server correctly provides scopes_supported in the OAuth protected resource metadata. This results in authorization requests without the offline_access scope, preventing refresh token issuance and causing authentication timeouts every 5 minutes.

What Should Happen?

Expected Behavior:

  1. Claude Code should read scopes_supported from the MCP server's /.well-known/oauth-protected-resource endpoint
  2. Include those scopes in OAuth authorization requests
  3. Receive refresh tokens when offline_access scope is supported
  4. Automatically refresh tokens to maintain persistent authentication

Error Messages/Logs

Debug Logs:
  [DEBUG] MCP server "basic-memory": Fetched OAuth metadata with scope: NONE
  [DEBUG] MCP server "basic-memory": Scopes in URL: NOT FOUND
  [DEBUG] MCP server "basic-memory": No scopes available from URL or metadata
  [DEBUG] MCP server "basic-memory": ERROR: No scopes stored to add to token request!
  [DEBUG] MCP server "basic-memory": Has refresh token: false
  [DEBUG] MCP server "basic-memory": Token expires in: 300

Steps to Reproduce

Actual Behavior:

  1. Claude Code fetches OAuth metadata but logs "Fetched OAuth metadata with scope: NONE"
  2. Authorization URLs are generated without any scope parameter
  3. OAuth authorization requests exclude the offline_access scope
  4. No refresh tokens are issued, causing re-authentication every 5 minutes

Reproduction Steps:

  1. Set up an MCP server with OAuth using WorkOS AuthKit (or similar provider)
  2. Configure the server to return scopes_supported: ["openid", "profile", "email", "offline_access"] in /.well-known/oauth-protected-resource
  3. Connect to the MCP server via Claude Code with debug logging enabled
  4. Observe the authorization URL in debug logs - it will be missing the scope parameter

Correct OAuth Protected Resource Metadata:
{
"resource": "https://mcp.basicmemory.com/mcp",
"authorization_servers": ["https://eloquent-lotus-05.authkit.app/"],
"scopes_supported": ["openid", "profile", "email", "offline_access"],
"bearer_methods_supported": ["header"]
}

Environment:

  • Claude Code version: 1.0.117
  • Platform: macOS (also affects other platforms)
  • MCP server: WorkOS AuthKit with Dynamic Client Registration

Impact:

  • High: Prevents extended MCP usage sessions
  • Users must manually re-authenticate every 5 minutes
  • Makes MCP servers with OAuth authentication practically unusable for development work

Comparison with Other Claude Clients:

  • Claude Desktop, Web, and Mobile handle OAuth refresh tokens correctly with the same MCP server
  • Only Claude Code exhibits this issue, suggesting a client-specific OAuth implementation problem

Technical Details:
The issue appears to be in Claude Code's MCP OAuth client implementation where it's not properly parsing or using the scopes_supported field from the OAuth
protected resource metadata when constructing authorization requests.

Workaround:
None available. Users must manually re-authenticate every 5 minutes.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code v1.0.117

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

PyCharm terminal

Additional Information

_No response_

View original on GitHub ↗

21 Comments

github-actions[bot] · 10 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/4540
  2. https://github.com/anthropics/claude-code/issues/5706
  3. https://github.com/anthropics/claude-code/issues/2527

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

github-actions[bot] · 7 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

cbcoutinho · 7 months ago

This is still an issue

imdirtydan23 · 6 months ago

Still an issue

GLStephen · 6 months ago

Still an issue

s-kris · 5 months ago

still an issue

enesakar · 5 months ago

still an issue

mbarton-mdvip · 4 months ago

still an issue

aron-muon · 4 months ago

This should be a very high priority bug

sccorby · 4 months ago

still an issue

tbuckworth · 3 months ago

Still an issue on v2.1.81 (macOS) — but with a twist: refresh token IS present, just not used across sessions

I'm hitting frequent re-authentication with the official Slack MCP plugin. Every new Claude Code session requires a browser OAuth flow, even though valid tokens exist in the Keychain.

Key finding: unlike the original report where no refresh token was issued, my Keychain entry (Claude Code-credentialsmcpOAuth) does contain both an accessToken and a refreshToken for Slack:

Key: plugin:slack:slack|38801a7d845718b3
  Has accessToken: true
  Has refreshToken: true
  expiresAt: 2026-03-23T22:57:18.867Z
  scope: channels:history,groups:history,im:history,mpim:history,canvases:read,users:read,users:read.email,chat:write,canvases:write,search:read.public,search:read.private,search:read.mpim,search:read.im,search:read.files,search:read.users
  discoveryState.authorizationServerUrl: https://mcp.slack.com

So it seems like Slack's MCP server is now issuing refresh tokens (possibly the scopes issue was fixed on their end), but Claude Code isn't using the refresh token to silently renew the access token on session start. Instead it prompts for a full re-auth.

Environment:

  • Claude Code v2.1.81, macOS (Darwin 25.3.0)
  • Slack MCP plugin v1.0.0 (official marketplace)
  • Token storage: macOS Keychain (Claude Code-credentials)

This suggests the scope of this bug may have shifted — even when offline_access / refresh tokens are available, the MCP OAuth client isn't consuming them correctly on session restart.

dPrad0 · 3 months ago

Still an issue

shigechika · 3 months ago

If you need offline_access or custom scopes that Claude Code doesn't send, mcp-stdio can act as a stdio bridge with its own OAuth 2.1 client. It handles RFC 9728/8414 discovery, PKCE, and token refresh independently from Claude Code.

claude mcp add my-server -- uvx mcp-stdio --oauth --oauth-scope "offline_access" https://your-server/mcp

Tokens are persisted in ~/.mcp-stdio/tokens.json and refreshed automatically on 401, so re-authentication shouldn't be needed until the refresh token itself expires.

yonatan-dvir · 2 months ago

Still an issue

aitkin-dn · 2 months ago

I am really frustrated with this one, we are waiting months for fix for something so simple, in order to use CC in our company with our company MCP - we must support this basic capability of AOuth.
Why is it taking so long to fix it?? other vendors have it, we eventually will give up on Claude Code/Desktop for them, why this isn't fix/prioritized guys?

pantelis-karamolegkos · 2 months ago

Any updates?

arielmoraes · 2 months ago

+1, Still an issue, besides ignoring the Scopes Suppoted, the Authorization Servers are also ignored.

devjerry0 · 2 months ago

Still an issue +1

localden collaborator · 21 days ago

Thank you for taking the time to report this.

We're currently triaging open MCP issues, and this one is being closed in favor of tracking it in #4540, which covers the OAuth client omitting the scope parameter from the authorization request even when scopes_supported is advertised in the protected resource discovery metadata. Please follow that issue for updates and feel free to add any additional context there.

The refresh token consumption behavior raised later in this thread is a separate code path; if you are hitting that specifically, please open a fresh issue so it does not get lost under the scope discussion.