[BUG] Notion connector OAuth fails with "Invalid authorization request"

I would also like to add that this is not a Claude Code-specific issue; the web version has the same problem.
Tool calls to Notion also fail.

I feed the url to Claude, this is what Claude told me:

Short version: Notion's OAuth server claims to support the way Claude identifies itself, then rejects it. The mechanism Before any login happens, the OAuth client has to tell the server who it is via a client_id. There are two ways to get one: DCR (Dynamic Client Registration) — the client POSTs to /register and the server hands back a freshly minted ID like e945Dmxia3YEY9kn. CIMD (Client ID Metadata Document) — newer, no registration call. The client_id is a URL pointing at a JSON document describing itself. Claude uses https://claude.ai/oauth/mcp-oauth-client-metadata, and the server is meant to fetch that URL and read the client's details from it. What breaks Claude Code uses CIMD. Notion's metadata explicitly advertises "client_id_metadata_document_supported": true. But when the CIMD request arrives, Notion returns 400 Invalid authorization request — before checking your account, your login, or your permissions. It never reaches a consent screen. The evidence, from the probes above: - Claude's metadata document resolves fine (HTTP 200) and lists exactly the redirect URI being sent - Every parameter matches what Notion says it accepts — scope=default, S256, response_type=code - Dropping scope and resource changes nothing — still 400 - Swapping in a DCR-issued client_id → HTTP 302, straight into the normal login flow Same server, same endpoint, same redirect, same everything — only the client_id form differs. That isolates it to CIMD handling. Whose bug Notion's, primarily — advertising support for a spec and then rejecting valid requests under it is a server-side contract violation. Anthropic shares it in the sense that Claude Code doesn't fall back to DCR when CIMD fails, which it easily could, since DCR demonstrably works against this exact server. Either side could fix it unilaterally. Neither has yet. Worth noting the public issue reports got the cause wrong, blaming the randomized localhost callback port. That theory is disproven by the 302 above — that authorization used http://localhost:8765/callback, an arbitrary port, and Notion accepted it. The port was a red herring; those users were hitting CIMD too. Nothing here is fixable from your machine, which is why the integration token is the way through — it skips OAuth entirely.

I want to mention that I don’t fully agree with Claude on this. I believe the issue is actually related to the URL and session format change.

Thanks for adding, hope this gets resolved soon

Note that this may be an intermittent issue on Notion's side and may not be Claude native.