[BUG] Desktop (Linux): spawn_task sessions still start without claude_desktop_config.json MCP servers; attach happens on UI focus, tools reach the model only on the next queued turn (re: #67432)

Status Open
Reported on v2.1.260
Maintainer reply None cached
Activity 1 comment · opened Sep 11, 2026

Related: #67432 (closed by inactivity bot), #90061 (in-flight turn ignores MCP pushes)

Environment

  • Claude Desktop 1.49585.0 (Linux, claude-desktop package)
  • Claude Code (Code tab) 2.1.260
  • OS: Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic
  • 7 local stdio MCP servers configured in ~/.config/Claude/claude_desktop_config.json

Summary

This is the bug in #67432, which the inactivity bot closed as not planned on 2026-07-21. It still reproduces, and not only on macOS. A session started from a spawn_task chip begins its first turn with only the app-internal MCP servers. ToolSearch for any configured server returns "No matching deferred tools found".

The desktop logs show where it goes wrong:

  1. For chip-spawned sessions, CCD start-timing reports mcp_count=8/9 (internal servers only). Normally started sessions report mcp_count=15/16.
  2. The configured servers are attached (LocalSessions.replaceEnabledMcpTools + reconcileServers) only when the spawned session is focused in the UI (LocalSessions.setFocusedSession), not when it starts.
  3. Even after that attach, the model gets the deferred_tools_delta only at the next queued user turn. A message steered into the running turn does not carry it.

Evidence (main.log)

| Launch path | mcp_count at init | First replaceEnabledMcpTools after start |
|---|---|---|
| Normal (5 sessions, 09-05 to 09-10) | 15–16 (init_mcp=connected:15/16) | same second to +2 s |
| spawn_task chip A | 9 | +2 min 6 s |
| spawn_task chip B | 9 | +2 s |
| spawn_task chip C | 8 | +37 s (same second as setFocusedSession) |

Session C timeline (UTC, from main.log and the session's transcript .jsonl):

  • 20:18:49 Spawned-task started → session starts; CCD start-timing ... mcp_count=8 ... init_mcp=connected:8/pending:0/failed:0
  • 20:18:50 first-turn deferred_tools_delta: only ccd_directory, ccd_session_mgmt, mcp-registry, scheduled-tasks (plus other internal servers)
  • 20:19:26 setFocusedSession → replaceEnabledMcpTools toolCount=243 → reconcileServers created=[<7 local servers>, ...] total=15
  • 20:19:45 ToolSearch for a configured server → no match
  • 20:20:10 user message steered into the running turn → no deferred_tools_delta attached
  • ~20:20:27 ToolSearch for the same server → "No matching deferred tools found"
  • 20:28:29 next queued user message → deferred_tools_delta adds all 7 local servers; tools work from this turn

The MCP servers themselves were healthy the whole time. They had been connected since 20:07 and answered tools/list in about 200 ms, per mcp-server-<name>.log.

Reproduction

  1. Configure one or more stdio MCP servers in claude_desktop_config.json.
  2. In a Code-tab session, have Claude call spawn_task; click the chip.
  3. In the spawned session's first turn, ToolSearch for a configured server finds nothing.
  4. Focus the session and steer a message into the running turn: still nothing.
  5. After that turn ends, send another message: the tools are available.

Expected

Chip-spawned sessions should attach the same MCP servers at start as normally started or scheduled sessions. At minimum, a delta arriving mid-turn should be delivered with the next steered message or tool result.

Impact

Workflows that depend on an MCP memory server at session start (a mandatory recall in CLAUDE.md) silently skip it in every spawned task. As #67432's comments note, spawning several tasks means visiting each one to kick its tools loose.

View original on GitHub ↗

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