[BUG] MCP OAuth on Windows: auth URL surfaced but browser auto-open is silently disabled (CC 2.1.148)

Preflight Checklist

• [x] I have searched existing issues — closely related: #11585 (open, OAuth flow framing), #36307 (closed dup of #11585), #14220 (closed NOT_PLANNED). This issue is filed as a distinct UX/discoverability bug, not a duplicate of #11585's framing.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

MCP OAuth browser auto-open is silently disabled on Windows. The authorization URL is generated and printed to the terminal, but the browser never launches. The only way to authenticate any OAuth-based MCP server is to manually highlight the URL in the terminal, copy it, switch to a browser, paste it, complete OAuth, and come back. There's no in-terminal instruction telling users this is required — first-time users will assume the server is broken.

This is server-agnostic. Hits every OAuth MCP I've tried: Stripe, Bugsnag, Asana, Gmail, Google Drive, Adobe Creative Cloud, Nightwatch, plus several others. Both plugin-style and stdio-style MCP servers exhibit the same behavior.

Environment:

• Claude Code: 2.1.148
• Node.js: v22.13.1
• OS: Windows 11 Pro (Build 10.0.26200.8457)
• Terminals: PowerShell 7.6.1 (native) + Git Bash as fallback

Distinction from #11585 (open since 2025-11-13, still reproduces 6+ months later at CC 2.1.148): in #11585 the symptom is framed as "no browser flow + no tools available — silent failure." In my case, the OAuth flow IS detected and the authorization URL IS surfaced in the terminal, but the browser is never auto-launched. After manual paste, tools work fine. So this isn't "OAuth flow never triggers" — it's "the documented auto-open step doesn't fire on Windows, requiring an undocumented manual paste step every single time."

This matches the debug-log root cause documented by @ctngln in #11585 (comment dated 2026-02-21):

MCP server "X": Authorization URL: https://...
MCP server "X": Redirection handling is disabled, skipping redirect

The auth URL is generated correctly — the redirect step is intentionally skipped, with no user-facing replacement. Community speculation in #11585 is that this is a consequence of the fix for #14220 (auto-launch at CLI startup was annoying users). If so, the fix removed auto-open entirely instead of gating it behind explicit user action.

What Should Happen?

Any one of these would fix it:

1. Restore browser auto-open as opt-in via a config flag (mcp.autoOpenBrowser in ~/.claude.json, or a CLAUDE_MCP_AUTO_OPEN=1 env var). This addresses #14220's original "spurious launch at startup" complaint by requiring explicit user action while restoring the desired flow for everyone else.

1. Add a claude mcp auth <name> command that explicitly triggers the OAuth flow and opens the browser on demand. Discoverable, user-initiated, no surprises at startup.

1. At minimum, print a clearly-formatted blocking prompt when an OAuth MCP needs auth — give users the URL and explicit instructions to paste it into a browser. Currently the URL is buried in init output and there's no guidance at all.

Why This Needs A Fix

• Open and unresolved for 6+ months — #11585 was filed 2025-11-13 against Claude Code 2.0.37. Today (2026-05-22) at Claude Code 2.1.148, the symptom is unchanged. The bug has shipped through many point releases without a fix or documented workaround landing in any changelog.
• Affects every OAuth-based MCP server on Windows (and likely macOS — see @kaalualu's Claude Desktop confirmation in #11585 comment dated 2026-01-19).
• It affects every OAuth-based MCP Anthropic ships first-party (Stripe, GitHub, Slack, Google Drive, Gmail, Asana, etc.). New users hit it on day one with no guidance.
• Tokens expire. This isn't a one-time setup nuisance — it's a repeated friction every time a token refreshes.

Steps to Reproduce

1. Add any OAuth-based MCP server (e.g., claude mcp add stripe ... or install an OAuth-based plugin from the Anthropic marketplace).
2. Restart Claude Code or invoke a tool from that server.
3. Observed: No browser opens. Authorization URL appears in terminal output but with no instruction to copy/paste it. Without prior knowledge of the workaround, users will conclude the server is broken.
4. Expected: Either browser auto-opens, or a clearly-visible blocking prompt directs the user to copy the URL into their browser.

Related Issues

• #11585 (OPEN, canonical) — OAuth flow framing. This issue is the UX/discoverability sibling: URL surfaces, paste works, but auto-open is gone.
• #36307 (CLOSED as duplicate of #11585) — same symptom on macOS, Slack MCP.
• #14220 (CLOSED NOT_PLANNED) — the spurious-startup-launch complaint that likely triggered the current "redirection disabled" behavior.

Is This A Regression?

Likely yes — per #14220 (closed 2026-02-14) and the ctngln debug-log comment in #11585. Auto-browser-open used to work, then was disabled, and no replacement UX was shipped.

Last Working Version

Unknown — sometime before #14220 was closed (2026-02-14).

---

Postscript: the bug bit me while reporting it

I first tried to file this via Claude Code's /feedback command in the terminal. The feedback was accepted internally (Feedback / bug report submitted), and Claude Code then prompted me to "press Enter to add this as a GitHub issue." I pressed Enter — and the browser never opened. Same root cause as the bug I'm reporting. I filed manually via gh issue create instead.

Including this as evidence: the bug is severe enough that it now breaks the in-product path to reporting the bug.