claude-code - 💡(How to fix) Fix Cowork (macOS): VM SDK 2.1.163 fails download_and_sdk_prepare ("Download failed") though artifact is reachable; no fallback to working 2.1.161

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Cowork fails to start on macOS (Apple Silicon) with: "Failed to start Claude's workspace - Download failed. Check your internet connection and try again."

This is NOT a network or missing-artifact problem. The failing step is download_and_sdk_prepare, specifically its SDK half. The Cowork VM's internal Linux runtime was bumped server-side from 2.1.161 to 2.1.163, and the host-side prepare of the 2.1.163 linux-arm64 runtime fails, leaving ~/Library/Application Support/Claude/claude-code-vm/2.1.163 empty on every launch. The VM rootfs itself decompresses and checksum-validates fine; "All files ready" is logged immediately before the failure.

Evidence it is not the network and not a missing file:

(1) The 2.1.163 linux-arm64 artifact is reachable and intact: GET https://downloads.claude.ai/claude-code-releases/2.1.163/linux-arm64/claude.zst returns HTTP 200, content-length 52,819,087, valid md5. The 2.1.161 equivalent also returns 200.

(2) Fails identically (~3.5s) on two different networks (home Wi-Fi and a phone hotspot). A fast, consistent failure is the signature of a verification step, not a transfer timeout.

(3) .sdk-version is still 2.1.161; the in-VM coworkd log shows the last successfully installed SDK is v2.1.161, with no 2.1.163 install.

(4) The macOS half (claude-code/2.1.163/claude.app) installs fine; only the Linux VM runtime (claude-code-vm/2.1.163) fails.

(5) The app surfaces only the generic "Download failed", but the app bundle contains the error identifiers checksum_mismatch and manifest-version-mismatch, consistent with a manifest/checksum verification failure on the 2.1.163 runtime.

Two underlying problems. First, the 2.1.163 Linux VM runtime cannot be prepared (likely a manifest/checksum mismatch in the release). Second, on prepare failure the app does not fall back to the already-installed, working 2.1.161 runtime; it bricks the entire workspace and shows a misleading "check your internet connection" message.

Reinstalling the app, clearing the VM bundle, and "Reinstall workspace" all fail to help (they re-trigger the same failed prepare). This looks like the same root cause as #60660 (same "All files ready -> Download failed" contradiction, reported on Windows); this appears to be the macOS / 2.1.163-specific manifestation.

What Should Happen?

Either of the following would resolve it:

The 2.1.163 Linux VM runtime should prepare and install successfully (the released artifact's manifest/checksum should match what the app verifies).

Or, if a runtime version cannot be prepared, the app should gracefully fall back to the last known-good installed runtime (2.1.161 is present and verified here) instead of failing the entire workspace.

Separately, the user-facing error should reflect the real cause (a verification/prepare failure) rather than "Download failed. Check your internet connection," which misdirects users into repeated, pointless reinstalls.

Error Messages/Logs

cowork_vm_node.log (the failure; paths shortened):

2026-06-05 15:17:11 [info] [VM:steps] download_and_sdk_prepare started
2026-06-05 15:17:11 [info] [cache] Decompressing rootfs.img from cached .../claudevm.bundle/rootfs.img.zst
2026-06-05 15:17:19 [info] [cache] rootfs.img checksum validated
2026-06-05 15:17:19 [info] [cache] rootfs.img decompression from cache completed in 7096ms
2026-06-05 15:17:19 [info] All files ready in .../claudevm.bundle
2026-06-05 15:17:19 [error] [VM:steps] download_and_sdk_prepare failed (7097ms): Download failed. Check your internet connection and try again.
2026-06-05 15:17:19 [error] [VM:start] Startup failed: Error: Download failed. Check your internet connection and try again.
    at jCr (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.js:532:1906)
2026-06-05 15:17:19 [info] [VM:start] Skipping auto-reinstall (already attempted once)

main.log (macOS half of 2.1.163 installs fine):
2026-06-05 11:52:21 [info] [CCD] Initialized with version 2.1.163
2026-06-05 14:48:48 [info] [CCD] Installed bundle at .../Claude/claude-code/2.1.163

coworkd.log (in-VM; last successful SDK install, no 2.1.163):
2026/06/04 22:51:48 [coworkd] installed SDK binary v2.1.161 to /usr/local/bin/claude

Server reachability check (artifact present and intact):
$ curl -sI https://downloads.claude.ai/claude-code-releases/2.1.163/linux-arm64/claude.zst
HTTP/2 200
content-length: 52819087
content-type: application/zstd
x-goog-hash: md5=c6QQRvFMsdNjR8hLrSHyLQ==

Steps to Reproduce

Step 1. On macOS (Apple Silicon), Claude Desktop 1.11187.2, open the Cowork tab.

Step 2. The app advances the in-VM SDK runtime target to 2.1.163 (server-driven; main.log shows "[CCD] Initialized with version 2.1.163" starting today).

Step 3. The banner appears almost immediately: "Failed to start Claude's workspace - Download failed. Check your internet connection and try again."

Step 4. Observe that ~/Library/Application Support/Claude/claude-code-vm/2.1.163 is recreated empty on every launch, while claude-code-vm/2.1.161 stays intact (contains the claude binary and a .verified marker).

Step 5. "Reinstall workspace", clearing the vm_bundles bundle, and a full reinstall of Claude Desktop all reproduce the same failure (each just re-triggers download_and_sdk_prepare, which fails at the SDK step).

Step 6. The failure also reproduces on a completely separate network (phone hotspot), confirming it is not local connectivity.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.161 (Cowork VM SDK runtime; worked through Jun 4)

Claude Code Version

Claude Desktop 1.11187.2; Cowork VM SDK target 2.1.163 (failing), 2.1.161 last working

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is the Claude Cowork desktop workspace, not the Claude Code CLI. The Platform and Terminal/Shell fields above are auto-detected defaults and are not directly relevant to this issue.

Does NOT help: full Claude Desktop reinstall, deleting vm_bundles/claudevm.bundle, "Reinstall workspace", or switching networks; each just re-triggers the same failing download_and_sdk_prepare.

Suggested fixes: (server) re-publish the 2.1.163 linux-arm64 runtime so its manifest/checksum matches what the client verifies, or roll the in-VM SDK target back to a known-good version; (client) fall back to the last verified runtime on prepare failure rather than bricking the whole workspace, and surface the real cause instead of a generic connectivity message.

Related: #60660 (same "All files ready -> Download failed" pattern, reported on Windows).