[BUG] Cowork Windows: rootfs.vhdx is invalidated and re-decompressed on every launch, adding minutes to startup on mechanical disks
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
On every launch, Cowork discards the existing decompressed rootfs.vhdx and rebuilds it from rootfs.vhdx.zst, even though both the image and its .rootfs.vhdx.origin marker are still present from the previous session.
On a SATA hard disk this adds 4–6 minutes to every startup.
The reason appears to be that rootfs.vhdx is written to during the session, while .rootfs.vhdx.origin is not updated. On the next launch the image no longer matches its recorded origin, so it is treated as invalid.
Bundle contents while Claude was running:
rootfs.vhdx 7.70 GB 19:23:02
.rootfs.vhdx.origin 0 B 19:12:15
After a clean shutdown via File > Exit:
rootfs.vhdx 7.68 GB 19:27:08 <- modified again on shutdown
.rootfs.vhdx.origin 0 B 19:12:15 <- marker unchanged
Nothing is deleted between sessions. Both files survive. But the mtime of the image keeps moving while the marker stands still, and the next launch logs rootfs.vhdx origin missing and rebuilds all 7.7 GB.
If rootfs.vhdx is meant to be the immutable base image, it should not be written to. sessiondata.vhdx exists alongside it and appears to be the intended place for mutable state.
Evidence
cowork_vm_node.log, two consecutive launches on the same day, same machine, no reinstall or update in between:
18:43:35 [Bundle:status] rootfs.vhdx origin missing
18:43:35 [warm] No warm file found for rootfs.vhdx at current version
18:49:42 [cache] rootfs.vhdx decompression from cache completed in 367232ms
19:08:15 [Bundle:status] rootfs.vhdx origin missing
19:08:15 [warm] No warm file found for rootfs.vhdx at current version
19:12:15 [cache] rootfs.vhdx decompression from cache completed in 239233ms
19:12:20 All files ready in ...\vm_bundles\claudevm.bundle
19:12:29 [VM:start] Windows VM service configured
19:12:29 [VM:steps] create_network completed (2ms)
19:12:35 [VM:steps] vm_boot completed (4140ms)
19:12:59 [VM] Network status: CONNECTED
19:13:08 [VM] API reachability: REACHABLE
19:13:16 [VM:start] Startup complete, total time: 238353ms
Everything after the decompression is fast. The VM boots in 4 seconds, the network is created in 2 ms, and the guest connects normally. The entire delay is the repeated decompression.
Consequence — likely explains a large cluster of existing reports
While this is happening, the UI reports:
Failed to start Claude's workspace
VM connection timeout after 60 seconds
The startup has not failed. It completes successfully at 238 seconds every time if you simply wait. The 60-second timeout fires during work the app itself started.
"VM connection timeout after 60 seconds" is already reported in #36137, #39161, #42784, #48370, #61113, #65128 and #67066, and in several of those the user concludes the workspace is broken and starts reinstalling. On this machine the workspace was never broken — it was just slow, and the error message said otherwise. Fixing the re-decompression would remove the timeout for anyone whose storage is the limiting factor.
Possibly related: #56542 (path handling between AppData\Roaming and AppData\Local).
What Should Happen?
A decompressed rootfs.vhdx that is still valid should be reused across launches rather than rebuilt, so startup costs seconds instead of minutes.
Secondarily, while a decompression is in progress the UI should show progress rather than a timeout error, since the operation is known to take several minutes on slow storage.
Error Messages/Logs
Steps to Reproduce
- Install Claude Desktop on a machine whose system drive is a mechanical hard disk, not an SSD.
- Open Cowork and let the VM start fully.
- Quit Claude with File > Exit. Wait one minute.
- Confirm that rootfs.vhdx and .rootfs.vhdx.origin are both still present in the bundle folder, and note that the mtime of rootfs.vhdx is later than that of the marker.
- Start Claude again and open Cowork.
- Observe rootfs.vhdx origin missing in cowork_vm_node.log, followed by a full re-decompression, while the UI shows the 60-second timeout.
- Wait roughly 4 minutes. The workspace starts successfully.
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude Desktop: 1.24012.9.0 (MSIX)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Environment
OS: Windows 10 Home 22H2, build 19045
CPU: Intel Core i7, 4th generation (2013)
RAM: 12 GB
System drive: SATA hybrid hard disk, 5400 rpm class, 625 GB free
Claude Desktop: 1.24012.9.0 (MSIX)
Hyper-V role not present (Home edition); VirtualMachinePlatform enabled and vmcompute running — the VM itself works correctly
Windows Defender active, no exclusions configured
Storage Sense disabled; nothing on the machine deletes the bundle files
Additional Information
Networking is not involved. Get-NetNat is empty and no manual NAT rule is needed — the HNS network created by create_network handles it, and the guest reports CONNECTED and REACHABLE. The sole issue is the repeated decompression.
This should affect any user on mechanical storage, which on older hardware is still common.