claude.ai connectors silently stop being fetched in Code sessions until a manual /login
Summary
claude.ai-synced MCP connectors (Atlassian, Google Drive, Google Calendar, Zoom, etc.) stop being loaded into Claude Code sessions with no error — claude mcp list and the claude.ai Connectors UI both still show them connected, and they remain live/usable in Claude Desktop chat the entire time. Running /login inside an affected session immediately restores them.
Environment
- Claude Code 2.1.251, macOS (Darwin 24.6.0, arm64)
- Enterprise/managed org account
- No proxy, no custom CA, no managed-settings connector policy in effect (confirmed via
claude doctorand direct proxy checks)
Evidence
Per-connector debug logs at ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-claude-ai-<name>/*.jsonl show the connection sequence working normally when it fires:
Initializing claude.ai proxy transport for server mcpsrv_...
Using claude.ai proxy at https://mcp-proxy.anthropic.com/v1/mcp/mcpsrv_...
Successfully connected (transport: claudeai-proxy) in 1095ms
Connection established with capabilities: {"hasTools":true,...}
The last such log entry for four affected connectors (Atlassian, Google Drive, Google Calendar, Zoom) was 2026-08-25. Every session started since then — across multiple full CLI exits/restarts, confirmed on 2026-08-31 — produced no new log file at all for these connectors. Not a connection failure: the fetch step is simply never attempted.
ToolSearch//mcp in every affected session showed zero mcp__claude_ai_* tools for these connectors during this window, while the same account's connectors stayed fully functional in Claude Desktop chat throughout.
Fix and a new observation
Running /login in an affected session immediately restored all four connectors (69 tools) for that session. Prior reports (#69422, #69417) describe this as needing to be repeated every session. In this case, a subsequent fresh session, with no further /login, loaded the connectors normally — suggesting /login repaired something server-side or in local state rather than being a pure per-session workaround. Not yet confirmed whether this holds after another few days' gap.
Related (all closed/locked, no maintainer fix landed for this symptom)
#69422, #69417, #62643, #51138, #55914, #51736