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

Solid forensics — and your root-cause read matches the well-known failure mode for this kind of disk image: a growable raw image backing a microVM only ever grows on the host unless the guest issues discard/fstrim and the host honors it as a hole-punch. Without that pass-through (and without idle compaction), every install/build/download inside the guest is a permanent host-side write, even after the guest deletes it. So "monotonic growth, never reclaimed" is the expected behavior here, not an edge case. Your reclaim (delete rootfs.img + sessiondata.img while the VM is dormant, rebuild from rootfs.img.zst, session state lives under local-agent-mode-sessions/) lines up with that and is the right manual lever until there's a real fix.
The one piece that's still missing is early warning. Your worst outcome wasn't the wasted GB — it was the hard out-of-disk failure mid-prompt, with no visible owner. That's a silent failure: the cost is invisible until it's catastrophic. Until the app surfaces VM storage itself (your suggestion #3), you can make it visible yourself with a read-only size check that warns before it bites. Nothing here touches the bundle — it's just du + a notification:

BUNDLE="$HOME/Library/Application Support/Claude/vm_bundles/claudevm.bundle"
THRESHOLD_GB=6   # warn well before it can starve a mid-prompt write
[ -d "$BUNDLE" ] || exit 0
SIZE_GB=$(du -sg "$BUNDLE" 2>/dev/null | awk '{print $1}')
[ -z "$SIZE_GB" ] && exit 0
if [ "$SIZE_GB" -ge "$THRESHOLD_GB" ]; then
  osascript -e "display notification \"Claude cowork VM is ${SIZE_GB} GB. Quit Claude and reclaim (rootfs.img + sessiondata.img) before it fills the disk.\" with title \"Claude VM disk\""
fi

Run it on a schedule (every few hours) via a LaunchAgent or cron:

0 */4 * * * /bin/bash "$HOME/bin/claude-vm-size-warn.sh"

That turns the silent disk drain into a visible signal you act on at your convenience, instead of discovering it when a write fails mid-session. It also gives you a rough growth-rate read if you log $SIZE_GB over time.
Caveat: I haven't reproduced this on M4 / macOS 26 specifically — the snippet is provider-agnostic and read-only, so it's safe regardless, but treat the 6 GB threshold as a starting point and tune it to your free-space headroom. Your suggested fixes (guest fstrim + host compaction, a size cap with idle auto-reset, and a Settings → Storage reclaim button) are the actual fix; this is just so the failure stops being silent in the meantime.

I can't believe this hasn't been addressed globally. It's so boorish

Adding on to the evidence:
claudevm.bundle had reached 10 GB on my machine, making it the singlelargest item in ~/Library/Application Support/Claude by a wide margin (everything else in that directory combined is ~1.3 GB):

````
$ du -sh ~/Library/Application\ Support/Claude/* | sort -h | tail
162M Code Cache
212M claude-code
233M claude-code-vm
690M Cache
10G vm_bundles <- claudevm.bundle/rootfs.img

$ ls ~/Library/Application\ Support/Claude/vm_bundles
claudevm.bundle warm

````

It's a single growable rootfs.img, not stale versions - consistent with the
report that the guest disk only ever grows because deleted files inside the VM
are never discarded back to the host (no fstrim/discard pass-through, no
post-session compaction).

Two things make this worse than the raw size:

1. No discoverability - nothing in the UI surfaces the VM or its size; the

only way I found it was manually walking ~/Library. Double-digit GB
vanish with no visible owner.

1. The only "fix" is destructive- deleting the whole bundle reclaims the

space but forces a full VM re-provision on next Cowork/sandbox use. There's
no lighter-weight reclaim.

Same problem on Windows (Claude Desktop 1.22209.3.0 MSIX, Claude Code 2.1.215,
Win10 19045). vm_bundles reached 10.2 GB (rootfs.vhdx ~8.3 GB) and left my
system drive with 5 GB free.
Additional data point: after deleting the folder, the app re-created it and
started re-downloading immediately on next launch (observed
.cowork-adopted + rootfs.vhdx.zst.<hash>.partial within minutes), even
though no Cowork session was started. There is no setting to opt out, disable
local Cowork provisioning, or relocate the bundle.
On Windows the folder is also hidden behind MSIX path virtualization
(%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles),
so most users can't even find what is eating their disk.
Workaround: NTFS junction redirecting vm_bundles to another drive.
Requests: make provisioning opt-in (ask before a 10+ GB download), add a
disable setting, and compact the VHDX instead of letting it grow forever.

Claude Desktop Version 1.32885.1 (a757f5), same problem. It happened on 4th June the first time; I submitted feedback and a support request. Then I uninstalled it and reinstalled it. All Cowork tasks were gone. What a painful point.
This week it happened again. Can't it be installed on other drives for technical reasons?
Does the environment can only survive on C to be functional?