[BUG] Cowork VM regression on Intel Mac — guest never starts coworkd after VM bundle update `6d1538ba` → `2a762adf`

Summary

Cowork had been working on this Intel Mac for ~6 months. On 2026-08-18 at 16:35 the app auto-updated the VM bundle from 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a to 2a762adfc2eea13eca0d113a2e6452ff00ae3f62. Since that moment the workspace VM has never started: 17+ consecutive attempts, 0 successes.

The x86 guest kernel boots normally, but guest userspace produces no console output at all and coworkd never starts, so guest_vsock_connect times out after 60s on every attempt.

This is filed as a regression, not a feature request. Issue #20787 ("Cowork Support for Intel Mac") is framed as though x86 was never supported — these logs show it demonstrably worked here across 112 VM starts since 2026-02-20, with the last successful boot at 13:22 on the same day it broke.

Environment

| | |
|---|---|
| Machine | Mac mini, Intel Core i3-8100B @ 3.60GHz (Coffee Lake, x86_64) |
| uname -m | x86_64 (hw.optional.arm64 = 0) |
| macOS | 15.7.7 (24G720) |
| Claude Desktop | 1.32352.1 |
| Guest image | smol-bin.x64.img |
| Network mode | gvisor (unchanged since 2026-02-20) |

Evidence: the bundle version is the only variable

From ~/Library/Logs/Claude/cowork_vm_node.log:

2026-06-17 16:29:23  Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a   → 41 starts, working
2026-08-18 13:22:08  guest_vsock_connect completed                              ← last success
2026-08-18 16:35:51  Bundle version: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62   → 17+ starts, 0 successes

The app itself had already auto-updated to 1.32352.1 at 00:14 that morning and worked fine at 13:22, so the app version is not the variable. The only thing that changed at 16:35 is the VM image.

Failure signature

[VM:steps] vm_boot completed (205ms)
[VM:steps] guest_vsock_connect started
[VM:start] Still waiting for guest connection... 50094ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: vm_boot
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

Guest console (coworkd.log, kernel on hvc1) is healthy right up to the init handoff, then silent forever:

[    1.192679] Run /init as init process
[    1.786247] xor: automatically using best checksumming function   avx
[  271.505658] clocksource: timekeeping watchdog on CPU0: ...      ← 4.5 min later, nothing in between

The VM process meanwhile spins at ~115% CPU for the whole timeout window, which reads more like a guest binary failing to exec in a loop than a process blocked on I/O. Every subsequent retry then also fails to stop the previous VM (Timeout waiting for VM to stop (state: 1), proceeding with cleanup, 60s each), so the app loops every ~5 minutes indefinitely.

Ruled out

• Corrupt local image — zstd -t rootfs.img.zst passes; zstd -dc rootfs.img.zst | cmp - rootfs.img tails match. Mid-file differences are just the guest writing to the image during boot attempts (rootfs.img mtime advances each try).
• Corrupt local state — full rm -rf of claudevm.bundle plus a clean re-download of the same bundle version fails identically. This is the fix that worked in #24070; it does not apply here. Fresh sessiondata.img, machineIdentifier, gvisorMacAddress, no efivars.fd.
• In-app "reinstall the workspace" — ineffective by design here: it logs Reinstall files deleted (sessiondata.img and compressed cache preserved), and it auto-runs once on first failure anyway.
• Disk space — fails identically at 95% full (13 GiB free) and at 81% full (42 GiB free).
• gvisor networking (#24933) — gvisor has been the mode since 2026-02-20 across 112 mostly-successful starts, so it is not the differentiator.
• VPN / Tailscale — see below.

Secondary bug: the VPN error is a false positive

While a VPN interface exists, the failure is reported as:

Your network traffic may be routing through a VPN, which can interfere with Claude's workspace.

This is misleading. guest_vsock_connect is an AF_VSOCK virtio socket between host and guest and never touches IP, so a VPN cannot break it. The diagnostics simply list every utun present (utun0–utun7) plus Tailscale — which had been running for months across all the successful boots. Quitting Tailscale entirely changed nothing except that the banner then showed the real message, VM connection timeout after 60 seconds.

The VPN text sent me down a long dead end, and #24070 reports the same false positive on macOS. Suggest gating it on something stronger than "a utun exists", or dropping it in favour of the actual error.

Expected

Either the VM image continues to support x86_64 guests, or — if Intel support is being dropped deliberately — the app should say so plainly instead of timing out and blaming the user's VPN.

Related

#20787 (Intel support, framed as never-supported), #24070 (same false-positive VPN error + guest never starts coworkd, macOS), #24933 (gvisor cascading boot failures), #67066 (same signature across two bundle versions, Windows ARM64).