Windows: CCD session host repeatedly exits killing live background tasks ('torn down with N live background task(s)') — Desktop 1.37937.3 / runtime 2.1.246, filesystem MCP relay flapping
Environment
- Claude Desktop 1.37937.3 (Microsoft Store / MSIX install,
C:\Program Files\WindowsApps\Claude_1.37937.3.0_x64__...) - claude-code runtime 2.1.246 (auto-updated from 2.1.237 today; the old version initially could not be removed — see EPERM below)
- Windows 11 Pro 10.0.26200
- Session type: long-running claude.ai/code conversation hosted by the desktop app, actively using background agents (Agent tool), background shell tasks, and a persistent Monitor.
Symptom
The CCD-managed session host process exits every ~5-15 minutes, killing all live background tasks (subagents, background shells, monitors). Within one hour main.log recorded five of these:
07:46:11 [info] [CCD] Session local_569991b7-... torn down with 1 live background task(s) — settling as stopped (exited)
08:15:41 [info] [CCD] Session local_569991b7-... torn down with 5 live background task(s) — settling as stopped (exited)
08:21:39 [info] [CCD] Session local_569991b7-... torn down with 5 live background task(s) — settling as stopped (exited)
08:27:09 [info] [CCD] Session local_569991b7-... torn down with 3 live background task(s) — settling as stopped (exited)
08:44:20 [info] [CCD] Session local_569991b7-... torn down with 3 live background task(s) — settling as stopped (exited)Each time, the next user message spawns a fresh host process and every background task from the previous host is reported as orphaned ("No completion record was found for background agent ... from the previous session"). Hosts died both while idle-waiting on agents and seconds after active turns, so this is not (only) the WarmLifecycle 900s idle timeout — the log says (exited), i.e. the host process terminated on its own.
Accompanying errors
- Constant flapping of the built-in filesystem MCP relay — dozens per hour, continuing even after a clean app restart:
[error] [LocalMcpServerManager] Failed to connect to filesystem: Connection closed { code: 'CONNECTION_CLOSED', name: 'SdkError', ... }- Broken runtime upgrade left a mixed-version state — old hosts (2.1.237) lingered as zombie processes, blocking cleanup:
08:07:43 [warn] [CCD] Could not remove old version 2.1.237 (in use?): [Error: EPERM: operation not permitted, unlink '...\Claude\claude-code\2.1.237\claude.exe']At one point three generations of session-host processes were alive simultaneously (the conversation kept re-attaching to the newest one while older ones lingered).
What we ruled out / tried
- Not memory pressure: 111 GB free of 128 GB during the failures.
- No OS-level crashes: Application event log has no crash entries for the app; the only reboot was user-initiated.
- Full remediation attempt: complete app quit ->
Stop-Processon all remainingclaude.exezombies -> relaunch. Zombies were cleared and the mixed-version EPERM stopped, but the session-host exits and the filesystem relay flapping continued (next "torn down with 3 live background task(s)" came ~5 minutes after the clean restart).
Impact
Background agents are effectively unusable in the desktop-hosted session: any agent or background shell running longer than a few minutes is killed mid-work, repeatedly. Work survives only because we keep everything checkpointed to disk (git worktrees + receipts) and re-dispatch after every host death — which also burns significant token budget on resume cycles.
Expectation
A session host with live background tasks should not be torn down (or at least should be restarted with task continuity), and the filesystem MCP relay should not crash-loop.
Happy to provide fuller main.log excerpts on request.
3 Comments
Update from the reporter — Council-style adversarial review of our own RCA refined the mechanism. The 'crash-loop' framing was too narrow; the log evidence points to a CCD lifecycle contract bug at query completion:
Session ... query iterator completed, often withStop hook Query completedandCycleHealth healthy cycle ... hadFirstResponse=true— i.e., a healthy, normal end-of-turn, thentorn down with N live background task(s) — settling as stopped (exited).Resuming session4-13s after teardown.Idle timeout reachedfollowed by[CCD] Skipping pause ... 1 active background task(s)— so the idle-lifecycle respects live background tasks, while the query-iterator-completion teardown path does not. Looks like two divergent lifecycle contracts.LocalMcpServerManager ... Connection closed) appears to be a sibling symptom (local stdio child), present before and after teardowns, not the trigger.Repro suggestion: in a Desktop-hosted session, start one long benign background task (sleep loop with a heartbeat file), end the foreground turn, send nothing. Expected per this bug:
query iterator completed→torn down with 1 live background task(s)and the heartbeat stops.Environment note: the desktop app here is the Microsoft Store/MSIX package (1.37937.3), so MSIX PLM/AMSI may amplify, but the iterator-completion correlation is exact across all six events.
Additional root-cause detail for the constant
LocalMcpServerManager Failed to connect to filesystemflapping: the per-server log (Logs\mcp-server-filesystem.log) shows the actual child failure — a classic unquoted path with spaces spawn error (Windows cp866 console message):"C:\Program" is not recognized as an internal or external command, followed byCouldn't start for Cowork and Code sessions. Error: Connection closed { context: 'shared-pool' }repeating dozens of times per hour. Meanwhile the direct chat instance of the same server starts fine viaUsing built-in Node.js for MCP serverand connects successfully — so only the shared-pool spawn path for Cowork/Code sessions is broken. This install is the Microsoft Store/MSIX package living underC:\Program Files\WindowsApps\Claude_1.37937.3.0_x64__...— i.e. the shared-pool spawner appears to build a command line with the unquoted MSIX install path and dies on the first space. That failing shared pool is exactly the relay used by CCD sessions, which likely couples this to the background-task teardowns reported above.Your RCA lines up with what I'd expect from an MSIX install, the unquoted path with spaces in the shared-pool spawner is the kind of thing that only ever bites Windows Store builds. Until it's patched, two workarounds that hold: run long background agents from a plain terminal
claudesession instead of a Desktop-hosted one (that teardown path doesn't exist in the CLI host), and if you need the Desktop UI, the non-MSIX standalone build sidesteps theC:\Programspawn failure entirely. Worth a sweep of%USERPROFILE%\.claude\claude-codefor leftover runtime versions after each auto-update too, the EPERM zombie state comes from two versions fighting over the same exe. oh also, btw, I built a portable Hermes OTG and I run it on USB as my rescue agent; super handy doing quick diagnose & fix, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG