claude.ai-synced connectors require /login every session — never persisted locally

claude.ai-synced connectors require /login on every new session — auth is never persisted locally

Summary

claude.ai-synced (Anthropic-managed org) MCP connectors do not appear at all — in either /mcp or claude mcp list — at the start of every new Claude Code session, even though the account is fully logged in and chat works normally. Running /login makes all of them appear and authorize at once, but they vanish again as soon as a new session starts. A full machine restart does not help.

Note: the connectors are only enumerable from within an already-authenticated session. Running claude mcp list as a child process of a live, logged-in session (e.g. CLAUDECODE=1 / CLAUDE_CODE_SESSION_ID set) does list them, because it inherits that session's brokered state. A cold invocation in a fresh terminal lists nothing. This strongly suggests the connector set is held only in live session/in-memory state and is never persisted to disk.

Investigation shows the connector authorizations are never written to local storage — they appear to be brokered through the account session and held only in memory for the lifetime of that session.

Environment

• Claude Code: 2.1.181
• OS: macOS (Darwin 25.5.0)
• Auth: enterprise / org account (claude.ai-synced connectors, ~28 org-managed: Atlassian, Slack, Box, Datadog, Salesforce, M365, Gmail, etc.)
• Credential storage: macOS Keychain (Claude Code-credentials)

Steps to reproduce

1. Be signed in to an org account that has claude.ai connectors configured (so they sync into Claude Code).
2. Start a fresh Claude Code session.
3. Open /mcp (and/or run claude mcp list in a fresh terminal). → The claude.ai connectors do not appear at all (empty / not listed).
4. Run /login. → All connectors immediately appear and become authenticated/connected in that session.
5. Start a new session (or restart the machine).
6. Open /mcp again. → Connectors have vanished again; must /login to bring them back.

Note: a claude mcp list invoked as a child of the already-authenticated session (with CLAUDECODE=1 / CLAUDE_CODE_SESSION_ID inherited) will list them — that path inherits live session state and does not reflect the cold-start behavior in step 3.

Chat/inference works correctly at every step — only the connectors are affected.

Expected behavior

claude.ai-synced connectors should appear in /mcp (and claude mcp list) and retain their authorization across sessions (or be automatically re-brokered on session startup) the same way directly-added MCP servers do — without requiring a manual /login every session.

Actual behavior

On a new session the connectors do not appear at all in /mcp or claude mcp list, and their authorization is absent — both the listing and the auth are only restored by running /login, and both are lost again on the next session.

Evidence / root-cause investigation

Cold claude mcp list in a fresh terminal (no active session) lists only locally-added servers — every claude.ai-synced connector is absent:

➜ claude mcp list
google-workspace: <local stdio server> - ✔ Connected

(The same command run as a child of a live, logged-in session lists all ~28 connectors — see note above.)

Inspecting the Claude Code-credentials Keychain blob (structure only, no secret values):

- mcpOAuth
  - plugin:<plugin>:atlassian|...   (serverName, serverUrl, accessToken, discoveryState, clientId, redirectUri)
  - plugin:<plugin>:slack|...
  - plugin:<plugin>:box|...
  - plugin:<plugin>:egnyte|...
  - plugin:<plugin>:ms365|...
- claudeAiOauth
  - accessToken, refreshToken, expiresAt, scopes, subscriptionType, rateLimitTier   (valid, not expired)

Findings:

1. claudeAiOauth (account token) is present and valid — consistent with chat working fine.
2. mcpOAuth only contains directly-registered (plugin-defined) MCP servers. Those persist across sessions/restarts as expected.
3. None of the ~28 claude.ai -synced connectors have any entry in mcpOAuth — no tokens, no records, nothing. They are not in the Keychain and not in ~/.claude.json (which contains zero access_token / refresh_token / mcpOAuth / mcpsrv_ strings; its mcpServers block only holds locally-added servers).
4. ~/.claude/mcp-needs-auth-cache.json regenerates each session listing the ~23 unauthenticated connectors. Deleting it does not help — there are no stored tokens to fall back to.
5. A full machine restart does not help (confirms it is not a stale-process/daemon issue).

Conclusion: the claude.ai-synced connectors are authorized in-memory per session (via /login) and that authorization is never persisted, so every new session starts them unauthenticated.

Possibly related (separate) observation

~/.claude/daemon.log also shows the background supervisor's account-token proactive refresh failing intermittently (~once/day), after which it requires interactive re-login:

[supervisor] auth: proactive refresh failed, signalling re-auth required
[supervisor] auth: headless daemon cannot complete OAuth — run `claude auth login` to refresh
[supervisor] auth: no token found, will re-check keychain every 30s
...
[supervisor] auth: token found via keychain re-check   (recovers only after an interactive login)

This appears to be a distinct issue from the connector-persistence bug above (the connector problem occurs even when the account token is valid), but may share an underlying token-handling/refresh path. Noted in case it's relevant.

Workaround

Adding the needed connectors as direct user-scoped MCP servers (bypassing claude.ai sync) causes Claude Code to run the OAuth flow itself and persist the tokens to the mcpOAuth Keychain section, which survives sessions and restarts:

claude mcp add --transport http --scope user <name> <url>

Impact

Users with many org-managed connectors must run /login at the start of every session before any connector is usable, which is disruptive for daily workflows.

Related issues

Appears to be part of the same claude.ai managed-connector brokering cluster, but with a distinct failure mode (connectors absent entirely + never persisted, rather than appearing as stubs):

• #62479 (open) — claude.ai connectors expose only auth stubs in-session despite showing Connected. Closest, but there the connectors do appear; here they do not appear at all until /login.
• #62643 (open) — claude.ai connectors (Gmail etc.) not available in CLI (less detailed).
• #48670 (closed) — mcp-needs-auth-cache.json blocks reconnection. Related, but its 15-min TTL cause is ruled out here since a full restart does not help.
• #58607 (closed) — persist MCP OAuth client registrations/refresh tokens (scoped to self-hosted DCR servers).
• #52565 (closed) — custom connector OAuth fails to persist across restart (reporter notes managed connectors work — inverse of this case).