Notion MCP OAuth fails with "Invalid redirect_uri for OAuth client"
Description
Authenticating the hosted Notion MCP server (https://mcp.notion.com/mcp) via /mcp in Claude Code fails with an "Invalid redirect_uri for OAuth client" error returned from Notion's OAuth server. Authentication never completes.
Environment
- Claude Code version: 2.1.119 (latest as of filing)
- OS: macOS 15 (Darwin 24.6.0)
- Install:
~/.local/bin/claude - Browsers tried: Brave, Chrome — both fail identically (rules out browser shields / extensions)
Steps to reproduce
claude mcp add --transport http notion https://mcp.notion.com/mcp/mcp→ select Notion → Authenticate- Browser opens the Notion authorize URL
- Complete Notion login → Notion rejects with
Invalid redirect_uri for OAuth clientbefore redirecting back to localhost
Root cause (from Claude Code debug logs)
Claude Code uses a fixed client_id (a claude.ai-hosted client metadata URL) combined with a randomly-picked localhost callback port. Notion's OAuth server validates the submitted redirect_uri against the metadata document's allowlist and rejects because the random localhost port isn't listed.
From ~/Library/Caches/claude-cli-nodejs/<cwd>/mcp-logs-notion/<timestamp>.jsonl:
Authorization URL: https://mcp.notion.com/authorize
?response_type=code
&client_id=https%3A%2F%2Fclaude.ai%2Foauth%2Fclaude-code-client-metadata
&code_challenge=[REDACTED]
&code_challenge_method=S256
&redirect_uri=http%3A%2F%2Flocalhost%3A55564%2Fcallback
&state=[REDACTED]
&resource=https%3A%2F%2Fmcp.notion.com%2Fmcp
The port is randomized per attempt (observed 55564, 60330, etc.). The log also shows "No client info found" immediately prior, suggesting Dynamic Client Registration (RFC 7591) was expected but skipped — the static claude.ai client is being reused instead of registering a fresh one.
Expected behavior
Either:
- (a) Perform DCR against Notion's authorization server to register a fresh client with the current localhost callback, or
- (b) Update the
claude-code-client-metadatadocument'sredirect_uristo include wildcard localhost entries that Notion will accept.
Workarounds tried
- Re-running
/mcp— fails with a new random port each time claude update— already on latest- Different browser (Brave → Chrome) — identical failure, confirms server-side rejection
- Falling back to
@notionhq/notion-mcp-serverwith an internal integration token — blocked for users whose Notion workspace restricts integration creation to owners
Notes
Notion's connector works fine in the Claude Desktop app (different OAuth client / fixed redirect URI), so the issue is specific to the Claude Code CLI's OAuth flow against mcp.notion.com.
4 Comments
Reproduced on Linux (WSL2, Debian) with Claude Code 2.1.119 (I suggest dropping the
platform:macoslabel or addingplatform:linux).A fresh fetch of the client metadata today confirms it declares no ports at all, so Notion's exact-match check can never succeed:
The metadata has
localhost/callback(no port) while the runtime uses ephemeral ports (:53092in my case,:55564/:60330above). RFC 8252 §7.3 says the authorization server "MUST allow any port" for loopback redirects, so Notion is non-compliant, but a metadata update on the Claude Code side would unblock users faster than a Notion fix — option (b) in the issue is the pragmatic path.This is a strong connector-auth bug because the report identifies a concrete mismatch between the OAuth client metadata model and the runtime callback strategy. If Claude Code presents a random localhost callback port but the provider validates redirect URIs against a fixed allowlist, authentication is structurally doomed before the user even starts.
That means this is not just "Notion login failed." It is an incompatibility at the OAuth integration boundary between Claude Code’s client behavior and Notion’s redirect_uri validation rules.
The debug-log evidence is especially useful because it isolates the failure to a precise contract mismatch rather than vague browser or extension interference. For users, the practical result is simple: the hosted connector appears supported but cannot actually be authorized.
I just checked again and was able to successfully authenticate. It would appear that there has been a change that resolved this (though I'm not certain what).
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.