[BUG] Headless session start reports already-authorized claude.ai connectors as requiring authentication; tool calls then succeed

Environment

• Claude Code 2.1.226 (native installer), Linux (Ubuntu 26.04, headless)
• Headless SDK session: claude --print --sdk-url … --input-format stream-json --output-format stream-json (launched by Claude Code Remote Control)
• MCP servers: claude.ai-managed connectors (Vercel, GitHub, Gmail, Google Calendar, Google Drive, Supabase, Claude Code Remote), several authorized in claude.ai connector settings well before the session

Observed

At session start, the injected context states:

The following MCP servers require authentication before their tools can be used: Claude_Code_Remote, Github, Gmail, Google_Calendar, Google_Drive, Supabase, Vercel, claude.ai Microsoft 365 … This session is non-interactive, so Claude cannot run the OAuth flow here. Tell the user that these servers need to be authorized …

Later in the same session, with no authentication action taken by anyone in between:

• mcp__claude_ai_Vercel__list_teams → succeeds (returns the account's team)
• mcp__claude_ai_Github__get_me → succeeds (returns the authenticated login)

So the banner misreported at least two connectors that were fully usable. ~/.claude/mcp-needs-auth-cache.json gained fresh entries for exactly the listed servers, timestamped at session start — the state is recomputed each session, so this is a startup misclassification rather than a stale cache, and clearing the file does not help.

Expected

The session-start needs-auth list reflects actual usability. If startup-time verification is not possible (e.g. token refresh is deferred to first tool call), the message should say the status is unverified rather than instructing the model to tell the user re-authorization is required.

Impact

The banner explicitly instructs the model to tell users these capabilities are unavailable until re-authorized. Agents that trust it report false unavailability and send users to re-run OAuth flows that are already complete. We now carry a standing operating rule to make a live read call before believing the banner, which works but shouldn't be necessary.

Hypothesis

The startup evaluation classifies a connector as needs-auth without attempting a token refresh; the refresh happens lazily on the first tool call, which is why calls succeed while the banner says otherwise.

Related (not duplicates)

#78220, #80635, #80822 cover the needs-auth cache wrongly blocking servers; #82527 covers interactive OAuth completing while the CLI still reports needs-auth. This report is the false-positive banner in headless sessions for claude.ai-managed connectors whose tools work on first call.