[BUG] Cowork: `stable` channel points to a VM runtime that rejects the desktop app's bundled SDK wrapper — surfaced as "Download failed"

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 9, 2026

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 from
testedWrapperVersions, 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

  1. 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.2100.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.

  1. 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.

  1. 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.

  1. 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/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)

---

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_

View original on GitHub ↗