[BUG] Cowork VM fails to start — SDK download truncated at ~4 MB, checksum verification fails every attempt (macOS, Apple Silicon)

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?

Summary

Cowork/Code mode cannot start. On every launch, download_and_sdk_prepare fetches the claude-code-vm SDK binary but the transfer is truncated at ~4 MB (the same byte count every time), so checksum verification fails on all 3 retries and startup aborts with the misleading message "Download failed. Check your internet connection and try again." The connection is fine — the app's downloader is cutting the transfer short.

Launch Claude Desktop on macOS Apple Silicon with Cowork attempting SDK 2.1.177.
Observe download_and_sdk_prepare fail with checksum mismatch on all 3 attempts.
Note transferred bytes: 4194272 vs expected: 53850962 in ~/Library/Logs/Claude/main.log.

Suspected cause

Claude Desktop's SDK download pipeline truncates the response body at ~4 MiB before checksum verification (consistent with issue #50493). Appears to coincide with the 2.1.177 SDK rollout.

What Should Happen?

On launch, Cowork should download the complete claude-code-vm SDK binary (~53.8 MB), pass checksum verification, and start the VM so Cowork/Code mode is usable. If the newer SDK (2.1.177) can't be verified, it should fall back to the already-present, verified 2.1.170 binary rather than aborting startup.

Error Messages/Logs

[ClaudeCodeManager-VM] Downloaded file size: 11661956 bytes, transferred bytes: 4194272 bytes (expected: 53850962)
[ClaudeCodeManager-VM] Checksum mismatch: expected=f585026d3322bb08a52adc8bfed4fa8c589b7c6f32aca3d3a48870da6cea1f4c, actual=4485454ba229bfe0a2b02a7af48679afa773f822eea370355b4bedfcb3cb1858
[ClaudeCodeManager-VM] All download attempts failed

Steps to Reproduce

1. On macOS Apple Silicon (M4, Tahoe 26.5.1), open Claude Desktop 1.13576.0 with Cowork, which attempts to fetch SDK 2.1.177 (linux-arm64).
2. Watch ~/Library/Logs/Claude/main.log and cowork_vm_node.log during launch.
3. download_and_sdk_prepare fails: the SDK transfer stops at 4,194,272 bytes of an expected 53,850,962, so checksum verification fails on all 3 attempts and the VM never starts.
4. Reproduces identically on home Wi-Fi and on a phone hotspot (same byte cutoff), with no active VPN/proxy — confirming app-side truncation, not the network.

Result: Cowork/Code cannot start; the on-screen error is the misleading "Download failed. Check your internet connection and try again."

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Last working Cowork SDK: 2.1.170 (worked until the auto-upgrade to 2.1.177). Exact prior app build unknown.

Claude Code Version

Claude Desktop 1.13576.0 (Cowork). SDK attempted: 2.1.177; last verified on disk: 2.1.170.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is Claude Desktop "Cowork" mode (not the standalone CLI), so the Terminal/Shell and claude --version fields above don't map cleanly — the relevant version is Claude Desktop 1.13576.0.

Full environment: macOS Tahoe 26.5.1, Apple M4 (arm64); VM target is linux-arm64.

The downloaded SDK fragment is a valid ELF header but truncated to ~4 MiB (4,194,272 bytes) of the expected 53,850,962, so its checksum (actual=4485454b…) never matches expected (f585026d…). The byte count is identical on every retry, across two different networks (home Wi-Fi + phone hotspot), and with no active VPN/proxy — pointing to the app's HTTP download client truncating the response body, not the network or CDN.

Likely duplicates / related: #50493, #49430.