MCP OAuth regression: client metadata document redirect_uris missing port causes auth failure for providers supporting CIMD

[giampaolocasolla]

Severity: All MCP OAuth providers advertising client_id_metadata_document_supported: true are broken in 2.1.80+

Problem

Starting in 2.1.80, Claude Code sends a portless redirect_uri via the published client metadata document, while the local OAuth callback server listens on a specific port (default 3118). This mismatch causes every provider that supports Client ID Metadata Documents (CIMD) to reject the authorization request with invalid_redirect_uri.

Root cause

In 2.1.80, the MCP OAuth provider class gained a clientMetadataUrl getter that always returns a value (defaults to https://claude.ai/oauth/claude-code-client-metadata). Previously this property was undefined on the class.

This changes the client registration path. The OAuth flow has this logic:

if (client_id_metadata_document_supported && clientMetadataUrl)
    client_id = clientMetadataUrl  // Use metadata document instead of dynamic registration
else
    // Dynamic client registration (sends actual redirect_uris with port)

Before 2.1.80, clientMetadataUrl was undefined, so the flow always fell through to dynamic client registration, which sends the correct redirect_uris including the port (e.g. http://localhost:3118/callback).

Now, when a provider advertises client_id_metadata_document_supported: true, Claude Code uses the published metadata at https://claude.ai/oauth/claude-code-client-metadata. That document contains:

{
  "redirect_uris": [
    "http://localhost/callback",
    "http://127.0.0.1/callback"
  ]
}

These URIs have no port. The actual redirect URI Claude Code constructs is http://localhost:3118/callback. The provider compares the two, they don't match, auth fails.

Reproduction

1. Install Claude Code >= 2.1.80
2. Configure any MCP server whose OAuth discovery metadata includes "client_id_metadata_document_supported": true (e.g. Granola: https://mcp-auth.granola.ai/.well-known/oauth-authorization-server)
3. Attempt to authenticate
4. Browser opens, immediately shows invalid_redirect_uri

Affected providers (confirmed)

• Granola (mcp.granola.ai): advertises client_id_metadata_document_supported: true
• Slack (mcp.slack.com): same error pattern, likely same root cause

Any provider supporting CIMD is affected.

Verification

Confirmed by diffing cli.js between 2.1.79 and 2.1.81. The only relevant change is the addition of get clientMetadataUrl() on the OAuth provider class, which flips the registration path for all CIMD-supporting providers.

Suggested fix

The published client metadata document needs to account for the dynamic port. Options in order of preference:

1. Don't use CIMD when the redirect URI has a non-standard port. If the locally constructed redirect_uri doesn't match any URI in the published metadata, fall back to dynamic client registration.
2. Include the default port in the published metadata. Add http://localhost:3118/callback and http://127.0.0.1:3118/callback to the redirect_uris array at https://claude.ai/oauth/claude-code-client-metadata.
3. Use port 80 (implicit) for the local callback server when CIMD is active. This would match the portless URIs in the metadata but may conflict with other services.

Option 1 is the most robust since it handles custom ports via MCP_OAUTH_CALLBACK_PORT and random port fallback.

Secondary issue

When OAuth fails, Claude Code caches an empty accessToken with expiresAt: 0 in the macOS Keychain. On subsequent sessions it sees this entry and skips the OAuth flow entirely, so the browser never opens again. This was reported separately in #29934 but compounds the problem here: users can't even retry after the regression is fixed without manually clearing the Keychain.

Environment

• Claude Code 2.1.81 (regression introduced in 2.1.80)
• Last working version: 2.1.79
• macOS Darwin 25.3.0

[Koriit]

Not sure if it is related but I'm also failing mcp auth (Slack) on 2.1.74 today (stable).

redirect_uri did not match any configured URIs. Passed URI: http://localhost:3118/callback

[galElmalah]

same here, getting redirect_uri did not match any configured URIs. Passed URI: http://localhost:3118/callback

[orcaman]

Same here

[yurano]

I also reported a similar issue in #37767.

After investigating further, I found that OAuth 2.1 draft (draft-ietf-oauth-v2-1-13), Section 8.4.2 explicitly states:

The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs

This requirement exists because native apps typically use an ephemeral port assigned at runtime.

Additionally, the Model Context Protocol (MCP) Authorization Mechanism is defined as being based on OAuth 2.1:
https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization

Given this, it seems that the root cause of this issue may be that the Authorization Server does not support dynamic loopback ports as required by OAuth 2.1.

In other words, this may not be a client-side bug, but rather a server-side incompatibility with the OAuth 2.1 specification.

[WladmirJunior]

Same here

[rlucioni]

this may not be a client-side bug, but rather a server-side incompatibility with the OAuth 2.1 specification

@yurano this is likely true as far as the ephemeral port goes, but I think the problem is compounded by the use of localhost vs. the loopback IP literal. Also from https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13#section-8.4.2:

While redirect URIs using the name localhost (i.e., http://localhost:{port}/{path}) function similarly to loopback IP redirects, the use of localhost is NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather than localhost avoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user's device.

Some OAuth provider libraries - we use @cloudflare/workers-oauth-provider - interpret this guidance by implementing support for the dynamic port only when the loopback IP literal is used, not localhost: cloudflare/workers-oauth-provider#145.