Custom connector fails at token exchange — server issues auth code correctly, claude.ai never calls /token (ofid_f35608ed2b59d7ad)

[pdugan20]

MCP server URL

https://mcp.rewind.rest/mcp

Where does the issue occur?

During OAuth token exchange — server issues authorization code correctly, claude.ai never POSTs to /token.

Transport used

streamable-http

Client registration type

Dynamic Client Registration (DCR) — also tried manual pre-registration via Advanced Settings with identical failure.

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

Not applicable (server does not use SSE)

When did you last reproduce this?

2026-04-22, 8:00 PM PDT

Browser and OS

Chrome on macOS / Claude iOS app

Describe the issue

Custom MCP connector worked reliably via claude.ai web and iOS until approximately April 15, 2026. Since the Connections → Customize UI migration, adding the connector fails with either "Couldn't reach the MCP server" (first attempt) or "Authorization with the MCP server failed" / mcp_token_exchange_failed (after pre-registering a client via Advanced Settings to bypass DCR).

The server is verifiably healthy at every step that we control:

• /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource/mcp return valid JSON
• POST /register returns 201 with a valid client record
• GitHub upstream auth completes end-to-end through our /callback handler
• completeAuthorization() (via @cloudflare/workers-oauth-provider@0.4.0) returns a valid MCP authorization code and we 302-redirect to https://claude.ai/api/mcp/auth_callback?code=…&state=…
• curl -I https://mcp.rewind.rest/mcp returns a 401 with WWW-Authenticate: Bearer realm="OAuth", resource_metadata=… byte-identical in shape to Sentry, Notion, and Linear's working MCP servers

After the 302 redirect to claude.ai's callback, the Worker tail shows zero subsequent requests from claude.ai — no /token call, no /mcp call with a Bearer. The connector UI then displays "Authorization with the MCP server failed."

Either:

1. claude.ai fails to parse / accept the authorization code we returned, or
2. claude.ai silently aborts the OAuth flow before attempting the token exchange.

Either way the failure is on claude.ai's side — our 302 is the last step under our control, it carries a correctly-shaped code + state, and it lands at the claude.ai callback URL we were told to redirect to.

Related / probable duplicates:

• Custom MCP server unreachable after Connections → Customize migration — server confirmed healthy via curl #188 — "Custom MCP server unreachable after Connections → Customize migration" (same timeline)
• [BUG] claude.ai connector completes OAuth flow but never attaches Bearer token to MCP requests #155 — "OAuth completes but authenticated POST arrives without Authorization header" (same category; confirms claude.ai web's post-OAuth behavior is the regression, not server implementations)

Issue details

Reference IDs collected across multiple attempts today:

• `ofid_a0225447065f6c7b`
• `ofid_3656e96b3960e1b5`
• `ofid_8e4ac9fece484c6f`
• `ofid_f35608ed2b59d7ad`

Server-side log from a successful /callback leg, captured immediately before the UI "Authorization with the MCP server failed" error:

```
[callback] code=present state=present
[callback] github exchange ok: id=1837100 login=pdugan20
[callback] allowlist check: github_id=1837100 rewind_user_id=1 allowlist_keys=1837100
[callback] completeAuthorization redirectTo=https://claude.ai/api/mcp/auth_callback?code=&state=
```

After that 302, the Worker tail shows no /token request from claude.ai, only repeated unauth'd /mcp probes returning 401.

Server stack:

• Cloudflare Worker
• `@cloudflare/workers-oauth-provider@0.4.0` (latest published)
• GitHub as upstream identity provider
• All well-known endpoints return valid JSON
• DCR and manual client registration both supported; both tried

Comparison with working listed connectors (byte-identical 401 shape):

```

rewind (broken in claude.ai web)

HTTP/2 401
content-type: application/json
www-authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.rewind.rest/.well-known/oauth-protected-resource/mcp", error="invalid_token"

sentry (working in claude.ai web as a listed connector)

HTTP/2 401
content-type: application/json
www-authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.sentry.dev/.well-known/oauth-protected-resource", error="invalid_token", resource_metadata="https://mcp.sentry.dev/.well-known/oauth-protected-resource/mcp"
```

Desktop stdio transport works perfectly against the same server code; only the claude.ai web/mobile custom connector OAuth flow is affected.

[jamesgebara]

I have the same issue I think:

Couldn't reach the MCP server. You can check the server URL and verify the server is running. If this persists, share this reference with support: ofid_******

[ppreyas]

I have the same issue as well. Error I receive is : Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: "ofid_6a17320851f57800"

Using a custom domain running homeassistant.

[YarivReznik]

+1 — same exact symptom on a custom remote MCP server.

Reference: ofid_140bedbf9c3f6d56
Reproduced: 2026-05-06

What works (verified via CloudFront access logs across the entire month, capturing every request before it reaches the origin):

• Discovery: GET /.well-known/oauth-authorization-server 200 ✓
• DCR: POST /api/mcp/register 201 ✓ (also tested CIMD with https://claude.ai/oauth/mcp-oauth-client-metadata — same failure)
• Authorize: consent page loads, user approves → POST /api/mcp/authorize/approve 200 ✓
• Code minted, browser 302's to https://claude.ai/api/mcp/auth_callback?code=…&state=…

What never happens:

• POST /api/mcp/token — zero requests in any of our logs (CloudFront edge OR origin) across the entire month
• Followed immediately by POST /api/mcp 401 from Claude-User without a Bearer header

Stack: backend behind CloudFront, RS256 JWT signing, AS metadata fully spec-compliant per RFC 8414, protected-resource per RFC 9728 (including the path-based /.well-known/oauth-protected-resource/<resource-path> variant returning correct JSON, mirroring Sentry's pattern), WWW-Authenticate: Bearer realm=…, resource_metadata=… shape byte-identical to Sentry/Linear.

Things tested that did NOT change behavior:

• DCR vs CIMD vs pre-registered client_id
• Including/excluding iss query parameter (RFC 9207)
• state=none fallback when client doesn't send state vs omitting state entirely
• scopes_supported: ["mcp.access"] vs ["claudeai"] (matching the loginov-rocks/Medium example)
• authorization_endpoint path consistency with token_endpoint (both under /api/mcp/* to match HubSpot/Sentry/Linear pattern)
• response_modes_supported: ["query"], registration_endpoint advertised in AS metadata
• Path-based well-known: uploaded oauth-protected-resource/<path> and oauth-authorization-server/<path> returning correct JSON
• A GET /api/mcp/authorize 302 → SPA consent page so all OAuth endpoints share /api/mcp/* prefix
• Different domain: tried adding the connector at a completely separate hostname (different DNS, different cert, same backend) — same ofid_140bedbf9c3f6d56 returned, ruling out any URL-level caching of the failure on our side

The same ofid returned across multiple distinct connector URLs strongly suggests Anthropic's failure tracking is stable per-account regardless of connector instance.

The OAuth flow up to the 302 redirect is correct, observable, and verifiable. Claude simply doesn't initiate the token exchange afterward.

Asking for the same thing as #240's resolution: please check the backend trace for ofid_140bedbf9c3f6d56 and confirm whether /token was attempted.

[pedromadidc]

ofid_d5d5f1e43ddb80c3

[faisalanz]

ofid_73831c4fc745d98e
ofid_21a1efbe079a8d84
ofid_b7cd9b65dec17311

[abgagu]

Same symptom on a self-hosted MCP server behind Cloudflare Access with Managed OAuth (Beta).

Setup

• MCP server: https://mcp.onetoonecf.com/investors (FastMCP, streamable-http)
• Edge: Cloudflare Tunnel → origin (FastMCP)
• Auth: Cloudflare Access Managed OAuth + Google Workspace IdP (DCR enabled, https://claude.ai/api/mcp/auth_callback in allowed redirect URIs)

What works (verified)

• GET /.well-known/oauth-authorization-server → 200, valid Cloudflare-issued metadata
• GET /.well-known/oauth-protected-resource → 200, {"resource":"https://mcp.onetoonecf.com","authorization_servers":["https://onetoonecf.cloudflareaccess.com"]}
• HEAD /investors → 401 with WWW-Authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.onetoonecf.com/.well-known/cloudflare-access-protected-resource/investors" (no redirects)
• IdP Test from Cloudflare returns the correct user identity (email present)
• Browser flow with CF_Authorization cookie reaches the origin successfully (FastMCP responds with the expected JSON-RPC error for missing Accept: text/event-stream)

What fails

• Adding the connector in claude.ai web with URL https://mcp.onetoonecf.com/investors completes the consent screen against Google → redirects to Cloudflare callback → eventually returns to claude.ai → UI shows Authorization with the MCP server failed.
• Tried removing and re-adding the connector to force fresh DCR — same outcome.
• No cross-origin redirect involved at the MCP endpoint (verified with curl -I on both /investors and /investors/, both return 401 from the Access edge directly).

Reference IDs

• ofid_1f2927a7ff02ac31
• ofid_d0d049665aba03c3

Comparison
Same server reportedly works end-to-end with Claude Code CLI per other reports in this issue and #155. We have not yet validated CLI on our side but plan to.

This matches the pattern in this issue: server-side OAuth completes correctly, claude.ai web aborts after the callback without attempting the token exchange.