[BUG] macOS: Cowork VM provisioning writes 10.7 GB in 13 min and trips the macOS disk-write limit; rootfs.img.zst kept after extraction (11.2 GB bundle)

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 26, 2026

Summary

On macOS, re-provisioning the local agent / Cowork VM writes the full uncompressed 10 GiB rootfs.img to disk fast enough that macOS raises its own disk writes resource diagnostic against Claude Desktop — twice in twelve minutes, at up to 135× the OS write-rate limit. Separately, the source rootfs.img.zst (1.14 GB) is kept on disk after extraction, so the bundle costs 11.2 GB rather than 10 GB, and a zero-byte .partial download artifact is left behind.

This is distinct from #65577 (image grows unboundedly and is never reclaimed) and #22543 (10 GB bundle degrades performance). Both of those are about the steady-state size. This report is about the write burst during provisioning and the redundant retention of the compressed source image, which have their own fixes.

Environment

Claude Desktop 1.37937.2
macOS 27.0 beta (build 26A5421a)
MacBook Pro Mac14,7, Apple M2, 8 GB RAM
228 GB internal SSD, 69 GB free at time of incident

Evidence

macOS generated two disk writes diagnostic reports against com.anthropic.claudefordesktop on 2026-08-26, in /Library/Logs/DiagnosticReports/:

Claude_2026-08-26-170704_*.diag — window 17:05:02.923 → 17:07:02.143

Event:            disk writes
Writes:           2147.49 MB of file backed memory dirtied over 119 seconds
                  (18.01 MB per second average), exceeding limit of
                  24.86 KB per second over 86400 seconds
Writes duration:  119s
Footprint:        258.56 MB

Claude_2026-08-26-171747_*.diag — window 17:07:02.155 → 17:17:44.970

Event:            disk writes
Writes:           8589.96 MB of file backed memory dirtied over 643 seconds
                  (13.36 MB per second average), exceeding limit of
                  99.42 KB per second over 86400 seconds
Writes duration:  643s
Free disk space:  71.26 GB/228.27 GB
Footprint:        258.56 MB

The two windows are contiguous and non-overlapping (the second starts 12 ms after the first ends), so they are two escalating thresholds fired against one continuous write operation. They sum to:

2147.49 MB + 8589.96 MB = 10737.45 MB

rootfs.img is 10737418240 bytes = 10737.42 MB. The reported writes match the size of the extracted image to within rounding — the entire burst is one uncompressed write of the VM root filesystem.

The bundle contents confirm it:

$ ls -l ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
-rw-------  1 ali  staff           40 Aug 26 17:05 .cowork-adopted
-rw-------  1 ali  staff           40 Aug 26 17:24 .rootfs.img.origin
-rw-------  1 ali  staff           40 Aug 26 17:24 .rootfs.img.zst.origin
-rw-------  1 ali  staff     81214310 Aug 12 14:17 initrd
-rw-------  1 ali  staff     80510184 Aug 12 14:17 initrd.zst
-rw-------  1 ali  staff  10737418240 Aug 26 17:24 rootfs.img
-rw-------  1 ali  staff   1227484424 Aug 26 17:24 rootfs.img.zst
-rw-r--r--  1 ali  staff     32595968 Aug 13 18:28 sessiondata.img
-rw-------  1 ali  staff            0 Aug 26 17:24 vmlinuz.zst.f380613cca66.partial

rootfs.img is exactly 10737418240 bytes (10 GiB) and is not sparse — du reports the full 10 GB resident on disk, matching ls.
rootfs.img.zst (1.14 GB) has the same mtime as the extracted image, i.e. it is still there after extraction completed.
initrd and initrd.zst show the same duplication pattern (81 MB + 80 MB).
vmlinuz.zst.f380613cca66.partial is a zero-byte leftover from an interrupted or completed download that was never cleaned up.
.cowork-adopted has mtime 17:05, which is the start of the first write burst — so the trigger was VM adoption/provisioning, not ordinary agent activity.

Directory totals:

 12G  ~/Library/Application Support/Claude
 11G  ~/Library/Application Support/Claude/vm_bundles
287M  ~/Library/Application Support/Claude/claude-code-vm
281M  ~/Library/Application Support/Claude/claude-code

Impact

SSD endurance. 10.7 GB of real writes per provisioning pass. On a soldered consumer SSD this is not free, and it repeats every time the VM is re-provisioned or reset (see #22543: "regenerates quickly after deletion").
OS-level throttling. Once the daily write budget is blown, macOS classifies the process as a resource offender. This is the same mechanism that leads to background-work deprioritisation.
Disk footprint is 11.2 GB, not 10 GB. The 1.14 GB compressed copy serves no purpose after extraction. On this machine that is 1.6% of the whole SSD held for nothing.
Memory pressure on 8 GB machines. File-backed dirty pages at 13–18 MB/s on a machine with 8 GB RAM and a 2 GB swap file push the system into swap during provisioning.

Expected behaviour

Delete rootfs.img.zst (and initrd.zst) once extraction is verified, or don't persist them at all — stream-decompress from the download.
Create rootfs.img as a sparse file so an image that is mostly empty does not cost 10 GB of real blocks or 10 GB of real writes.
Rate-limit or chunk the extraction so it does not exceed the macOS disk writes budget in a single pass.
Clean up *.partial artifacts after a download completes or aborts.

Reproduce

Use Claude Desktop on macOS with local agent mode / Cowork enabled, on a machine where the VM has to be provisioned or re-provisioned.
Wait for provisioning to finish.
ls -l ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/ — both rootfs.img and rootfs.img.zst are present.
ls -lt /Library/Logs/DiagnosticReports/ | grep Claude — macOS disk writes diagnostics have been filed against the app.

Workaround

Quitting Claude Desktop and deleting rootfs.img.zst reclaims 1.14 GB with no functional loss until the next re-provision, which re-downloads it. Deleting rootfs.img as well (per #65577) reclaims the rest but guarantees another 10.7 GB write burst on next use.

View original on GitHub ↗