[BUG] Cowork Windows: sandbox VM disk (rootfs.vhdx) hits a hard 10 GiB cap every 1–2 weeks and kills bash with "No space left on device"; recovery service doesn't restart itself after a crash

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Environment: Claude desktop app for Windows, Cowork mode. The sandbox is a Hyper-V VM managed by CoworkVMService (cowork-svc.exe, runs as LocalSystem); its virtual disks live in AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\ (rootfs.vhdx, sessiondata.vhdx, smol-bin.vhdx). WSL is not involved (wsl.exe --list reports it is not even installed on this machine).

Each virtual disk has a hard cap of 10.00 GiB and never shrinks. rootfs.vhdx (the VM's system filesystem: packages a session installs with pip/npm, plus their caches) grows with ordinary use and is never pruned. When it reaches the cap, every bash tool call in every session fails immediately, because the VM can no longer even write /etc/passwd for a new session user.

This has now happened three times on one machine in three weeks: 31 Aug 2026 (sessiondata.vhdx full), 8 Sep 2026 (rootfs.vhdx full, ~2 weeks after a clean rebuild), and 20 Sep 2026 (rootfs.vhdx again, caught at 9.16/10.00 GiB by a preventive size check before it fully failed). After the 31 Aug crash, CoworkVMService itself did not restart on its own — it exited with code 1067 and stayed down until the whole PC was rebooted; simply restarting the service did not recover it.

Separately, sessiondata.vhdx (/sessions) shows the backing file does not reflect real content: df inside the VM reported /sessions at 70% (6.4 GB) while du on the same filesystem found about 700 KB of actual files (session folders are empty 4 KB placeholders). fstrim inside the VM fails with "Operation not permitted" (no sudo available), so the space cannot be reclaimed from inside the VM either. So the 10 GiB cap is being hit by a high-water mark, not by real disk usage.

What Should Happen?

Either the per-disk cap should not exist (or should be much higher / auto-expanding), or the app should prune, trim, or rebuild rootfs.vhdx and sessiondata.vhdx automatically before they fill up, instead of leaving that entirely to the user. At minimum: (1) CoworkVMService should have working recovery actions configured so it restarts itself after a crash instead of requiring a full Windows reboot, and (2) the app should detect the near-full condition itself and prompt the user to reset the sandbox, rather than surfacing an opaque "No space left on device" error from inside a bash call with no indication of the real cause.

Error Messages/Logs

useradd: /etc/passwd.94766: No space left on device

(bash tool calls fail immediately with this or equivalent "no space" errors once the .vhdx hits 10.00 GiB; nothing else in the app's UI indicates a disk-full condition)

Steps to Reproduce

1. Use Cowork on the Windows desktop app over a couple of weeks of normal work, in sessions that install Python or npm packages.
2. Watch AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx grow over time. It only grows.
3. When it reaches 10.00 GiB, any bash tool call in any session fails with a "No space left on device" style error (e.g. on useradd writing /etc/passwd), because the VM's system disk is full.
4. Recovery requires manually: closing the desktop app, stopping CoworkVMService, renaming the full .vhdx file, and restarting the service, which rebuilds a fresh disk on next launch (re-downloading the base image). If CoworkVMService fails to come back up cleanly (observed 31 Aug 2026, service exited with code 1067), a full Windows reboot is required before the service will run again.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude desktop app for Windows (Cowork), not the CLI

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

I am a non-developer (clinician/academic) running about 55 Cowork projects, so I depend on the sandbox being available without intervention. Since there's no in-app control for this, I built my own preventive check (a scheduled task that measures the .vhdx files daily via PowerShell, outside the VM, so it still works when bash itself is dead) and a one-click repair script. That works, but it's a user-side workaround for what looks like a missing disk-management feature. Related: this may be connected to the file-card issues (#95641, #95365, #86337, #72439) only in that all of them surfaced in the same two-week window after the early-September desktop app updates on this machine — flagging in case that's a useful signal, not claiming they're the same bug.

Start by locating the CoworkVMService Windows service and the Cowork VM disk provisioning, health-check, and recovery entry points; the report names rootfs.vhdx, sessiondata.vhdx, and the service as the affected components. Reproduce the near-full condition and service crash if possible, then verify that disk exhaustion is detected and recovery occurs without requiring a full Windows reboot.