[FEATURE] MCP OAuth "URL >" prompt should also accept a bare authorization code

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When an MCP server's OAuth loopback redirect can't be reached — Claude Code
over SSH, in a container, or on a remote dev host — Claude Code falls back to:

If the redirect page shows a connection error, paste the URL from your
browser's address bar:
URL >

This prompt accepts only a full callback URL. A bare authorization code is
silently ignored: the handler runs new URL(pasted), which throws on a bare
code, and the surrounding catch returns false. No error, no feedback — the
prompt just sits there, which reads as a broken server rather than a rejected
paste.

The inconsistency is what makes this a trap: account login in the same product
prompts Paste code here if prompted > and takes a bare code. Users who have
done claude /login reasonably expect "the code" to be the thing they copy,
and authorization pages commonly present a code rather than a URL.

Observed on v2.1.237.

Proposed Solution

Accept either form at the same prompt, and rename it to URL or code >.

1. Full callback URL — current behavior, unchanged, including the existing

state comparison that rejects a mismatch as CSRF.

1. Bare authorization code — used only when exactly one OAuth flow is

pending in this process, bound to that flow's stored state and PKCE
code_verifier.

Sketch: attempt new URL(value); if that throws and the value has no scheme
or whitespace, treat it as a code for the single pending flow. If more than
one flow is pending, keep requiring a URL, since there is nothing to bind to.

This does not weaken CSRF protection. state binds a response to the request
that started it; when the user pastes into the process that owns the one
pending flow, that binding is the process itself, and PKCE still prevents code
injection. It is the same trust model /login already relies on.

Alternative Solutions

• Server side: nothing an authorization server can do. We run one, and our

post-consent page originally displayed a bare code for exactly this reason.
It silently failed for every Claude Code user, so we reverted to printing
the whole callback URL. The client is the only place this can be fixed.

• ssh -R port forwarding: requires knowing the ephemeral callback port ahead

of time, so it can't be scripted for general use.

• A device-code style flow (see #69205): a better long-term answer, but far

larger than accepting a code at a prompt that already exists.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

1. Claude Code runs on a remote host over SSH; the browser is on my laptop.
2. I add an HTTP MCP server whose OAuth client uses a loopback redirect_uri.
3. I complete SSO in the laptop browser. The redirect to

http://localhost:<port>/callback cannot reach the remote host, so the
browser shows a connection error — the code was issued successfully.

1. The authorization page shows me the code. I paste it at URL >.
2. Nothing happens. No error. I assume the MCP server is broken.

Pasting the full http://localhost:<port>/callback?code=...&state=... works.
Accepting the code at step 4 would remove the dead end.

Additional Context

Related, not duplicates:

• #29507 — documents the URL paste fallback; this asks to widen what it takes.
• #69205 — remote/headless MCP OAuth generally; this is one small piece of it.
• #69978 — same class of confusion on the account-login side.