[BUG] Checksum mismatch error for rootfs.img.zst on macOS Sequoia 15.7.7 ARM64

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/64883
2. https://github.com/anthropics/claude-code/issues/50493
3. https://github.com/anthropics/claude-code/issues/68030

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This does not appear to be a duplicate

This does not appear to be a duplicate

Confirmed on Claude Desktop 1.13576.0, macOS Tahoe 26.2, Apple Silicon. Happens when I open COWORK Same expected hash as this report (f40e54e8...083e1e00), but my received hash differs: 48d86e53bfd4bc1533a54805ea739b49b198c8ec54dfd8b3d231fdcedcb61a9f. Different reporters getting different "received" hashes for the same expected file suggests the app's HTTP download client corrupts the artifact client-side, not a single bad CDN file (cf. #50493).

Proof the CDN is fine and the app's downloader is the problem:

1. curl'd the exact URL from main.log:

https://downloads.claude.ai/vms/linux/arm64/6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a/rootfs.img.zst
shasum -a 256 → f40e54e816c94625497b37e477a1d70fcdf980f1f0acc166b666a214083e1e00 (matches expected exactly)

1. Decompressed it, placed both rootfs.img and rootfs.img.zst into vm_bundles/claudevm.bundle/, locked with chmod 444, added a .verified marker. Confirmed stored hash = f40e54e8... after a failed launch (lock held).

1. App fails anyway. main.log shows it fires a fresh "Starting download" on EVERY launch and never reads the placed file:

[download:1] Starting download from https://downloads.claude.ai/vms/linux/arm64/6d1538ba.../rootfs.img.zst
[ScheduledTasks] startVM failed: Error: Checksum mismatch ... got 48d86e53...

So two problems: (a) the download client corrupts the file, and (b) the rootfs path has no local-file fallback — it re-downloads unconditionally and ignores a hash-verified bundle file plus markers. The SDK-binary .verified workaround from the 2.1.111 threads does NOT work for the rootfs path.

Ruled out: disk (64GB free), proxy (none), network (WiFi + hotspot, same result), app version (failed right after updating to latest), full reinstall + vm_bundles/claude-code-vm wipe.

I'm also encountering this issue on Claude desktop -- error appears immediately upon relaunching Claude even after manual cleanse of VM bundles library (recommended correction by Claude).

Confirming I'm hitting this same bug on macOS (Apple Silicon, MacBook Air).
Error:

Failed to start Claude's workspace. Checksum mismatch for rootfs.img.zst: expected f40e54e816c94625497b37e477a1d70fcdf980f1f0acc166b666a214083e1e00, got acfcdf3bb9ccdc30d5828dc539cd1114577f69b09300b72346c2c120fe6f79a7

The "expected" and "got" values are identical on every retry, which points to a server/CDN mismatch rather than local corruption.
Things I've tried (none worked):

Reinstalled the workspace via the in-app button multiple times
Fully quit/relaunched the app and restarted the Mac
Searched ~/Library/Application Support/Claude for rootfs.img.zst, .img, and .zst — no such file exists anywhere on disk, so there's nothing corrupt locally to delete. The downloader seems to fetch → fail checksum → delete → retry in a loop.
vm_bundles/claudevm.bundle contains only .auto_reinstall_attempted and .cowork-adopted marker files (otherwise empty).

So the in-app "Reinstall workspace" can't resolve it — there's no local artifact to clear, and each re-download pulls the same mismatched file from the CDN. This looks like it needs a server-side fix. Happy to provide logs if useful.

Confirming on Claude Desktop 1.13576.4, macOS 26.5.1 (Tahoe, build 25F80), Apple Silicon (M4 Max).

Same expected hash as this report (f40e54e8…083e1e00), but my received hash differs again: d7767b08044767f573ca331752ec5599444671580caf8f4715584b29900b3240.

That makes three distinct "received" hashes for the same artifact now — the OP's, @llmacim's 48d86e53…, and my d7767b08… — while the CDN copy is verified-good. That strongly supports @llmacim's conclusion that the app's download/decompress pipeline corrupts the artifact client-side, rather than a single bad CDN object.

From ~/Library/Logs/Claude/cowork_vm_node.log, every startup:

[VM:start] Beginning startup, bundlePath=…/Application Support/Claude/vm_bundles/claudevm.bundle
[VM:start] Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
[Bundle:status] rootfs.img missing
[warm] No warm file found for rootfs.img at current version
[cache] No cached compressed file for rootfs.img
rootfs.img not found, downloading...
Downloading rootfs.img...
[error] Checksum mismatch for rootfs.img.zst: expected f40e54e8…, got d7767b08…

Persists across: a full reboot, the 1.13576.1 → 1.13576.4 auto-update, and a complete manual wipe of vm_bundles/claudevm.bundle (the cold re-download reproduced the identical d7767b08…, so on this machine the corruption is deterministic, not random per-attempt).

Second, separate problem — a recovery trap. After the first failure the app writes a one-shot guard file vm_bundles/claudevm.bundle/.auto_reinstall_attempted. While it exists, every start logs Skipping auto-reinstall (already attempted once) and never retries a clean reinstall. The in-app reinstall / deleteVMBundle only removes rootfs.img / .rootfs.img.origin / efivars.fd — it does not delete that dotfile — so restart, reboot, and reinstall never clear it; the user has to rm it manually. This makes the bug look permanently unrecoverable even after a "reinstall workspace." Please have the reinstall path also clear .auto_reinstall_attempted.

Happy to provide full logs.

wrote this recovery trap ("After the first failure the app writes a one-shot guard file vm_bundles/claudevm.bundle/.auto_reinstall_attempted. While it exists, every start logs Skipping auto-reinstall (already attempted once) and never retries a clean reinstall. The in-app reinstall / deleteVMBundle only removes rootfs.img / .rootfs.img.origin / efivars.fd — it does not delete that dotfile — so restart, reboot, and reinstall never clear it; the user has to rm it manually. This makes the bug look permanently unrecoverable even after a "reinstall workspace." Please have the reinstall path also clear .auto_reinstall_attempted.") in claude code and after claude deleted the files, I closed it and reinstalled claude manually.
It fixed it!! (btw, tks @fishtar )

wrote this recovery trap ("After the first failure the app writes a one-shot guard file vm_bundles/claudevm.bundle/.auto_reinstall_attempted. While it exists, every start logs Skipping auto-reinstall (already attempted once) and never retries a clean reinstall. The in-app reinstall / deleteVMBundle only removes rootfs.img / .rootfs.img.origin / efivars.fd — it does not delete that dotfile — so restart, reboot, and reinstall never clear it; the user has to rm it manually. This makes the bug look permanently unrecoverable even after a "reinstall workspace." Please have the reinstall path also clear .auto_reinstall_attempted.") in claude code and after claude deleted the files, I closed it and reinstalled claude manually. It fixed it!! (btw, tks @fishtar )

Update — this is a Cowork (desktop VM workspace) failure, and the guard-file fix does NOT resolve the download-corruption variant.

To be clear on scope: this is Claude Cowork failing to start its VM workspace on the desktop app, not the Claude Code CLI. The rootfs.img.zst is the Cowork VM rootfs image.

Tried the .auto_reinstall_attempted guard-file fix (delete vm_bundles + claude-code-vm, which removes the guard dotfile the in-app "reinstall workspace" leaves behind, then manual clean reinstall of the app in that order). Confirmed the guard file was present (dated to day one of the failure) and removed.

Result: Cowork still fails, identical hash. got 48d86e53..., expected f40e54e8....

So there appear to be (at least) two distinct Cowork startup failures throwing the same checksum error:

1. Guard-file trap — the app skips a clean reinstall because .auto_reinstall_attempted is never cleared by the in-app "reinstall workspace" path. Fixed by manually removing the dotfile + reinstalling. (Real fix for some users.)
2. Download-client corruption — the desktop app's HTTP downloader corrupts the Cowork rootfs.img.zst in transit. This is mine, and the guard-file fix does nothing for it.

Evidence it's #2 for me: a plain curl of the exact URL from main.log returns the correct file (f40e54e8..., matches expected). The Cowork downloader fetching the same URL produces 48d86e53.... Different reporters get different "received" hashes for the same expected file (mine 48d86e53..., #68514 6311d6aa..., #68565 ffa0a4c0...), consistent with client-side corruption, not a single bad CDN artifact.

Tested on: Claude Desktop (latest, reinstalled today, the build with the new "share your debug logs" message), macOS Tahoe 26.2, Apple Silicon. Home WiFi + cellular hotspot, both fail Cowork startup identically. Guard file removed. A verified-good rootfs file placed in vm_bundles/claudevm.bundle/ is ignored — main.log shows Cowork re-downloads unconditionally on every launch.

The guard-file fix won't help anyone hitting Cowork variant #2. That needs the Cowork download client fixed (or a local-file fallback that trusts a hash-verified bundle file instead of always re-downloading).

Feedback sent to Anthropic. Reference ID: 9ae01330-1c68-427d-9160-a664b46c3bb7

This is mis-tagged as invalid. This is a genuine Claude Cowork / desktop VM bug, not unrelated to this repo.

The same failure is correctly triaged elsewhere: #68565 carries area:cowork, area:desktop, and platform:macos. This issue (#68514) is the same rootfs.img.zst checksum failure on the Cowork VM, same expected hash f40e54e8..., and should be re-triaged to match (and linked as related/duplicate rather than closed as invalid).

Multiple users on current builds are hitting it with different received hashes for the same expected file (48d86e53..., 6311d6aa..., ffa0a4c0...), which points to client-side download corruption in the desktop app, not an issue outside this repo's scope. Debug logs submitted via the in-app prompt, reference ID 9ae01330-1c68-427d-9160-a664b46c3bb7.

Requesting re-triage off invalid so this routes to the Cowork/desktop area.

Bug report: Claude workspace fails to start — checksum mismatch for rootfs.img.zst

Summary: The Linux workspace fails to start on every launch with a checksum mismatch for rootfs.img.zst. The downloaded file's hash is identical on every attempt (same wrong value each time), across fresh downloads, multiple networks, and a fully updated app — which points to a server/CDN deploy desync rather than a local or network problem.

Error message

Failed to start Claude's workspace
Checksum mismatch for rootfs.img.zst:
expected f40e54e816c94625497b37e477a1d70fcdf980f1f0acc166b666a214083e1e00
got      9ea06eecb4c7173a4f82a5cc335a22ab3098f1abf21dc11e49e4d2dcd18fd8aa

Environment

• Platform: macOS (Apple Silicon / ARM64)
• Claude desktop app: latest (updated/reinstalled as part of troubleshooting)
• VM bits observed locally: claude-code-vm 2.1.181

Key diagnostic detail

The got hash is byte-identical on every download attempt. Random network corruption would produce a different hash each time. An identical wrong file every time indicates the served artifact's checksum does not match what the client build expects (deploy desync between client and CDN).

Steps already tried (all unsuccessful)

1. Reinstall workspace (in-app)
2. Fully quit (Cmd+Q) and reopen
3. Restart the Mac
4. Deleted ~/Library/Application Support/Claude/vm_bundles and relaunched to force a clean rebuild
5. Updated / reinstalled the latest Claude desktop app
6. Re-downloaded on a clean network (phone hotspot) with VPN/proxy/filtering off

Impact

Linux workspace is completely unusable (code execution, data processing). Related symptom: recently opened chats bounce back to the home screen, likely because they attempt to attach the workspace and hit the same failure.

Related public issues

• https://github.com/anthropics/claude-code/issues/68514
• https://github.com/anthropics/claude-code/issues/50493

After long investigation and following all steps above, what solved the issue for me was:

1. In Claude Desktop use Help -> Troubleshooting -> Clear Cache and Restart
2. Close Claude Desktop completely
3. Download file by curl curl -o ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/rootfs.img.zst https://downloads.claude.ai/vms/linux/arm64/6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a/rootfs.img.zst
4. check shasum -a 256 ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/rootfs.img.zst
5. Restart Claude Desktop

Thanks Manfred.

coincidentally I saw this on another thread here: https://github.com/anthropics/claude-code/issues/45538 this morning - which means I attempted (1), (2) (5) in your list above and my Cowork space has returned to normal. I have been using for 3 hours. Not gone through an update / restart or any other system process yet to test stability.

After long investigation and following all steps above, what solved the issue for me was: 1. In Claude Desktop use Help -> Troubleshooting -> Clear Cache and Restart 2. Close Claude Desktop completely 3. Download file by curl curl -o ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/rootfs.img.zst https://downloads.claude.ai/vms/linux/arm64/6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a/rootfs.img.zst 4. check shasum -a 256 ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/rootfs.img.zst 5. Restart Claude Desktop

These steps worked for me and fixed Claude.

4\. shasum -a 256 ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/rootfs.img.zst

Thanks, this worked.