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

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

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

  1. 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', ... }
  1. 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-Process on all remaining claude.exe zombies -> 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.

View original on GitHub ↗

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