Windows: background-agent (Cowork VM) sandbox intermittently hangs/closes the whole app, silently killing in-flight background agents

Claude Desktop: background-agent (Cowork VM) sandbox intermittently hangs/closes the whole app, silently killing in-flight background agents

Environment

• Claude Desktop version: 1.24012.1.0 (Windows, x64, WindowsApps package Claude_1.24012.1.0_x64__pzs8sxrjxfjjc)
• OS: Windows 11 Home, build 10.0.26200
• Feature in use: background Agent tool calls (Cowork VM sandbox — Hyper-V/HCS-based), driven from a single long-running Claude Code session

Version history on this machine (may or may not be related, including for context):
| Version | Installed |
|---|---|
| 1.21459.1.0 | 2026-07-15 |
| 1.21459.3.0 | 2026-07-16 |
| 1.24012.0.0 | 2026-07-21 |
| 1.24012.1.0 | 2026-07-21 (current) |

The jump from 1.21459.x to 1.24012.x on 2026-07-21 is a large version-number increase suggesting a significant release, two days before the incidents below became frequent enough to notice.

---

Symptom

While a session has multiple background Agent tool calls in flight (dispatched via the SDK's async-agent mechanism, running inside the Cowork VM sandbox), the mechanism intermittently fails in one of two ways:

1. Detected hang — Windows logs a formal Application Hang (Event ID 1002) for claude.exe, and the whole desktop app is closed by Windows.
2. Silent disconnect — no Windows Error Reporting event is generated at all, but the Cowork VM service's own log shows the client (main app) disconnecting, and all in-flight background agents are killed simultaneously. In one instance, this resulted in the user finding the entire desktop app closed after leaving it running unattended overnight, with zero explanation available from Windows' own crash/hang telemetry.

In-flight background agents lose their ability to report progress/completion when this happens. Filesystem changes an agent already made before the disconnect do persist to disk (verified via git diff in the working repo after each incident), but the agent's live process and conversational state is gone — the controlling session has to SendMessage to the (now-idle) agent id to resume it from its saved transcript, effectively restarting its reasoning from a checkpoint.

Confirmed incident timeline

Windows Application Hang (Event ID 1002) for claude.exe — 3 in the last 30 days:

• 2026-07-09, 02:47:05
• 2026-07-10, 21:46:12
• 2026-07-22, 19:00:44 — coincided with dispatching 11 concurrent background Agent tool calls in one turn (a data-seeding workflow, one subagent per data file). Event detail: "The program claude.exe version 1.24012.1.0 stopped interacting with Windows and was closed." A companion AppHangTransient WER event was logged ~4 minutes earlier (18:56:59).

Cowork VM Service disconnects with no corresponding Windows hang/crash event:

• 2026-07-22, ~21:15-21:16 — C:\ProgramData\Claude\Logs\cowork-service.log shows: Persistent RPC: connection ended: failed to read length: EOF, then Session has no active connections, idle timeout starts, then the service itself restarts. Only 2 concurrent background agents were active at this point (already reduced from the 11-agent dispatch above, specifically to try to avoid a repeat). Both agents were killed.
• 2026-07-23, ~07:37-07:38 — same disconnect signature in the service log, again with 2 concurrent background agents in flight, both killed. This is the incident the user discovered after leaving the machine unattended overnight — the desktop app was found fully closed. Note: the installed app package's own files were rewritten at the same 07:37:38 timestamp, so this specific incident may be confounded with an auto-update cycle rather than being a fourth genuine hang — flagging that ambiguity rather than asserting it's definitely a crash.

Note on the "EOF" log line's reliability as a signal: Persistent RPC: connection ended: failed to read length: EOF also appears in the same log many other times over the preceding ~9 days (July 14 through July 22) under what were, as far as we can tell, completely normal circumstances (the user closing the app normally between sessions). It fires whenever the client disconnects for any reason, so it is not by itself proof of a crash — only the two incidents above are notable because they coincided with live, in-flight background agents being killed.

Suspected trigger

All confirmed hangs/disconnects happened while background Agent tool calls were active in the Cowork VM sandbox:

• The first (2026-07-22 19:00) followed dispatching 11 concurrent background agents in a single turn.
• After reducing to 2 concurrent agents, with a strict "wait for both to fully complete before dispatching the next pair" discipline, disconnects still recurred twice more (21:15 and the next morning at 07:37) — suggesting the failure mode is not purely a function of concurrent-agent count. Possible contributing factors we could not isolate from the client side: cumulative session duration/turnover of many sequentially-dispatched agents over several hours, or a resource leak in the Cowork VM/HCS layer that accumulates across many agent lifecycles rather than being triggered by peak concurrency alone.

Environment checks that rule out obvious external causes

• System memory was not under pressure at the time of the checks performed after each incident (~30% used, tens of GB free).
• No competing virtualization software (VirtualBox, VMware, Docker Desktop) is installed that would conflict with the Hyper-V-based Cowork VM sandbox.
• No other single process was under unusually heavy load at the time of the incidents.

Impact

Long-running sessions doing multi-agent orchestration (e.g., a data-seeding workflow dispatching many sequential/parallel background agents over several hours) cannot currently be trusted to run unattended — the whole desktop app can silently close, with no crash telemetry captured by Windows in at least 2 of the 3 most recent incidents, making root-causing from the OS side difficult without instrumentation on Anthropic's end (e.g., the Cowork VM service or the main app logging its own crash dumps/stack traces on this failure path, since Windows' own WER isn't reliably catching it).

What would help from Anthropic's side

• Confirm whether the Cowork VM sandbox (cowork-svc.exe / HCS-based) has known resource-leak or connection-stability issues under sustained multi-agent workloads, especially across long sessions rather than just high peak concurrency.
• If possible, have the Cowork VM service or main app write its own crash dump / stack trace when the "connection ended: failed to read length: EOF" disconnect happens with active agents in flight, since Windows Error Reporting isn't reliably catching this failure mode.
• Any guidance on a safe concurrency/duration ceiling for background Agent tool usage on Windows would help users avoid triggering this until it's fixed.