Custom connector: code delivered to auth_callback, claude.ai never POSTs /token — regression between Jul 18–20, 2026 (server and CDN eliminated)

**Server:** `https://ellenwhiteresearch.com/mcp` — Python MCP SDK 1.28.1 (`mcp` on PyPI),
streamable HTTP, stateless, OAuth authorization server colocated at the same origin.
Metadata at `/.well-known/oauth-authorization-server` (PKCE S256, dynamic client
registration, `client_secret_post`/`client_secret_basic`).

**Symptom:** claude.ai walks the entire flow — 401 on `/mcp` → discovery → dynamic
registration → `/authorize` → user consents → 302 to
`https://claude.ai/api/mcp/auth_callback?code=…&state=…` — and then **never POSTs
`/token`**. The user lands on `settings/connectors?step=end_error`. Retrying
reproduces it exactly. Existing connections die the same way when their access
token expires: the refresh-grant POST also never arrives.

## Timeline (all UTC)

| When | What |
|---|---|
| **Jul 18 2026 14:24** | Last full success: access + refresh issued to client `Claude` (redirect `https://claude.ai/api/mcp/auth_callback`). Same domain, same server code, same SDK version as every failure below. |
| **Jul 20 19:53–19:55** | Three attempts: `POST /mcp` 401 (UA `Claude-User`) → both discovery docs 200 → `POST /register` 201 (UA `python-httpx/0.28.1`) → `GET /authorize` 302 → consent submitted, code issued, 302 to `auth_callback` with `code`+`state`. **No `POST /token` ever arrives.** client_ids registered: `93157f9b-8fa7-43fd-82a1-b2d8bf322f39`, `5b5fb45f-5619-4d76-a460-d7b1684386f9`, `3b42ef45-896c-48c3-961f-391af557d31b`. |
| **Jul 21 00:43–00:45** | Retry after server added RFC 9207 `iss` to the authorization response — identical failure. client_id `034ed114-eeeb-40be-8475-6cda9e9a16d8`. |

## What has been eliminated

- **The server.** The complete flow, replayed externally exactly as claude.ai runs it
(register → authorize → consent → token with PKCE verifier → authenticated MCP
initialize), succeeds end-to-end: `/token` returns 200 with access+refresh, and the
MCP session initializes. Authorization responses carry `code`, `state` (echoed
exactly), and `iss` (byte-matching the metadata issuer).
- **The CDN.** Cloudflare fronts the origin; a full security-events export for the
window shows **zero blocked or challenged requests** attributable to these flows —
no `/token` POST was ever stopped at the edge.
- **Reachability.** claude.ai's own backend demonstrably reaches this origin: its
`POST /mcp` probes and `POST /register` calls (UAs `Claude-User`,
`python-httpx/0.28.1`) arrive and are answered 201/401 seconds before the exchange
should follow.
- **Client type mismatch.** claude.ai registers as a confidential client
(`token_endpoint_auth_method: client_secret_post`, secret issued) — matching the
advertised `token_endpoint_auth_methods_supported`.

Probing `https://claude.ai/api/mcp/auth_callback` with an unknown `state` returns
`307 → /settings/connectors?step=end_error&flow_id=ofid_…` — consistent with the
callback being received and the flow failing inside claude.ai **after** code
delivery and **before** any token request is made.

## Matching public reports

- anthropics/claude-ai-mcp **#215** — "server issues auth code correctly, claude.ai
never calls /token" (closed *not planned*).
- anthropics/claude-ai-mcp **#506** — identical symptom against Entra ID; reporter's
control experiment shows the same server works from ChatGPT's connector flow.

## Ask

Trace connector flows for domain `ellenwhiteresearch.com` at the timestamps above
(the registered client_ids are listed): what does the flow processor log between
receiving `auth_callback?code=…&state=…` and the decision not to call the
registered `token_endpoint`? A regression appears to have landed between
**Jul 18 14:24 UTC** (last success) and **Jul 20 19:53 UTC** (first failure);
nothing changed server-side in that window.