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?

After Claude Desktop auto-updated on Saturday Feb 7, 2026, Cowork's Linux VM fails to establish a workspace. The VM boots at the hypervisor level but the guest OS never completes initialization — coworkd never starts. The host times out waiting for a vsock connection and incorrectly blames a VPN.

The failure occurs during guest_vsock_connect. The Swift log confirms "Linux VM started successfully" but the guest Linux OS never reaches the point where coworkd starts. The coworkd.log (VM console output) has zero entries from any of the 10+ failed boot attempts after the update, confirming the guest kernel/init is hanging or crashing before coworkd can initialize. Each attempt ends with the host waiting ~60 seconds, timing out, detecting the Tailscale utun4 interface, and displaying: "Your network traffic may be routing through a VPN, which can interfere with Claude's workspace." This error is a false positive — Tailscale was active during all prior successful boots.

The last successful coworkd boot was at 4:54 PM. Between approximately 5-7 PM the app auto-updated. Starting at 7:40 PM, 8+ consecutive boot attempts all failed with the identical pattern. Quitting and relaunching Claude Desktop multiple times, a full system reboot, and reinstalling the app from the .dmg all failed to resolve the issue. The reinstalled app did not overwrite the VM bundle files at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/ — the corrupted rootfs.img (10.7 GB) and sessiondata.img (316 MB) persisted.

The workaround was manually deleting the VM bundle directory (rm -rf ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle) and relaunching, which triggered a fresh download and resolved the issue.

What Should Happen?

Recommendations
Fix the VPN false positive — The error message blames the user's VPN when the actual failure is the guest OS not booting. The VPN detection should not trigger when the failure is at the vsock/guest-init level, only when network connectivity to an already-running guest fails.

Reinstall should replace VM bundle — If a user reinstalls Claude Desktop, the VM images should be refreshed. Persisting potentially corrupted images across reinstall defeats the purpose.

Add a "Reset Workspace" option — Users should be able to nuke and re-download the VM bundle from the UI without having to find the directory manually.

Integrity check the rootfs on boot — The log shows: "Rootfs is compressed — checksum is for compressed form, skipping on-disk integrity check". After decompression, there is no integrity verification. A corrupted decompressed image will silently fail to boot with no actionable error.

Log the actual guest console output on failure — When coworkd never starts, there's no diagnostic information from inside the VM. Capturing early kernel/init output (even via serial console) would make failures like this diagnosable without manual log archaeology.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce
Have a working Cowork workspace on Claude Desktop (pre-update)
Allow Claude Desktop to auto-update (the update received on Feb 7, 2026 ~5-7 PM EST)
After update, attempt to launch Cowork / "Set up workspace"
Observe the workspace spinner, followed by the VPN error after ~60 seconds
Note that quitting/relaunching the app and even rebooting does not resolve the issue
Note that reinstalling the Claude Desktop .dmg does not resolve the issue (VM bundle files at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/ are not replaced)
To resolve: Manually delete the VM bundle and relaunch:

rm -rf ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle

Note: This is not reliably reproducible on demand since it was triggered by a specific auto-update. The core issue is that the updated app shipped with or produced a VM image that the guest OS cannot boot from, and there is no recovery path in the UI.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

cc_version=2.1.34

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

VM Bundle version (pre-failure): fc96f5bc6a7aeee6e651437eba3c76d0fe9a16f3 (from node log)

VM Configuration at time of failure:

CPUs: 4
Memory: 4 GB
Network: VZVmnetNetworkDeviceAttachment (shared mode), macOS 26+
rootfs.img: 10.7 GB (decompressed)
sessiondata.img: 316 MB
Additional context: The issue was diagnosed by an Opus 4.6 Claude Code session running alongside the broken Cowork instance, by reading the logs at ~/Library/Logs/Claude/cowork_vm_node.log, cowork_vm_swift.log, and coworkd.log. Happy to provide full log files if needed.