OAuth-based MCP connectors fail inside sbx sandboxes — token never reaches ~/.claude/.credentials.json

Summary

When Claude Code runs inside an sbx sandbox, OAuth authentication for managed remote MCP connectors (any of the claude.ai * entries — Linear, PostHog, Sentry, Supabase, Gmail, Google Drive, Google Calendar, Figma, Notion) appears to succeed in the browser but the token is never persisted inside the sandbox. Every subsequent /mcp call returns:

Authentication successful, but server still requires authentication. You may need to manually restart Claude Code.

Restarting Claude Code does not help. The same flow works from a non-sandboxed Claude Code on the same host.

Filing here because the user-visible failure is in Claude Code; the underlying fix may span Claude Code and the sbx sandbox runtime.

Environment

• Claude Code: 2.1.116
• Sandbox OS: Ubuntu 25.10 (Linux 6.12.44, aarch64)
• Host OS: macOS

Reproduction

1. Inside an sbx sandbox, run claude mcp list — all claude.ai * servers show ! Needs authentication.
2. Run /mcp, pick a server, complete OAuth in the host browser. Browser shows success, CLI prints "Authentication successful, but server still requires authentication."
3. Restart Claude Code.
4. claude mcp list — still Needs authentication.

Evidence

• ~/.claude/.credentials.json mtime is frozen at the start of the session even after multiple OAuth attempts hours later. It contains only the top-level claudeAiOauth entry (a proxy-managed token), never an MCP token.
• ~/.claude/mcp-needs-auth-cache.json is updated and still lists the server as needing auth.
• Network policy is not the cause: **.anthropic.com:443, **.claude.ai:443, and the relevant per-service domains are all allowed, and sbx policy log shows no recent blocks.

Suspected cause

The OAuth callback lands on the host's browser at http://localhost:<port> but the sandboxed Claude Code process listens on the sandbox's localhost — a different network namespace. The callback never reaches the sandboxed process, so the token is never written to .credentials.json. Non-sandboxed Claude Code does not have this separation and works correctly.

Expected

This is likely a cross-component issue (Claude Code + sbx runtime). Either:

• Managed remote MCP OAuth works inside sbx — e.g. sbx auto-publishes the ephemeral OAuth callback port, or Claude Code adopts a proxy-managed MCP token path analogous to the top-level proxy-managed session token, or a device-code / out-of-band OAuth flow is added.
• At minimum, claude mcp list / /mcp should detect the sandboxed state and surface a clear "OAuth MCP not supported in sandboxed sessions" error instead of an infinite "successful but still needs auth" loop.

Related

• #37957 — "Authentication successful, but server still requires authentication" (same message, possibly broader root cause)
• #19481 — /mcp reconnect doesn't refresh OAuth tokens
• #48275 — claude.ai connector disconnect state doesn't sync back