[BUG] 2.1.218 (native build): OAuth MCP servers report "requires authentication" in --print/headless sessions despite valid keychain tokens (regression from 2.1.210)

Summary

After auto-updating to 2.1.218 (the first native-binary npm build — bin/claude.exe replacing cli.js), all OAuth-backed HTTP MCP servers are reported as "requires authentication" in non-interactive --print sessions, even though valid OAuth tokens exist in the macOS Keychain and the same servers work fine in interactive sessions. Rolling back to 2.1.210 fixes it with no other changes.

This silently breaks headless automation that depends on remote MCPs (cron jobs, agent orchestration frameworks that spawn claude --print).

Environment

• macOS 15 (Darwin 25.5.0), Apple Silicon
• Claude Code 2.1.218 via npm install -g @anthropic-ai/claude-code (auto-updater installed it)
• Auth: Claude Max OAuth (keychain Claude Code-credentials), no ANTHROPIC_API_KEY / CLAUDE_CODE_OAUTH_TOKEN
• MCP servers affected: user-scope http servers with OAuth — https://mcp.beehiiv.com/mcp, https://mcp.facebook.com/ads. Header-auth http servers (e.g. GHL) and stdio servers are unaffected.

Repro

1. Configure a user-scope OAuth HTTP MCP server and authenticate it interactively (/mcp); confirm tools work in an interactive session.
2. Run a headless probe:

``bash
claude --print --model haiku --dangerously-skip-permissions \
"Do not use tools. Is MCP server <name> available or does it require authentication?"
``

1. On 2.1.218: the session's system context lists the server under "MCP servers require authentication before their tools can be used" and tools are unavailable. On 2.1.210 (same machine, same keychain, same config): the server connects and tool calls succeed end-to-end.

Evidence it's the version, not the tokens

• claude mcp list / claude mcp get <server> show ✔ Connected on both versions (misleading during diagnosis, incidentally).
• Keychain mcpOAuth entries for both servers had valid accessToken + future expiresAt (one with a working refreshToken) at failure time.
• Model auth (subscription OAuth) works fine in the same headless 2.1.218 sessions — so keychain reads per se succeed; only the MCP OAuth path is affected.
• Reproduced identically from a GUI login shell and from a launchd-spawned context; per-project MCP approval state ruled out (same result from multiple project cwds).
• npm install -g @anthropic-ai/claude-code@2.1.210 → same probe immediately connects and a real MCP tool call succeeds.

Expected

Non-interactive sessions should use stored MCP OAuth tokens (and refresh with a stored refresh token) exactly as ≤2.1.210 did, flagging "requires authentication" only when no usable token exists.

Workaround

Pin 2.1.210 and set DISABLE_AUTOUPDATER=1 for headless spawns.