claude.ai connectors silently stop being fetched in Code sessions until a manual /login

Status Open
Reported on v2.1.251
Maintainer reply None cached
Activity 0 comments · opened Aug 31, 2026

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 doctor and 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

View original on GitHub ↗