[BUG] Cowork VM: guest_vsock_connect times out (60 s) on Intel Mac after update to 1.32352.1 — bare workspace connects, attaching a Drive-synced folder tips every boot over the timeout

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?

Since auto-updating to Claude Desktop 1.32352.1, the Cowork Linux workspace (VM) fails to start on my Intel Mac. The VM itself boots (logs show "Linux VM started successfully"), but the next step — guest_vsock_connect — never completes; after exactly 60 seconds the app logs "VM connection timeout after 60 seconds," tears the VM down, and retries in a loop. During bundle rebuilds the app quits and relaunches itself as part of this loop. Cloud sessions show "Workspace unavailable / failed to start" for every bash tool call; only stage/commit file transfer works.

Key isolation finding: after a clean reboot with only Claude running, the workspace DID boot and connect with no folders attached (tools returned "No folders are connected to this device" — i.e., the guest answered). The moment I re-attached my Google Drive–synced folder, the workspace restarted with the share mounted and every subsequent boot timed out at 60 s again, reproducibly. So the machine sits right at the timeout boundary on this build's slower boot path, and the shared-folder mount tips it over.

Persisted through: full macOS reboot (×2), in-app workspace reinstall, Help → Troubleshooting → Delete Cowork + Clear Cache, manual deletion of the VM bundle (clean 12 GB re-provision), second clean reboot.

What Should Happen?

The Cowork workspace should provision and connect (as it did on the previous app version on this same machine earlier the same day), including with a connected shared folder, and device bash commands should execute in the VM.

Error Messages/Logs

Tool-side error (every bash call): "Workspace unavailable. The isolated Linux environment on this device failed to start." (alternating with "Workspace still starting…")

cowork_vm_swift.log — identical pattern on every attempt: [info] Direct-boot artifacts not present in bundle; using EFI (GRUB) boot [info] VM startup step: vm_boot completed [info] Linux VM started successfully [info] VM startup step: guest_vsock_connect started <no completion — next event is teardown ~60–90 s later> [warn] Timeout waiting for VM to stop (state: 1), proceeding with cleanup

cowork_vm_node.log: [error] [VM:start] Connection timeout, last completed step: vm_boot [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds [error] [networkDiagnostics] Failed to spawn /usr/bin/pgrep (via disclaimer): exited with code 1

coworkd.log (guest console) — guest boots (Ubuntu 22.04, kernel 6.8.0-136-generic, "Apple Virtualization Generic Platform") but crawls with boot-stage stalls: watchdog: BUG: soft lockup - CPU#2 stuck for 956s! [loadkeys:6334] watchdog: BUG: soft lockup - CPU#3 stuck for 259s! [loadkeys:6025] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: (t=898984 jiffies ...) clocksource: timekeeping watchdog on CPU2: hpet wd-wd read-back delay ... clock-skew test skipped!

vzgvisor.log ends at "usernet: calling AcceptBess..." — host network stack waiting for a guest that never arrives.

Steps to Reproduce

Hardware/OS: Intel MacBook Pro (MacBookPro16,1, i7-9750H, 16 GB RAM), macOS 26.6.2 (25G83).
Install/update Claude Desktop to 1.32352.1.
Open a Cowork session and connect a Google Drive–synced folder (Drive for Desktop; folder is a few GB on a ~466 GB volume).
Trigger any tool that needs the Linux workspace (e.g., a bash command from a cloud session via the device bridge).
Observe: VM boots, guest_vsock_connect starts, times out at 60 s, teardown/retry loop; app self-relaunches during bundle rebuilds.
Control test A: clean reboot, launch only Claude, NO folders connected → workspace connects successfully.
Control test B: re-attach the Drive-synced folder → workspace restarts with the share and every boot times out again.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

The version prior to 1.32352 (auto-updated afternoon ET 17 AUG 2026). It ran multiple Cowork VM sessions on this same machine earlier that same day without issue. (Exact prior version number not recorded — the auto-updater replaced it; install history will show it.)

Claude Code Version

Claude 1.32352.1 (6c6aa5) 2026-08-18T00:07:03.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

App: 1.32352.1, Electron 42.9.2, Node 24.18.1, packaged. VM bundle claudevm.bundle present, 12.11 GB, isDownloaded: true; SDK claude-code-vm 2.1.229. 49.6 GB disk free.
Hypothesis: the 1.32352.1 x64 bundle ships without direct-boot artifacts, so Intel hosts fall back to the slower EFI/GRUB boot path ("Direct-boot artifacts not present in bundle"); on 2019-class Intel hardware this sits at the fixed 60 s vsock deadline, and the virtiofs mount of a cloud-synced folder pushes it past it every time.
Suggested fixes: restore x64 direct-boot artifacts; and/or make the guest_vsock_connect timeout adaptive/longer on Intel (e.g., 180 s); and/or attach shared-folder mounts after the vsock connection so a slow mount can't fail the whole boot.
Full Help → Troubleshooting log export attached (main.log, cowork_vm_swift.log, cowork_vm_node.log, coworkd.log, vzgvisor.log, vm-info.json, supported-features-info.json, system-info.txt, gpu-info.json).

Claude-logs-2026-08-18T11-09-23-011Z.zip