OAuth token issued but silently discarded on claude.ai web — Claude Code CLI connects E2E to the same server

### MCP server URL

https://mcp.coconutgestao.com.br

### Where does the issue occur?

When auth finishes and redirects back to Claude.ai

### 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-17 ~00:20 BRT (UTC-3)

### Browser and OS

Chrome on macOS 15 (Darwin 25.5)

### Describe the issue

Our remote MCP server (Streamable HTTP, OAuth 2.1 + DCR + PKCE) connects successfully end-to-end from Claude Code CLI, but fails on claude.ai web. On web, the full OAuth flow runs and the token endpoint returns 200 (a session is created on our auth server), but no authenticated request ever reaches the MCP endpoint afterward — the web client appears to obtain the token and then discard it. The connector ends with "Authorization failed (ofid_…)". The same server and same token shape work from the CLI, which isolates the failure to the web connector's post-token behavior. This looks like the same class as #393 / #240 / #155 ("token=200 then silence").

### Issue details

```shell
Step-by-step comparison of the two clients against the SAME server:

| Step | Claude Code CLI | claude.ai web |
|---|---|---|
| Discovery (protected-resource + AS metadata) | 200 | 200 |
| DCR (client registration) | client created | client created |
| Authorization + consent | ok | ok |
| Token exchange | 200, session created | 200, session created |
| Authenticated call to MCP endpoint (initialize) | ARRIVES, 200, tools listed | NEVER arrives |
| Result | Connected, tools usable | "Authorization failed" (ofid) |

On web, the token IS minted (a new session row is created on each attempt), but our Cloudflare Worker logs show ZERO requests carrying an Authorization header after the token exchange. The web client never calls the MCP endpoint with the token it just received.

Error IDs shown in Claude.ai (multiple attempts):
- ofid_576f475c15bec041
- ofid_f17bc253f20d07ab
- ofid_70a16d8a185d94e9
- ofid_87a4c6b84a98df0a
```

### Expected behavior

After a successful token exchange, the web connector should present the issued access token to the MCP endpoint (initialize/tools) exactly as the Claude Code CLI does, and the connector should finish in a "connected" state with the tools listed. Instead the web client obtains the token and never makes an authenticated request to the server.

### Logs from your server

```shell
Evidence gathered via curl + live Cloudflare Worker logs (wrangler tail):

- Discovery: /.well-known/oauth-protected-resource (RFC 9728) and AS metadata (RFC 8414) both 200, exposing registration_endpoint, authorization_endpoint, token_endpoint, and resource.
- JWKS: publishes an ES256 signing key; the access_token validates against it.
- PKCE: S256 accepted.
- Token: decoded access_token is a valid ES256 JWT; id_token echoes the nonce and carries email; client_id claim present.
- Server accepts the token: when the CLI (or a manual curl) presents the token, initialize returns 200.
- Web attempts: after the token endpoint returns 200, the Worker logs show NO subsequent request with an Authorization header. (Exact timestamps available on request to correlate with the ofids above.)
```

### Additional context

Server stack: Cloudflare Worker (brand URL) -> Supabase Edge Function running @lovable.dev/mcp-js. Auth server: Supabase Auth (GoTrue), ES256 signing keys.

Reproduction:
1. Add https://mcp.coconutgestao.com.br as a custom connector on claude.ai web.
2. Complete OAuth (DCR -> consent -> token). Token endpoint returns 200; auth server creates a session.
3. Connector shows "Authorization failed" (ofid). No authenticated request reaches the MCP endpoint.
4. Configure the SAME URL in Claude Code CLI -> connects, initialize succeeds, tools list returns.

Since the server is provably healthy and a first-party client (CLI) connects with the same token, this appears to be a web-connector-side issue obtaining/forwarding the token to the MCP endpoint. Any guidance on what the web connector expects post-token (e.g., a specific resource/audience requirement the CLI is lenient about) would help.