MCP OAuth: stale DCR client registration is reused, authorization fails with "Invalid redirect URI" until credentials are deleted by hand

[xpzouying]

Problem

The OAuth provider persists the DCR client registration (credentials/mcp/<key>-client.json) and reuses it for every subsequent authorization (clientInformation() in packages/agent-core/src/mcp/oauth/provider.ts). When the server side has meanwhile expired or dropped that registration (common for authorization servers that GC dynamic registrations), the next interactive flow builds its authorization URL from the stale client_id/redirect URI and the authorization server rejects it — in our case with "Invalid redirect URI" on the consent page.

Nothing in the client detects this: the flow just fails, and retrying reuses the same stale registration. The only recovery is knowing to delete credentials/mcp/<key>-client.json manually, which no error message suggests.

Suggested direction

When the authorization endpoint (or token exchange) rejects with a registration-related error (invalid_client, redirect-URI mismatch), invalidate the persisted client info (invalidateCredentials('client')) and re-run DCR once before surfacing the failure. Open to other designs — mainly filing this so the failure mode and its manual workaround are on record. Applies to both v1 (mcp/oauth/) and v2 (mcpCore/oauth/).

[xpzouying]

Root cause confirmed, and it is deterministic rather than server-side expiry: startCallbackServer() binds a random free port (oauth/callback-server.ts, listen(0)), while DCR registration records the first flow's port in redirect_uris. Every subsequent interactive flow uses a fresh port, so the authorization endpoint rejects it with "Invalid redirect URI" — reproducible 100% on the second interactive authorization. Deleting the client registration recovers because it forces re-DCR with the new port.

Verified both directions live today: a second interactive authorization against the stored registration failed with exactly this error, and after clearing the stored registration the same flow succeeded on the first try.

Also note the detection gap called out above: the rejection renders in the user's browser at the authorization endpoint — this client only ever observes a callback timeout, so the pending authorization surface stays open until TTL.

Fix I'd propose (PR incoming): before invoking auth() in beginAuthorization, compare the flow's callback URI against the stored registration's redirect_uris; on mismatch, invalidate the stored client registration so auth() re-registers with the current callback URI.