Multi-account configurations re-trigger OAuth browser tabs on every Claude Code session and sub-agent spawn

[noahlevin]

Setup: four Claude Code MCP servers, each authorized against a different Superhuman/Gmail identity:

• superhuman-mail-noahlevin → noah@noahlevin.com (personal)
• superhuman-mail-seriouspeople → noah@seriouspeople.ai (Serious People LLC)
• superhuman-mail-pvalue → nlevin@pvaluepartners.com (P Value Partners)
• superhuman-mail-modular → noah@modularmarketing.co (Modular Marketing)

All four configured per Superhuman's MCP docs as HTTP transport pointing at https://mcp.mail.superhuman.com/mcp. All four authorize successfully and stay authorized — claude mcp list shows all four ✓ Connected, and parallel tool calls against all four return data without intervention.

Bug: every new Claude Code session — and every sub-agent spawn within a session — opens three browser tabs to a Superhuman login/OAuth screen, despite the tokens being valid. Closing the tabs has no effect on functionality; the next MCP call succeeds. The tabs are pure UX cost. A typical workday produces 50–100+ unsolicited tabs.

Why I'm filing this with Superhuman even though there's an upstream Claude Code bug (anthropics/claude-code#57674):

1. The OAuth handshake is initiated by the server — Superhuman's authorization endpoint is what the tab navigates to. If the server returned 200 / a soft "still valid" response on initial probe instead of redirecting to authorization, the client wouldn't have anything to open.
2. Multi-account is the realistic Business-plan use case. Most paying customers have at least a personal + work Gmail. The MCP add-on is $10/mo on top of $40/mo Business — at $50/user/month, "your second account opens browser tabs all day" is a real product gap.
3. The "three tabs not four" symptom suggests the auth flow is keyed on something coarser than (URL × OAuth identity). Worth a look from your side regardless of the Claude Code fix.

Acknowledgments:

• I understand multi-account isn't officially supported yet — this report is about the behavior when it's set up, since Claude Code allows it and the MCPs work.
• I'm aware Claude Code #57674 tracks the broader "HTTP MCP tokens not loaded at session start" pattern. This issue is the Superhuman-shaped slice of it.

Asks:

1. Confirm whether the server-side OAuth probe / token-validation handshake can be made silent (cached or non-interactive) when a valid token is presented.
2. Flag this with your engineering team as a multi-account roadmap item. The MCP product is excellent — I use it 50+ times a day — but the popup loop makes parallel-account workflows costly.

Environment:

• Claude Code 2.1.145
• macOS Darwin 25.3.0 (arm64)
• Superhuman Business plan with MCP add-on