Claude desktop local-agent VM (claudevm.bundle/rootfs.img) grows unboundedly and is never reclaimed — silently fills disk, causes out-of-space failures

Summary

The Claude desktop app provisions a local Linux microVM (gvisor/vfkit-based) to sandbox "local agent mode" / cowork / sandboxed-skill execution. It is stored as a growable raw disk image at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/. The live disk (rootfs.img) grows monotonically and is never trimmed, compacted, or garbage-collected, so it silently consumes disk until the machine runs out of space. This produced hard "out of disk space" failures mid-prompt with no visible cause.

Environment

• Claude desktop 1.11187.1 (Electron 41.6.1)
• Claude Code 2.1.161 (embedded)
• macOS 26.1 (build 25B5042k), Apple M4
• 460 GB volume

What it was (technical)

• rootfs.img — the live VM disk — had grown to 10 GB from a ~2 GB compressed base (rootfs.img.zst).
• sessiondata.img — 1.3 GB of per-session state.
• Total bundle ~13 GB, the single largest consumer inside ~/Library/Application Support/Claude (~13 GB overall).
• Growth is driven by sandboxed tasks (apt/npm/pip installs, build artifacts, downloads) writing into the persistent guest disk. Files deleted inside the guest are not reclaimed on the host — there is no fstrim/discard pass-through and no post-session compaction, so the host-side image only ever grows.

Evidence of runaway growth

• Bundle created 2026-03-08 (first cowork / local-agent use). By 2026-06-04, rootfs.img had reached 10 GB — with ~10 GB written in that single day (file mtime 17:22), tracking a heavy cowork/SDK-skill session.
• Free space on the volume dropped below 13 GB of 460 GB, producing a hard "out of disk space" failure mid-prompt, on more than one occasion.

Why it surprises users ("emerged out of nowhere")

Nothing in the UI surfaces the VM or its size, and there is no cleanup affordance. From the user's perspective, double-digit GB disappear with no visible cause and no obvious owner — it is not discoverable without manually spelunking ~/Library/Application Support.

Expected behavior / suggested fixes

1. Periodic guest fstrim + host-side image compaction, or a discard/sparse-aware image format, so freed guest space is returned to the host.
2. Cap the image size and/or auto-reset the VM disk when idle.
3. Surface VM storage in Settings → Storage with a one-click reclaim.
4. Garbage-collect stale session layers instead of accumulating everything into a single ever-growing disk.

Workaround (verified)

With the VM dormant (no vfkit/gvisor process running, image not held open per lsof), delete rootfs.img + sessiondata.img. The VM rebuilds from rootfs.img.zst on next use. This reclaimed ~11 GB with no loss of projects or cowork session data (session state lives separately under local-agent-mode-sessions/).