OAuth never starts on a modern/auto-era connect: the era-negotiation probe hides the auth challenge

[rinormaloku]

Summary

Connecting to an OAuth-protected HTTP server with Protocol Era = Auto or Modern never starts the authorization flow. The same server authorizes fine with Protocol Era = Legacy. The user sees a red toast instead of the OAuth redirect:

Failed to connect to "<server>": Version negotiation probe failed: Interactive auth recovery required

Root cause

Era auto/modern makes the SDK send a server/discover negotiation probe before anything else. Its classifier (probeClassifier.ts in @modelcontextprotocol/client) reports whatever the transport threw as SdkError(ERA_NEGOTIATION_FAILED), keeping the original error at data.cause. That hides both connect-time auth signals this codebase keys off:

• Remote path (web). The backend always runs interceptAuthChallenges: true (core/mcp/remote/node/server.ts), so a 401 becomes AuthChallengeError → auth_challenge → RemoteClientTransport rejects with AuthRecoveryRequiredError (carrying the authorization URL). Wrapped in SdkError, it no longer matches err instanceof AuthRecoveryRequiredError at clients/web/src/App.tsx:2654, and isUnauthorizedError() at :2670 can't see it either (it has no status/code). Also flips connection status to error at core/mcp/inspectorClient.ts:1548, which isConnectAuthRecoveryError exists to prevent.

• Direct path (CLI/TUI). No stored tokens means no authProvider, so no interception, so the SDK surfaces the raw 401 as SdkHttpError. The probe classifier ignores the HTTP status (it only looks for a JSON-RPC error body), verdicts "legacy", and in pin mode rethrows as ERA_NEGOTIATION_FAILED with the 401 discarded entirely — no status, not even a cause:

  SdkError ERA_NEGOTIATION_FAILED — "the server did not offer pinned protocol
  version 2026-07-28 via server/discover (no fallback in pin mode)"
  

Reproduced against a real dual-era OAuth server (401 + WWW-Authenticate: Bearer resource_metadata=… on both initialize and server/discover):

era	error out of client.connect()	recovery matches?
legacy	AuthRecoveryRequiredError	✅ redirect
auto	SdkError / ERA_NEGOTIATION_FAILED	❌ generic toast
modern (pin)	SdkError / ERA_NEGOTIATION_FAILED	❌ generic toast

core/auth/utils.ts:177-181 already anticipates this wrapper shape, but only walks the chain for UnauthorizedError — not for the two typed errors the Inspector's own paths actually produce.

Not related to the 2026-07-28 authorization SEPs (SEP-2468 iss, SEP-837 application_type, SEP-2352 issuer binding, DCR deprecated in favour of CIMD). Era-legacy authorization against the same server works; only the probe wrapper is at fault.

Fix

1. core/auth/challenge.ts: add a cause-chain walker that returns a nested AuthRecoveryRequiredError / AuthChallengeError hidden inside a wrapper error.
2. core/mcp/inspectorClient.ts: unwrap the client.connect() rejection with it, before withDirectAuthRecovery and the outer isConnectAuthRecoveryError check see it. Fixes web, CLI, and TUI in one place — no client-side changes needed.
3. core/mcp/inspectorClient.ts: on the direct path, enable interceptAuthChallenges for era auto/modern even with no stored tokens, so the 401 becomes a typed AuthChallengeError that survives the probe as data.cause instead of being silently reclassified as "not a modern server".

Workaround until then

Connect once with Protocol Era = Legacy, complete OAuth, then switch to Modern and reconnect — with tokens stored the probe carries the Bearer and server/discover succeeds.

Upstream

Worth reporting separately: classifyHttpError should treat HTTP 401/403 on the probe as auth-required rather than as absence of modern evidence, and pin mode should not drop the status.

[cliffhall]

Independent verification against a composable test server

Reproduced this on unfixed v2/main two ways, confirmed the mechanism in the SDK source, then verified PR #1806 fixes both. Summary below for the record.

Repro 1 — live composable server

TestServerHttp with modern: {} (dual-era) + createOAuthTestServerConfig({ requireAuth: true }), so the bearer middleware guards the modern leg and the server/discover probe itself is answered 401. Direct (Node) transport, no stored tokens:

era	connect() rejects with	recoverable?
legacy	SdkHttpError (401)	✅ isConnectAuthRecoveryError → true
auto	SdkHttpError (401, after fallback to legacy)	✅ true
modern	SdkError / ERA_NEGOTIATION_FAILED — 401 discarded entirely: no status, no cause, no data	❌

Note auto passes here. On the direct path with no authProvider it falls back to legacy and the initialize 401 surfaces intact. auto fails on the remote path, which is the reported case.

Repro 2 — the web / remote path (what the report shows)

The remote backend always sets interceptAuthChallenges, so the 401 becomes AuthChallengeError → handleAuthChallenge runs discovery + DCR → RemoteClientTransport rejects with AuthRecoveryRequiredError carrying the authorization URL. Modeling that rejection at the transport boundary:

era	result
legacy	AuthRecoveryRequiredError, status stays disconnected → redirect fires
auto	SdkError / ERA_NEGOTIATION_FAILED, real error at data.cause, isConnectAuthRecoveryError false, status flips to error
modern	same as auto

The wrapper message is byte-for-byte the toast in the report: Version negotiation probe failed: Interactive auth recovery required.

This also explains the reporter's "it completes some of the steps but stops after DCR" precisely. Discovery and registration do run — they happen inside handleAuthChallenge, before the error is thrown. What is lost is the typed error carrying the authorization URL, so nothing ever navigates. The requests in his screenshot are the flow succeeding right up to the point where the result is discarded.

Mechanism, confirmed in the SDK source

In @modelcontextprotocol/client@2.0.0-beta.5 (dist/index.mjs):

1. normalizeReply classifies a probe send rejection as auth-required only for SdkHttpError and UnauthorizedError. Our AuthRecoveryRequiredError / AuthChallengeError fall through to network-error.
2. classifyNetworkError then wraps: new SdkError(EraNegotiationFailed, "Version negotiation probe failed: " + describeError(error), { cause: error }). SdkError's third argument is data, hence the real error lands at err.data.cause rather than err.cause.
3. classifyHttpError parses only a JSON-RPC error body and never reads outcome.status — so a 401 verdicts "legacy" regardless of body shape.
4. Pin mode (protocolEra: "modern") then throws at index.mjs:2670 with no cause argument at all, which is why the modern row above has nothing to recover.

Points 3 and 4 are the upstream bug — tracked in #1807.

Verification of the fix

Applied only the core/ half of PR #1806 (not its tests) and re-ran both repros. Every probing-era case now rejects with the original typed error, connection status stays disconnected, and on the live server auto/modern produce a real AuthRecoveryRequiredError with an authorization URL.

Both halves are load-bearing. The findNestedAuthError unwrap alone does not fix the live direct-path case — with the 401 discarded by pin mode there is nothing in the chain to find. The interceptAuthChallenges change is what puts a typed error there to recover.

Regression check with the patch applied: web 4728 tests / 306 files, TUI 282, CLI 304 — all passing.

Still open on this path

#1808 sits directly downstream: once the redirect fires, a callback with no recorded discovery state dead-ends on AuthorizationServerMismatchError. Anyone verifying #1805 as fixed should expect to land there next.

[cliffhall]

Fixed by #1809 (squash-merged into v2/main). Carries @rinormaloku's original commit from #1806 with authorship preserved, plus the review changes: the era-probe workaround is marked removable (#1807), a satisfied silent auth recovery no longer rejects a connected connect(), and nested silent recoveries are bounded.