claude.ai account connectors don't attach to spawned sessions until the first inbound user message — autonomous background sessions run with no connector tools

Status Open
Reported on v2.1.197
Maintainer reply None cached
Activity 2 comments · opened Aug 4, 2026

Summary

claude.ai account connectors (remote MCP servers connected through claude.ai settings, surfaced in sessions as mcp__<uuid>__<tool> deferred tools) are not attached to a freshly spawned session until the session receives an inbound message (a user message or a background-task notification). A spawned background/"chip" session that begins working autonomously therefore runs its entire first work stretch with no connector tools at all — ToolSearch finds nothing, and the session either improvises without the capability or reports it missing. The moment the user sends any message, the full connector roster appears within seconds.

Local servers from .claude.json / .mcp.json are unaffected (they connect at session start and announce mid-stretch as they come up). The gap is specific to account connectors.

This looks adjacent to the v2.1.221 changelog fix — "Fixed MCP servers from --mcp-config not connecting before first turn in print mode" — but for claude.ai account connectors in interactive/spawned desktop sessions rather than --mcp-config in print mode.

Environment

  • Claude Code 2.1.197 (desktop app, macOS Darwin 25.5.0)
  • ~9 claude.ai account connectors (remote MCP over streamable HTTP + OAuth)
  • Tool search enabled (default)

Reproduction (traced from transcripts, timestamps to the second)

Spawned session (background task created from another session, starts working immediately):

| T+ | Event |
|---|---|
| 0:00 | Session created; begins autonomous work (Bash/Read loop) |
| 11:48 | First ToolSearch for a connector tool → "No matching deferred tools found" |
| 12:06 | MCP health check inside the session lists only local servers — the account connectors are absent from the roster entirely (not deferred — absent) |
| 12–34 min | Two more ToolSearch attempts → nothing; dozens of tool-call boundaries pass with no injection |
| 34:59 | Session finishes its stretch, reporting the connector-dependent step could not be done |
| (idle ~50 min) | |
| user sends first message | Connector tools appear; first ToolSearch resolves them; first real tool call succeeds ~4 s later |

Interactive session (control): all account connectors were injected in one batch at T+17.3 min — the exact timestamp of the first user message to that session (many tool-call boundaries occurred earlier with no injection). A later-added connector was injected at a background-task-notification boundary hours later.

Subagent (control): a subagent spawned from an already-injected session sees the full connector roster instantly — inheritance works; only the fresh-session-before-first-inbound-message window is blind.

Server side (control): the connectors' MCP server logs show zero requests during the blind window — the client never initiates the connection — and the first request after injection completes normally in ~2 s. So this is not a slow or failing handshake; the attach simply doesn't begin until a message boundary.

Expected

Account connectors attach at session start (or at latest before the first assistant turn), the same as configured local/remote servers — especially for spawned background sessions, which may run a long autonomous stretch with no user message by design.

Actual

Connector attachment/injection happens only at inbound-message boundaries. Autonomous spawned sessions run blind until the user happens to message them; agents then either report the capability missing or improvise without it (in our case, a session did substantial work while unable to reach the tools its task required).

Impact

Any workflow that spawns background sessions expecting account-connector tools (MCP-first platforms, task queues, "chip" workflows) silently loses those tools for the whole first work stretch. The failure is invisible: no error, no retry trail — the roster is simply empty. Current workaround: send the spawned session any message immediately after creating it, which triggers injection within seconds.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗