Fix MCP OAuth Regression 'invalid_redirect_uri' Error in Claude Code v2.1.80+ for Providers Supporting Client ID Metadata Documents (CIMD)
Claude Code v2.1.80 introduced a regression where MCP OAuth providers advertising `client_id_metadata_document_supported: true` fail with `invalid_redirect_uri` during authorization. The root cause is a new `clientMetadataUrl` getter that returns a portless redirect_uri (e.g., `https://claude.ai/oauth/claude-code-client-metadata`), while the local OAuth callback server listens on a specific port (default 3118). This mismatch causes all CIMD-supporting providers — including Slack, Gmail, Google Calendar, Atlassian/Jira, Datadog, Linear, Notion, and Sentry MCP connectors — to reject authorization requests. Anthropic staff (localden) confirmed the fix involves adding `application_type: 'native'` to the client metadata document. The affected versions are v2.1.80 through at least v2.1.150; the fix is server-side and does not require a specific npm version upgrade, though re-authenticating after the server fix is necessary.
Symptoms
- MCP OAuth authorization fails with 'invalid_redirect_uri' error when connecting to providers that support Client ID Metadata Documents (CIMD)
- OAuth flow redirects to the provider's authorization page but fails after user consent with 'redirect_uri mismatch'
- All MCP connectors using OAuth with CIMD break simultaneously — Slack, Gmail, Google Calendar, Atlassian/Jira, Datadog, Linear, Notion, Sentry
- Error appears after upgrading Claude Code from v2.1.79 or earlier to v2.1.80 or later
- MCP servers using Dynamic Client Registration (DCR) without CIMD are unaffected
- The authorization callback server on localhost:3118 receives the redirect, but the provider rejects it because the registered redirect_uri in the metadata document lacks the port number
Error signatures
invalid_redirect_uri
redirect_uri mismatch
OAuth authorization failed
client_id_metadata_document_supported
Possible causes
- In Claude Code v2.1.80, the MCP OAuth provider class gained a `clientMetadataUrl` getter that always returns a value (defaulting to `https://claude.ai/oauth/claude-code-client-metadata`). Previously this property was undefined, causing the OAuth flow to use Dynamic Client Registration instead
- The OAuth flow logic checks: `if (client_id_metadata_document_supported && clientMetadataUrl)` — now that `clientMetadataUrl` is always truthy, the flow always uses the metadata document path, bypassing Dynamic Client Registration for CIMD-supporting providers
- The published client metadata document at `https://claude.ai/oauth/claude-code-client-metadata` contains redirect_uris without port numbers (e.g., `http://localhost/callback`), but the local OAuth callback server listens on a specific port (default 3118: `http://localhost:3118/callback`)
- The `application_type` field was missing from the client metadata document, preventing the OAuth provider from recognizing the client as a native application that uses loopback redirects with dynamic ports
- This is a regression — versions before v2.1.80 correctly used Dynamic Client Registration (DCR) for CIMD-supporting providers, which handles dynamic port assignment properly
Solutions
Use Local Port Forwarding to Match the Portless redirect_uri (Advanced Workaround)
Since the metadata document specifies portless redirect_uris (e.g., `http://localhost/callback`), you can configure a local reverse proxy or port forward to map port 80 to the actual callback port 3118. This makes the redirect_uri match what the provider expects.
- Set up a local port forward from port 80 to port 3118: on macOS/Linux use `sudo socat TCP-LISTEN:80,fork TCP:localhost:3118` or configure nginx as a reverse proxy
- Alternatively, change the OAuth callback port in Claude Code settings to 80 if configurable
- Re-initiate the OAuth flow — the provider should now see the redirect going to port 80, matching the metadata document
- Remove the port forward after successful authentication if no longer needed
Commands
sudo socat TCP-LISTEN:80,fork TCP:localhost:3118
curl -s http://localhost/callback -v
Risks
- Requires root/admin privileges to bind to port 80
- Port 80 may conflict with existing web servers on the machine
- Complex setup — only recommended for advanced users who cannot wait for the server-side fix
Verification
- Step 1: Run `sudo socat TCP-LISTEN:80,fork TCP:localhost:3118 &` → expect: process starts in background
- Step 2: Run `curl -s http://localhost/callback` → expect: connection reaches port 3118 application
- Step 3: Initiate MCP OAuth connection → expect: authorization succeeds
Force Dynamic Client Registration by Removing MCP Server from Config and Re-adding (Workaround)
For providers that support Dynamic Client Registration (DCR), you can force the OAuth flow to bypass the client metadata document path by removing the MCP server from your configuration and re-adding it. This triggers a fresh DCR flow that does not rely on the broken metadata document.
- Remove the affected MCP server entry from your Claude Desktop config (claude_desktop_config.json) or Claude Code .mcp.json
- Restart Claude Desktop or Claude Code to clear any cached OAuth state
- Re-add the MCP server configuration — this triggers a fresh OAuth flow
- If the provider supports DCR, the flow should now succeed because it bypasses the metadata document path
Risks
- Only works for providers that support Dynamic Client Registration (DCR) in addition to CIMD
- May not work if the OAuth library still detects CIMD support from the provider's discovery document and routes through the metadata document path
- Temporary workaround — the server-side fix is the permanent resolution
Verification
- Step 1: Remove MCP server from config, restart Claude Code, re-add server → expect: OAuth flow completes without 'invalid_redirect_uri' (for DCR-supporting providers)
Re-authenticate After Server-Side Fix (Official Resolution)
Anthropic staff (localden) confirmed the fix involves adding `application_type: 'native'` to the client metadata document at `https://claude.ai/oauth/claude-code-client-metadata`. This is a server-side change — no npm version upgrade is required. After the server-side fix is deployed, existing OAuth tokens must be refreshed by re-running the MCP connection flow.
- Ensure you are running Claude Code v2.1.80 or later (the regression cannot be fixed by downgrading as the metadata document update is server-side)
- Delete existing OAuth tokens for affected MCP connectors: look for token files in your MCP configuration directory or remove and re-add the MCP server entry in claude_desktop_config.json or .mcp.json
- Re-initiate the OAuth flow for each affected MCP connector — the updated metadata document with `application_type: 'native'` should now allow proper redirect_uri matching
- Verify the OAuth flow completes without 'invalid_redirect_uri' error
Commands
cat https://claude.ai/oauth/claude-code-client-metadata | python3 -m json.tool | grep application_type
Risks
- The server-side fix deployment timeline is controlled by Anthropic — there is no npm version to check for confirmation
- Existing OAuth sessions may need to be manually invalidated before re-authentication works
Verification
- Step 1: Run `curl -s https://claude.ai/oauth/claude-code-client-metadata | python3 -m json.tool` → expect: JSON output containing `"application_type": "native"`
- Step 2: Initiate MCP OAuth connection for any CIMD-supporting provider → expect: authorization flow completes without 'invalid_redirect_uri'
- Step 3: Check that the OAuth callback redirect_uri at localhost:3118 is accepted by the provider → expect: successful token exchange
Agent JSON
Canonical machine-readable representation of this issue:
{
"issue_id": "8fe927e2-656e-40aa-8aab-6a924072a71b",
"slug": "fix-mcp-oauth-regression-invalid-redirect-uri-error-in-claude-code-v2-1-80-for-providers-supporting-client-id-metadata-d-ao4gfz",
"verification_status": "unverified",
"canonical_json": "https://codekb.dev/v1/issues/fix-mcp-oauth-regression-invalid-redirect-uri-error-in-claude-code-v2-1-80-for-providers-supporting-client-id-metadata-d-ao4gfz"
}