Custom connector with manual OAuth Client ID: Desktop attempts DCR; web intermittently fails after successful token exchange

## Summary

Two related problems with a **custom remote MCP connector** that uses a **manually configured OAuth Client ID** (our authorization server does not support Dynamic Client Registration):

1. **Claude Desktop ignores the stored OAuth Client ID and attempts DCR**, failing with *"Automatic client registration isn't supported by [connector]. Edit the connector and add an OAuth Client ID."* — even though the connector was created on claude.ai web **with** the Client ID filled in Advanced settings, and the same connector completes the OAuth authorize step on web (proving the client ID is stored and sent there).
2. **On claude.ai web, connection intermittently fails *after* a fully successful token exchange.** Server-side logs show `/oauth/authorize` → consent → `POST /oauth/token` **200** (access + refresh token issued), yet Claude shows *"Authorization with the MCP server failed. You can check your credentials and permissions."* and **no authenticated request ever reaches the MCP server** (verified at both the CDN worker in front of it and the origin function logs). With the exact same connector configuration, some attempts succeed and then work perfectly.

## Setup

- Remote MCP server (Streamable HTTP) hosted on Supabase Edge Functions, fronted by a Cloudflare Worker on a custom domain.
- Authorization Server: Supabase Auth (GoTrue) OAuth 2.1 server, same project.
- AS metadata (`/.well-known/oauth-authorization-server/auth/v1`): **no `registration_endpoint`** (DCR unsupported, honestly advertised), `token_endpoint_auth_methods_supported: ["client_secret_basic","client_secret_post","none"]`, `code_challenge_methods_supported: ["S256","plain"]`.
- Client: public, PKCE (S256), no secret. Client ID entered in the custom connector's **Advanced settings → OAuth Client ID** field.
- Protected Resource Metadata (RFC 9728) served by the MCP server; `resource` exactly matches the connector URL; 401 responses carry `WWW-Authenticate: Bearer resource_metadata="…"`.

## Bug 1 — Claude Desktop attempts DCR despite stored Client ID

- Connector created on claude.ai web with OAuth Client ID filled. Web flows reach `/oauth/authorize` with the client ID (server logs confirm).
- Connecting the **same account-level connector from Claude Desktop (macOS)** immediately fails with the DCR-unsupported error.
- Support reference: **ofid_19c7bb0f4f69f5b4**

Expected: Desktop should use the stored OAuth Client ID exactly like web does (or the connect flow should fall back to it when the AS metadata advertises no `registration_endpoint`).

## Bug 2 — Intermittent post-token failure on web (no request reaches the MCP server)

Timeline of one failing attempt (UTC, from our AS logs — all three server-side steps succeed in under 5 seconds):

| time | event | status |
|---|---|---|
| 14:47:42 | `GET /.well-known/oauth-authorization-server` | 200 |
| 14:47:43 | `GET /oauth/authorize` | 302 |
| 14:47:45 | consent auto-approved (prior grant), redirect with code | 200 |
| 14:47:46 | `POST /oauth/token` | **200** (tokens issued) |
| after | *(no request of any kind arrives at the MCP server)* | — |

Claude then shows *"Authorization with the MCP server failed"*. The MCP server itself is reachable and healthy at that moment: the **pre-auth** discovery from Claude minutes earlier (unauthenticated `POST` → 401 + `WWW-Authenticate`, `GET` PRM → 200) traversed fine, and manual probes succeed.

Support references from three failing attempts: **ofid_476cee55a5ee4a1a**, **ofid_ced70a06b9b6261d**, **ofid_bab5c5b60377be84**.

With the same configuration, two attempts succeeded (2026-07-14 03:58 UTC and 14:17 UTC) — both were flows where the user interactively logged in / clicked approve on the consent page; the connector then worked normally (authenticated `POST`s arriving ~3s after token exchange). The failing attempts include both a manual-consent flow and an auto-approved (prior consent) flow, so we could not isolate a clean discriminator — it behaves like a race in the client's post-token connection step.

Happy to provide more logs or run instrumented attempts if helpful — we control both the AS and the MCP server and can correlate timestamps precisely.

## Environment

- claude.ai web (Chrome/Safari, macOS) and Claude Desktop (macOS), Max plan.
- MCP server: Streamable HTTP, TLS via Cloudflare; OAuth per MCP spec 2025-11-25 (PRM + WWW-Authenticate discovery).