[BUG] Cowork workspace VM never completes guest_vsock_connect on Intel Mac after Aug 18 bundle update; error message incorrectly blames VPN

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?

The Cowork workspace VM had been working reliably for ~18 days on this machine. On Aug 18 the app re-downloaded the VM bundle, and since then the workspace never starts.

The VM boots — kernel loads, /init runs, PF_VSOCK is registered — but the guest_vsock_connect startup step never completes. After ~3 minutes the app gives up, stops the VM (the VM does not respond to requestStop, producing Timeout waiting for VM to stop (state: 1)), and restarts it. This loops indefinitely every 3–4 minutes.

Two separate problems here:

The VM never becomes ready. Likely related to point 3 below.
The user-facing error message is wrong. It reports a VPN problem for what is actually a VM boot failure — see below.
Direct-boot artifacts not present in bundle; using EFI (GRUB) boot is logged on every start, even though vmlinuz and initrd are both present in the bundle. The app falls back to the slower GRUB path unnecessarily. On slow hardware this may be what pushes boot past the 3-minute timeout.
Environment
Model: MacBookPro15,4 (13-inch, 2019)
CPU: Quad-Core Intel Core i5 @ 1.4 GHz (x86_64, sysctl.proc_translated empty — not Rosetta)
RAM: 8 GB
macOS: 15.7.9 (24G830)
Claude Desktop: 1.32352.1
Disk: 63 GB free
VM config: memoryGB=4, cpuCount=auto, networkMode=gvisor
Steps to reproduce
Enable Claude Code in Claude Desktop on the machine above (Cowork had been working fine before this).
Let the app re-download the VM bundle.
Open the workspace.
VM boot loop begins and never resolves.

Reproduces 100% of the time, including immediately after a clean reboot with only Claude running and 69% system memory free.

Expected behavior

The workspace starts, as it did for the previous 18 days on the same hardware.

Actual behavior

Banner: "Failed to start Claude's workspace — Your network traffic may be routing through a VPN, which can interfere with Claude's workspace."

The VPN message is misleading

main.log shows this exact string emitted on every failed startVM, apparently regardless of the actual failure cause. There is no VPN involvement in this failure:

vzgvisor.log shows the network stack starting cleanly with no errors, then waiting at calling AcceptBess... for a guest connection that never arrives.
The failure is downstream of networking entirely — the guest agent never connects over vsock.
The failure reproduces identically with the VPN disconnected.

This message sent me down a multi-hour dead end investigating routing tables and split tunneling. Suggest surfacing the actual failing startup step instead.

Logs

cowork_vm_swift.log — the loop (identical block repeats every 3–4 min):

[VM] 2026-08-18 16:02:54 [info] startVM called ... memoryGB=4 cpuCount=auto networkMode=gvisor
[VM] 2026-08-18 16:02:54 [info] VM startup step: stop_existing_vm completed
[VM] 2026-08-18 16:02:54 [info] Direct-boot artifacts not present in bundle; using EFI (GRUB) boot
[VM] 2026-08-18 16:02:55 [info] Found smol-bin image at /Applications/Claude.app/Contents/Resources/smol-bin.x64.img
[VM] 2026-08-18 16:02:55 [info] Gvisor usernet started
[VM] 2026-08-18 16:02:55 [info] VM startup step: create_network completed
[VM] 2026-08-18 16:02:55 [info] VM startup step: create_vm_config completed
[VM] 2026-08-18 16:02:55 [info] VM startup step: vm_boot started
[VM] 2026-08-18 16:02:55 [info] Linux VM started successfully
[VM] 2026-08-18 16:02:55 [info] VM startup step: vm_boot completed
[VM] 2026-08-18 16:02:55 [info] VM startup step: guest_vsock_connect started
<-- never completes; next startVM ~3 min later

Earlier iterations also show:

[VM] 2026-08-18 15:38:02 [warn] Timeout waiting for VM to stop (state: 1), proceeding with cleanup

vzgvisor.log (entire file — network side is healthy):

level=info msg="usernet: starting with sockFD=200"
level=info msg="usernet: vmMAC=76:82:3b:90:df:c2"
level=info msg="usernet: virtual network created successfully"
level=info msg="usernet: net.Conn created from socket, type=*net.UnixConn"
level=info msg="usernet: network stack started successfully"
level=info msg="usernet: calling AcceptBess..."

coworkd.log — kernel boots fine, then nothing:

[ 1.383390] Run /init as init process
[ 1.480171] virtio_net virtio0 enp0s1: renamed from eth0
[ 1.480304] NET: Registered PF_VSOCK protocol family
[ 1.513356] [drm] Initialized virtio_gpu 0.1.0 0 for 0000:00:0a.0 on minor 0
[ 1.935795] async_tx: api initialized (async)
[ 98.538546] clocksource: timekeeping watchdog on CPU0: hpet retried 2 times before success
[ 203.472914] hrtimer: interrupt took 12460197 ns

No further guest output after async_tx at ~2s. Note the 12.5-second interrupt handling at 203s — the guest appears to be running but making no progress.

main.log:

2026-08-18 16:03:55 [warn] [ScheduledTasks] startVM failed: Error: Your network traffic may be routing through a VPN, which can interfere with Claude's workspace.
2026-08-18 15:10:42 [warn] [HostLoop] VM boot failed; bash proxy unavailable: Your network traffic may be routing through a VPN...
at kdn (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-Ca2l_6Tr.js:13:2640805)

Host memory is not the constraint:

2026-08-18 16:05:54 [info] [process-memory] tree_rss_sum=1062MB sys_free=2555MB/8192MB
Bundle contents

vmlinuz and initrd are present, yet direct-boot artifacts are reported missing:

-rw------- 1 natalia staff 0 Aug 18 11:17 .auto_reinstall_attempted
-rw------- 1 natalia staff 28165330 Aug 18 11:19 initrd
-rw------- 1 natalia staff 27816400 Aug 18 11:16 initrd.zst
-rw------- 1 natalia staff 10737418240 Aug 18 15:42 rootfs.img
-rw------- 1 natalia staff 1286740082 Aug 18 11:16 rootfs.img.zst
-rw-r--r-- 1 natalia staff 10737418240 Aug 18 11:13 sessiondata.img
-rw------- 1 natalia staff 15014280 Aug 18 11:19 vmlinuz
-rw------- 1 natalia staff 14761727 Aug 18 11:16 vmlinuz.zst
-rw-r--r-- 1 natalia staff 17 Aug 3 17:52 gvisorMacAddress
-rw-r--r-- 1 natalia staff 70 Aug 3 17:52 machineIdentifier
-rw-r--r-- 1 natalia staff 11 Aug 17 09:43 vmIP

machineIdentifier dates from Aug 3 (original workspace creation); vmIP from Aug 17 09:43 (last successful boot); the images were re-downloaded Aug 18 11:16 and unpacked 11:19 — the point at which the workspace stopped working.

Things already tried
Full reboot, then launching only Claude with no other apps — same result.
Full quit (⌘Q) and relaunch — same result.
Manual bundle deletion / re-download — same result.
.auto_reinstall_attempted marker is present, so the app's own automatic reinstall has already been consumed without success.
Verified the VPN is not involved (see above).

What Should Happen?

The workspace starts, as it did for the previous 18 days on the same hardware.

Error Messages/Logs

[VM] 2026-08-18 16:02:54 [info] startVM called ... memoryGB=4 cpuCount=auto networkMode=gvisor
[VM] 2026-08-18 16:02:54 [info] VM startup step: stop_existing_vm completed
[VM] 2026-08-18 16:02:54 [info] Direct-boot artifacts not present in bundle; using EFI (GRUB) boot
[VM] 2026-08-18 16:02:55 [info] Found smol-bin image at /Applications/Claude.app/Contents/Resources/smol-bin.x64.img
[VM] 2026-08-18 16:02:55 [info] Gvisor usernet started
[VM] 2026-08-18 16:02:55 [info] VM startup step: create_network completed
[VM] 2026-08-18 16:02:55 [info] VM startup step: create_vm_config completed
[VM] 2026-08-18 16:02:55 [info] VM startup step: vm_boot started
[VM] 2026-08-18 16:02:55 [info] Linux VM started successfully
[VM] 2026-08-18 16:02:55 [info] VM startup step: vm_boot completed
[VM] 2026-08-18 16:02:55 [info] VM startup step: guest_vsock_connect started
        <-- never completes; next startVM ~3 min later

Steps to Reproduce

1. On a MacBookPro15,4 (Intel i5 1.4 GHz, 8 GB RAM, macOS 15.7.9) with a working Cowork workspace, enable Claude Code in Claude Desktop 1.32352.1.
2. Let the app re-download the VM bundle (this happened automatically on Aug 18 at 11:03).
3. Open the workspace.
4. Observe the banner "Failed to start Claude's workspace" with the VPN message.
5. Check ~/Library/Logs/Claude/cowork_vm_swift.log — "VM startup step: guest_vsock_connect started" appears but never completes; startVM repeats every 3-4 minutes indefinitely.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.32352.1

Claude Code Version

1.32352.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_