MCP OAuth state mismatch on Windows — root cause likely matches closed #17733 (state/redirect_uri omitted from authorize request)

Reopening attention to a closed-as-not-planned bug via a fresh report, since it's still blocking us and #17733 is locked for comments.

Our own report: #78421 (server-side repro against our custom MCP server, cfos — OAuth 2.1 + PKCE + DCR, Windows). Symptom: no browser auto-launches, manually opening the printed auth URL and completing login isn't captured, pasting the redirect URL back does nothing, /mcp permanently shows "✗ not authenticated" with OAuth state mismatch - possible CSRF attack. We confirmed server-side that the client-issued state is passed back through our redirect chain byte-for-byte unmodified, so the mismatch isn't something our server is causing.

Closed issue #17733 (https://github.com/anthropics/claude-code/issues/17733, closed NOT_PLANNED, locked) describes what looks like the exact root cause:

When connecting to a remote MCP server with OAuth, Claude Code fails with "OAuth state mismatch - possible CSRF attack" even though authentication completes successfully. Server logs show Claude Code sends: GET /oauth/authorize?response_type=code&client_id=xxx&code_challenge=xxx Missing: redirect_uri, state But Claude Code validates state on callback, causing the error even when the server returns a valid auth code. Expected: Either send state in the request, or don't validate it on callback.

That matches our symptoms exactly: if the CLI never sent a state in the authorize request, it has nothing valid to compare the callback against, which explains the permanent state-mismatch and the "pasting the link back does nothing" behavior (no correct state was ever recorded to compare to).

We've also seen a related but distinct failure mode on Claude Desktop for custom (non-managed) OAuth connectors — reported separately at #52565 (also closed NOT_PLANNED) — "connected" shown in the UI with no tools ever loading, and no token persistence across restart.

Ask: this is blocking any custom OAuth-gated MCP server from working on Windows, across both CLI and Desktop. Requesting this be reopened/triaged rather than left as not-planned, since #17733's repro steps are still reproducible and the workaround (manually obtaining and pasting a bearer token) isn't viable for non-technical users.