[BUG] Cowork: `stable` channel points to a VM runtime that rejects the desktop app's bundled SDK wrapper — surfaced as "Download failed"
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?
What Does NOT Help
All confirmed on this machine, and consistent with #60660 and #65649:
Deleting or renaming vm_bundles\claudevm.bundle — done four times; re-downloads and re-validates cleanly every time, then fails identically
Full Claude Desktop reinstall
Stopping / restarting / reconfiguring CoworkVMService
Editing .sdk-version to a compatible runtime — the app re-derives its target and ignores it
Switching networks — #65649 confirms identical failure on a phone hotspot
What Should Happen?
Every Cowork session fails with:
Failed to start Claude's workspace — Download failed. Check your internet connection and try again.
This is not a download failure and not a corrupt artifact. Every VM bundle file is present and
checksum-validated immediately before the error, and both relevant CDN artifacts return clean 200s
with valid MD5s.
The actual failure is a compatibility-metadata mismatch:
Claude Desktop 1.26832.0.0 bundles SDK wrapper 0.3.222.https://downloads.claude.ai/claude-code-releases/stable returns 2.1.220.
Runtime 2.1.220 was built 2026-07-24, and its sdkCompat.testedWrapperVersions caps at 0.3.218.0.3.222 is first accepted by runtime 2.1.224, published 2026-08-06 — but stable never advanced to it.
So download_and_sdk_prepare fetches the stable runtime manifest, finds its own wrapper absent fromtestedWrapperVersions, and aborts. The app reports this as a connectivity problem.
The stable pointer is four releases behind the app (six behind latest, which is 2.1.226).
---
Evidence
- The compatibility gap
sdkCompat.testedWrapperVersions across published manifests:
Runtime buildDate Highest tested wrapper
2.1.219 2026-07-24 0.3.218
2.1.220 ← stable 2026-07-24 0.3.218
2.1.221 2026-08-03 0.3.220
2.1.222 2026-08-04 0.3.221
2.1.223 2026-08-05 0.3.221
2.1.224 2026-08-06 0.3.222 ✅
Wrapper version strings embedded in the shipped app bundle:
$asar = "C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar"
Select-String -Path $asar -Pattern '0\.3\.\d{3}' -AllMatches -Encoding ascii |
ForEach-Object { $_.Matches.Value } | Sort-Object -Unique
0.3.182 ... 0.3.215, 0.3.217, 0.3.218, 0.3.220, 0.3.221, 0.3.222
Two things follow. The app carries 0.3.222, which stable cannot accept. And the app's embedded
list includes 0.3.210–0.3.214, which appear in the 2.1.221+ manifests but not in 2.1.219/2.1.220 —
so the desktop build was compiled against a newer runtime generation than the one stable advertises.
- The artifacts are intact
$ curl -sI https://downloads.claude.ai/claude-code-releases/2.1.219/linux-x64/claude.zst
HTTP/1.1 200 OK
Content-Type: application/zstd
Content-Length: 62548539
x-goog-hash: md5=6G+1zv/06vqV4DnP3AS6Qw==
$ curl -sI https://downloads.claude.ai/claude-code-releases/2.1.220/linux-x64/claude.zst
HTTP/1.1 200 OK
Content-Type: application/zstd
Content-Length: 62556070
x-goog-hash: md5=MMjHGjgZ8Z22jL6OLAztRA==
Nothing is missing, truncated, or unreachable. This rules out the corrupt-download hypothesis in
#49430 and #50493 for this case.
- Failure timing proves nothing is being downloaded
When the VM bundle is already unpacked, download_and_sdk_prepare fails at a near-constant duration
across 15+ consecutive attempts:
3019, 3025, 3031, 3024, 3020, 3017, 3026, 3011, 3014, 3028, 3032, 3023, 3018, 3047 ms
A 62 MB transfer cannot succeed or fail in ~3.02 s with ±15 ms variance. This is a manifest fetch plus
a list-membership check — consistent with the manifest-version-mismatch identifier already present in
the app bundle, and with the independent macOS analysis in #65649.
When the bundle does need decompressing, the step runs longer (16368, 20871, 25302, 32905, 91116,
99766 ms) but fails at the identical point — immediately after All files ready.
- The VM service is healthy and never involved
SERVICE_NAME: CoworkVMService
TYPE : 210 WIN32_PACKAGED_PROCESS
START_TYPE : 2 AUTO_START
BINARY_PATH_NAME : "C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
STATE : 4 RUNNING
cowork-service.log shows the service starting cleanly, Named pipe server listening, the client
connecting, signature verified, and a VM session created — then zero log entries during any of the
~15 subsequent failed start attempts. The service is never asked to boot a VM. The failure is entirely
app-side, upstream of VM start.
---
Error Messages/Logscowork_vm_node.log — the contradiction, verbatim:
2026-08-09 10:14:39 [info] [cache] rootfs.vhdx checksum validated
2026-08-09 10:14:40 [info] [cache] rootfs.vhdx decompression from cache completed in 30538ms
2026-08-09 10:14:40 [info] [downloadVM] Decompressed rootfs.vhdx from local cache
2026-08-09 10:14:40 [info] [cache] vmlinuz checksum validated
2026-08-09 10:14:40 [info] [cache] initrd checksum validated
2026-08-09 10:14:40 [info] All files ready in ...\vm_bundles\claudevm.bundle
2026-08-09 10:14:40 [error] [VM:steps] download_and_sdk_prepare failed (20871ms): Download failed. Check your internet connection and try again.
2026-08-09 10:14:40 [error] [VM:start] Startup failed: Error: Download failed. Check your internet connection and try again.
at Ut (C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.chunk-BePYlYru.js:10:1538)
at async Object.startVM (...\index.chunk-aUP09L-a.js:78:45096)
2026-08-09 10:14:40 [info] [VM:start] Skipping auto-reinstall (already attempted once)
---
cowork-download-failed-bug-report.md
Error Messages/Logs
Error Messages/Logs
`cowork_vm_node.log` — the contradiction, verbatim:
2026-08-09 10:14:39 [info] [cache] rootfs.vhdx checksum validated
2026-08-09 10:14:40 [info] [cache] rootfs.vhdx decompression from cache completed in 30538ms
2026-08-09 10:14:40 [info] [downloadVM] Decompressed rootfs.vhdx from local cache
2026-08-09 10:14:40 [info] [cache] vmlinuz checksum validated
2026-08-09 10:14:40 [info] [cache] initrd checksum validated
2026-08-09 10:14:40 [info] All files ready in ...\vm_bundles\claudevm.bundle
2026-08-09 10:14:40 [error] [VM:steps] download_and_sdk_prepare failed (20871ms): Download failed. Check your internet connection and try again.
2026-08-09 10:14:40 [error] [VM:start] Startup failed: Error: Download failed. Check your internet connection and try again.
at Ut (C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.chunk-BePYlYru.js:10:1538)
at async Object.startVM (...\index.chunk-aUP09L-a.js:78:45096)
2026-08-09 10:14:40 [info] [VM:start] Skipping auto-reinstall (already attempted once)
Steps to Reproduce
Windows 11 x64, Claude Desktop 1.26832.0.0 (MSIX).
Open Cowork and run any command requiring the sandbox.
Banner appears within ~3 s: "Failed to start Claude's workspace — Download failed…"
Confirm curl https://downloads.claude.ai/claude-code-releases/stable → 2.1.220.
Confirm 2.1.220/manifest.json → sdkCompat.testedWrapperVersions ends at 0.3.218.
Confirm the app bundle contains wrapper string 0.3.222.
Confirm 2.1.224/manifest.json lists 0.3.222 and is published and reachable.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.226
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_