[BUG] Desktop: sessions spawned via spawn_task chips start without external MCP servers (local stdio + claude.ai connectors) until first user message

[SYNTYZE]

Environment

• Claude Desktop app (macOS): 1.11847.5
• Claude Code (Code tab / ccd): 2.1.131
• OS: macOS (Darwin 25.5.0)

Summary

Sessions spawned from background-task chips (created via the mcp__ccd_session__spawn_task tool) start executing their prompt immediately, but none of the externally configured MCP servers are available during this autonomous phase:

• Local stdio servers from claude_desktop_config.json (e.g. a markdown-vault server, firecrawl, playwright)
• claude.ai connectors (e.g. ClickUp, Notion, PubMed)

They are missing from the deferred-tools list entirely: keyword ToolSearch queries (even a plain clickup) return "No matching deferred tools found", and exact select:mcp__<server>__<tool> queries fail as well. Only app-internal MCP servers (ccd_session, ccd_session_mgmt, scheduled-tasks, mcp-registry) and built-in tools are available.

As soon as the user sends their first message into the spawned session, all MCP servers become available on the next turn.

Reproduction

1. In a project with MCP servers configured (local stdio via claude_desktop_config.json and/or claude.ai connectors), have Claude create a background-task chip via spawn_task.
2. Click the chip; the spawned session starts working on its prompt autonomously.
3. The session tries to use an MCP tool (directly or via ToolSearch) → not found, including exact select: queries.
4. Send any user message into the spawned session (a plain "retry" suffices) → on the next turn the same MCP tools resolve and work.

Observed timing (3 spawned sessions, same project, times UTC)

Session	Spawn start	MCP lookups failing	First user message	MCP working
A	07:32:06	07:33–08:18	08:41:23	08:42:59
B	07:32:12	07:32–07:47	08:45:22	08:46:07
C	07:32:15	07:32–07:33	08:45:34	08:46:20

In session A, even select:mcp__<pubmed-connector-id>__search_articles (exact tool names) returned "No matching deferred tools found" 19 minutes after session start, while mcp__ccd_session__mark_chapter (app-internal) worked from the start.

Expected

Spawned sessions should have the same MCP servers available as a normal interactive session in the same project — or at least the same set that scheduled-task sessions get.

Contrast: scheduled tasks are NOT affected

Scheduled-task sessions (also started without any user interaction, same machine, same day) had all external MCP servers available immediately: successful select: ToolSearch + MCP calls within seconds of session start (03:22 and 03:27 UTC runs verified). So this appears specific to the spawn_task session initialization path, not a general headless/non-interactive limitation.

Impact

Spawned sessions silently degrade: they skip or defer MCP-dependent steps (task-tracker updates, knowledge-base lookups) unless the user notices afterwards and manually pokes the session. Since the whole point of spawn_task is fire-and-forget background work, the MCP-dependent parts of those prompts are effectively never executed.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[hollydixon2340]

Independent reproduction with measurements, in case it helps re-open this.

Claude Code Desktop, macOS, v2.1.229. Measured across 684 local session transcripts on one machine by reading each session's deferred_tools_delta records and matching chip-spawned sessions against the recorded prompt of every spawn_task call.

The launch path is the entire variable — same machine, same account, same connectors:

Launch path	Remote connector (Linear) attached at session start
Scheduled task	286 / 291 (98%)
Human-typed / other	649 / 659 (98%)
Chip (spawn_task)	0 / 19 (0%)

This matches the report above that scheduled-task sessions are unaffected: on this host they attach at start 98% of the time, while spawn_task sessions attach never.

The trigger is the next prompt submitted into the session, not elapsed time. In all 13 chip sessions that eventually got the connector, it arrived in the same instant as the first human prompt typed into that session (gap 0 min, 13/13, no exceptions), immediately after the session-restart records. The remaining 6 sessions are simply the ones nobody ever typed into.

Negative control: across those same 13 sessions, 963 tool calls were made before the connector attached and not one of them triggered it. So no retry, no local MCP call and no tool-search sweep can summon the connector from inside the session — the attach appears bound to the prompt-submission path that spawn_task bypasses.

Why this is worse than a cosmetic delay: spawn_task is fire-and-forget, so the session does its entire body of work in the window where the connectors are absent. Four sessions here did 90–152 turns of real work without them, and three finished having silently failed to write back their issue-tracker updates — no error was raised, because no call was ever attempted. The failure is invisible from inside the session: with the tools simply missing, the model concludes the service is down and proceeds from its prompt instead.

Happy to share the measurement script or the per-session breakdown.