anthropics / anthropics/claude-ai-mcp

"OAuth flow completes but Claude.ai never sends authenticated request to /mcp — recurrence of #136 (July 2026)"

Aperta
#617 1 commento 0 reazioni 0 assegnatari Vedi su GitHub
auth bug server-developer-report
Lingua principale
Nessun dato sulla lingua
Stelle
471
Fork
76
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

### MCP server URL

https://mcp.commongrantapplication.com/mcp

### Where does the issue occur?

Other

### Transport used

streamable-http

### Client registration type

Dynamic Client Registration (DCR)

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026-07-14 (multiple times, ~21:00–22:20 CDT)

### Browser and OS

Browser and OS: Firefox (both normal and private/incognito windows tested), Windows

### Describe the issue

After a fully successful OAuth 2.1 flow (DCR + PKCE S256 + token exchange, all returning correct responses), Claude.ai stops sending any request to our /mcp endpoint. This is a recurrence of #136 — same symptom, same shape, but happening in July 2026, well after that issue was closed.
Notably, the very first attempt after we fixed an unrelated server-side bug did work: initialize was received, authenticated, and handled correctly, and Claude showed the "authorized" state briefly before erroring. Every attempt since — across multiple connector removals/re-adds, a private browsing session with zero cached state, and waits of several minutes between attempts — has completed the full OAuth exchange successfully but never called /mcp again.

### Issue details

```shell
The Claude popup error was: Authorization with cga failed. You can check your credentials and permissions. If this persists, share this reference with support: “ofid_0fa54781e3d0d2b2”
```

### Expected behavior

After the token exchange returns 200 with a valid access_token, Claude.ai should send an authenticated POST request to /mcp with an Authorization: Bearer header, containing an initialize JSON-RPC message — completing the MCP handshake the same way it did on the one attempt that worked, and the same way Claude Code (CLI) reportedly does successfully against other servers per #136's report.
Instead, Claude.ai shows the connector as briefly "authorized" and then immediately falls back to an "authorization failed" / "no MCP server found" error, without ever attempting that request.

### Logs from your server

```shell
# A representative successful OAuth cycle (one of several identical ones):
GET /.well-known/oauth-authorization-server → 200
POST /oauth/register.php (DCR) → 201
GET /oauth/authorize.php → 302 (redirect to consent)
GET /oauth/consent.php → 200
POST /oauth/consent.php → 302
POST /oauth/token.php → 200 (access_token issued,
verified valid: correct aud,
resource, scopes, exp)
--- NO REQUEST TO /mcp ARRIVES AFTER THIS ---

Confirmed via application-level logging inside our /mcp handler (not just web server access logs) that zero requests of any kind hit the endpoint after token issuance — so this isn't a routing or discovery-document issue on our side.
```

### Additional context

One successful /mcp initialize call did occur earlier in testing, confirming the server-side implementation is correct and reachable
Ruled out: DCR rate limiting (confirmed via logs — no 429s), stale browser session/cached consent (reproduced fresh in a private window with no prior cookies), server-side routing gaps (confirmed via app-level request logging showing zero attempts, not failed ones)
Reference IDs: ofid_0fa54781e3d0d2b2
Related: #136, #132, #133, #134

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.