claude.ai managed connector (claudeai-proxy) can't be re-attached from CLI — claudeAiOauth never re-minted, no recovery path

Open 💬 1 comment Opened Jun 26, 2026 by gblush

Summary

A claude.ai managed connector (the Claude Design connector, tool namespace mcp__claude_design__*, config type claudeai-proxy) intermittently attaches and then, once dropped, can never be re-attached from the CLI. The bridge OAuth token (claudeAiOauth) is never (re)minted, the feature flag is enabled, the account is logged in, and there is no CLI command or in-app affordance that re-establishes the connector bridge. Restarting the session does nothing because startup only re-reads a config that has no bridge token.

Environment

  • Claude Code 2.1.193 (native install, macOS / darwin)
  • Signed into Anthropic account (subscription)
  • tengu_claudeai_mcp_connectors GrowthBook flag = true

Symptom

The Claude Design managed connector was available in an earlier session (mcp__claude_design__list_projects etc. present), then disconnected mid-session. After that it never re-attaches. The model cannot call it because the tools are absent from the session toolset, and the user cannot restore it.

What I verified in ~/.claude.json (no command surfaces this to the user)

  • tengu_claudeai_mcp_connectors = true (feature enabled)
  • oauthAccount = present (account login OK)
  • claudeAiOauth = ABSENT ← the connector-bridge token; this is the missing piece
  • bridgeOauthDeadFailCount = 1
  • bridgeOauthDeadExpiresAt = a timestamp ~57 days in the past (dead/backoff window long expired, so nothing is actively blocking a retry — yet no retry ever mints the token)

Things that do NOT work (and arguably should, or should be documented)

  1. Restarting the app (any number of times) — startup re-reads a config with no claudeAiOauth; nothing re-triggers the bridge OAuth.
  2. claude mcp login <name> — rejects managed connectors entirely: No MCP server named "claude_design". Configured servers: .... It only resolves configured stdio/HTTP servers, not claudeai-proxy connectors.
  3. claude auth — only login/logout/status for the Anthropic account; no connector path.
  4. claude mcp add-from-claude-desktop — imports stdio servers only; does not carry a claude.ai managed connector. (Configuring the connector in Claude Desktop has no effect on Claude Code, which is itself a confusing footgun.)
  5. /mcp in-session — presents nothing actionable to (re)authenticate the managed connector.

The binary's own user-facing string points to https://claude.ai/customize/connectors, but there is no CLI/in-app way to make Claude Code re-run the bridge OAuth and mint claudeAiOauth once bridgeOauthDeadFailCount has been set, even after the dead window expires.

Expected behavior

At least one of:

  • A CLI command to (re)authenticate claude.ai managed connectors, e.g. claude mcp login accepting claudeai-proxy connector names, or a claude auth connectors / claude mcp reconnect subcommand.
  • Automatic re-attempt of the connector bridge OAuth on startup once bridgeOauthDeadExpiresAt has passed (instead of staying dead indefinitely).
  • An in-session /mcp affordance to reconnect a dropped managed connector.
  • Clear surfacing of connector-bridge auth state (claudeAiOauth present/absent, dead-until time) via claude doctor or claude mcp list, so the failure is diagnosable without hand-inspecting ~/.claude.json.

Impact

Any claude.ai managed connector (Claude Design and others of type claudeai-proxy) becomes permanently unusable in Claude Code after a single bridge-OAuth failure, with no user-facing recovery path. The user did everything reasonable (restart, re-login, configure in Desktop) and none of it is the right lever — the right lever doesn't appear to exist from the CLI.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗