›_ Claude Code Issues
Claude Code Issues / #87644

[BUG]

Status Fixed / completed
Reported on v2.1.229
Maintainer reply None cached
Activity 0 comments · opened Aug 18, 2026 · closed Aug 25, 2026

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?

[BUG] Cowork workspace VM hangs at guest_vsock_connect — regression from 1.30096.5 → 1.32352.x (Intel Mac)

Summary

After the auto-update from 1.30096.5 to 1.32352.0 the Cowork workspace VM no longer starts. The VM boots, the guest kernel runs, but the guest agent never establishes the vsock connection. The host times out after 60 s and retries in a loop.

The regression boundary is exact and reproducible from the logs: the last successful session ended at 01:55 local, the update installed at 02:02, the first failed start was at 02:05. Every start since then has failed identically — roughly 40 attempts, zero Guest connected.

The error surfaced to the user is misleading (see "Misleading error message" below).

Environment

| | |
|---|---|
| App version (broken) | 1.32352.1 (regression introduced in 1.32352.0) |
| App version (last working) | 1.30096.5 |
| Electron | 42.9.2 |
| SDK / CCD | 2.1.229 |
| OS | macOS 15.6, Build 24G517, Darwin 24.6.0 |
| Hardware | Intel Core i5-8500 @ 3.00 GHz, 6 cores, 32 GB RAM |
| Architecture | x64 (Intel Mac, Universal build) |
| Guest image | smol-bin.x64.img |
| Guest kernel | 6.8.0-136-generic (fresh bundle); 6.8.0-94-generic before |
| Network mode | gvisor user-mode networking |
| Free disk | 878 GB |

Timeline (from main.log)

2026-08-18 01:53:49  last successful session (SDK installed, processes spawned)
2026-08-18 01:56:16  [updater] Checking for updates
2026-08-18 01:56:16  [updater] Found an update, downloading
2026-08-18 01:56:44  [updater] Update downloaded and ready to install { releaseName: 'Claude 1.32352.0' }
2026-08-18 02:01:30  beforeQuitForUpdate handler fired, going down for update
2026-08-18 02:02:11  [updater] Version changed since last launch: 1.30096.5 → 1.32352.0
2026-08-18 02:02:12  [updater] Previous update install succeeded (1.30096.5 -> 1.32352.0)
2026-08-18 02:05:35  first failing startVM

Failure signature (cowork_vm_swift.log)

Every start since 02:05 ends the same way:

[VM] 2026-08-18 15:01:05 [info] VM startup step: create_network completed
[VM] 2026-08-18 15:01:05 [info] Configuration created:
[VM] 2026-08-18 15:01:05 [info]   - CPUs: 3
[VM] 2026-08-18 15:01:05 [info]   - Memory: 4GB
[VM] 2026-08-18 15:01:05 [info]   - Boot: EFI (GRUB)
[VM] 2026-08-18 15:01:05 [info] VM startup step: vm_boot started
[VM] 2026-08-18 15:01:05 [info] Linux VM started successfully
[VM] 2026-08-18 15:01:05 [info] VM startup step: vm_boot completed
[VM] 2026-08-18 15:01:05 [info] VM startup step: guest_vsock_connect started
                                 ← no "Guest connected", ever

Corresponding host-side node log:

[VM:start] Still waiting for guest connection... 50067ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: vm_boot

vzgvisor.log stops at the same point on every attempt — the network stack comes up and then waits:

level=info msg="usernet: network stack started successfully"
level=info msg="usernet: calling AcceptBess..."

Guest-side observation (coworkd.log)

The guest kernel boots normally and then goes silent shortly after handing off to init. Last console output of a failing boot:

[    1.110699] Run /init as init process
[    1.186542] virtio_net virtio0 enp0s1: renamed from eth0
[    1.190419] NET: Registered PF_VSOCK protocol family
[    1.207225] [drm] Initialized virtio_gpu 0.1.0 0 for 0000:00:0a.0 on minor 0
[    1.223233] Console: switching to colour frame buffer device 160x50
[    1.629660] clocksource: Switched to clocksource tsc
                ← nothing further

No EXT4-fs mount messages, no systemd output, no guest agent. Kernel command line is root=UUID=991a1505-1160-4e3a-8982-e9e304390d70 ro console=hvc0 console=hvc1 fsck.repair=yes.

What has been ruled out

  • VPN / Tailscale — fully disconnected (menu bar shows "Not Connected"), failure identical.
  • Host reboot — no change.
  • In-app "Reinstall workspace" — no change, identical failure signature before and after.
  • Full manual bundle deletion — ~/Library/Application Support/Claude/vm_bundles moved aside and rebuilt from scratch. Confirmed genuinely new: new MAC (fe:17:77:92:39:d8 → 36:15:0f:3b:56:82) and newer guest kernel (6.8.0-94 → 6.8.0-136). Still fails identically, which rules out image corruption.
  • Disk space — 878 GB free.
  • RAM — 32 GB total, VM requests 4 GB.

Host side is healthy throughout: gvisor network is created, the VM object starts, the guest kernel runs. The failure is entirely on the guest-agent / vsock handshake.

Misleading error message

On every timeout the app reports:

[VM:start] VPN detected during connection failure
Dispatching startup error: Your network traffic may be routing through a VPN,
which can interfere with Claude's workspace.

This appears to be triggered merely by the presence of utun* interfaces. This machine has utun0–utun8 (a mix of macOS-internal and leftover VPN interfaces), so the message fires unconditionally — including with every VPN disconnected. It sent me down a multi-hour dead end before I read the logs.

Suggestion: only surface the VPN hint when the failure is actually network-related. A hang at guest_vsock_connect is a virtio/vsock issue inside the hypervisor and cannot be caused by host DNS, routes, or a VPN.

Additionally, networkDiagnostics repeatedly logs:

Failed to run /usr/bin/pgrep: Error: Failed to spawn /usr/bin/pgrep (via disclaimer):
/Applications/Claude.app/Contents/Helpers/disclaimer exited with code 1

Expected behaviour

The workspace VM starts and the guest connects, as it did on 1.30096.5 on the same machine, same OS, same network setup.

Actual behaviour

guest_vsock_connect never completes. Workspace permanently unavailable. All sandbox-dependent features (document generation via docx/xlsx/pptx/pdf skills, any code execution, data processing) are unusable.

Notes

Possibly related, same failure step reported on other platforms: #67066, #48370, #42784, #47737.

This report is from an Intel Mac running the x64 guest image, which may be a less-exercised path than Apple Silicon. Happy to provide full debug logs or test a build on request.

What Should Happen?

The Cowork workspace VM should boot and the guest agent should establish the vsock connection, so that guest_vsock_connect completes and the workspace becomes available for running code.

This worked reliably on the same machine, same OS and same network configuration on version 1.30096.5, and broke immediately after the auto-update to 1.32352.0. No configuration on my side changed between the last working session (01:55) and the first failure (02:05) other than that update.

Error Messages/Logs

=== User-facing error ===
Failed to start Claude's workspace
VM connection timeout after 60 seconds


=== cowork_vm_swift.log — every start since 02:05, ~40 attempts ===
[VM] 2026-08-18 15:01:05 [info] Using gvisor user-mode networking
[VM] 2026-08-18 15:01:05 [info] Gvisor usernet started
[VM] 2026-08-18 15:01:05 [info] VM startup step: create_network completed
[VM] 2026-08-18 15:01:05 [info] VM startup step: vm_boot started
[VM] 2026-08-18 15:01:05 [info] Linux VM started successfully
[VM] 2026-08-18 15:01:05 [info] VM startup step: vm_boot completed
[VM] 2026-08-18 15:01:05 [info] VM startup step: guest_vsock_connect started
   <-- no "Guest connected", ever


=== cowork_vm_node.log ===
[VM:start] Still waiting for guest connection... 50067ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: vm_boot
[VM:start] VPN detected during connection failure
Dispatching startup error: Your network traffic may be routing through a VPN,
which can interfere with Claude's workspace.
[VM:start] Skipping auto-reinstall (already attempted once)

(the VPN message is a false positive - it fires on any utun* interface;
 this machine has utun0-utun8 and the failure is identical with every
 VPN fully disconnected)

[networkDiagnostics] Failed to run /usr/bin/pgrep: Error: Failed to spawn
/usr/bin/pgrep (via disclaimer): /Applications/Claude.app/Contents/Helpers/disclaimer
exited with code 1


=== vzgvisor.log — stops here on every attempt ===
level=info msg="usernet: virtual network created successfully"
level=info msg="usernet: network stack started successfully"
level=info msg="usernet: calling AcceptBess..."


=== coworkd.log — guest console goes silent right after init ===
[    1.110699] Run /init as init process
[    1.186542] virtio_net virtio0 enp0s1: renamed from eth0
[    1.190419] NET: Registered PF_VSOCK protocol family
[    1.223233] Console: switching to colour frame buffer device 160x50
[    1.629660] clocksource: Switched to clocksource tsc
   <-- nothing further: no EXT4-fs mount, no systemd, no guest agent
kernel cmdline: root=UUID=991a1505-1160-4e3a-8982-e9e304390d70 ro
                console=hvc0 console=hvc1 fsck.repair=yes


=== main.log — regression boundary ===
2026-08-18 01:53:49  last successful session
2026-08-18 01:56:44  [updater] Update downloaded { releaseName: 'Claude 1.32352.0' }
2026-08-18 02:02:11  [updater] Version changed since last launch: 1.30096.5 -> 1.32352.0
2026-08-18 02:05:35  first failing startVM

Steps to Reproduce

Environment: Intel Mac (Core i5-8500, 32 GB RAM), macOS 15.6 (Build 24G517),
Claude Desktop Universal build, x64 guest image (smol-bin.x64.img),
gvisor networking. Paid plan with Cowork enabled.

  1. Run Claude Desktop 1.30096.5 on an Intel Mac and use Cowork.

The workspace VM starts normally and bash commands execute.
(Confirmed working on this machine until 2026-08-18 01:55 local.)

  1. Let the in-app auto-updater install 1.32352.0.

Log: "[updater] Version changed since last launch: 1.30096.5 -> 1.32352.0"

  1. Open any Cowork chat and issue any request that requires the sandbox,

e.g. "run uname -a" or ask for a .xlsx/.pdf to be generated.

  1. The VM boots but never connects. After 60 s:

"Failed to start Claude's workspace - VM connection timeout after 60 seconds"
Log stops at: "VM startup step: guest_vsock_connect started"

  1. Repeat step 3 any number of times - identical failure every time.

~40 consecutive failed starts on this machine, zero successes since the update.

Note: I cannot provide a minimal code example, because no user code is involved.
The failure occurs during VM startup, before any user task runs. It is fully
deterministic on this machine: 100% failure rate after the update, 100% success
rate before it.

Repair paths attempted, all with an identical failure signature:

a) Disconnect Tailscale (menu bar shows "Not Connected") -> no change
b) Reboot the Mac -> no change
c) In-app "Reinstall workspace" -> no change
d) Quit Claude, move ~/Library/Application Support/Claude/vm_bundles aside,
restart so the bundle is rebuilt from scratch -> no change.
Verified the bundle was genuinely new: MAC changed
fe:17:77:92:39:d8 -> 36:15:0f:3b:56:82, guest kernel changed
6.8.0-94-generic -> 6.8.0-136-generic. This rules out image corruption.

Non-factors: 878 GB free disk, 32 GB RAM (VM requests 4 GB), no other
hypervisor or security agent installed.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.30096.5

Claude Code Version

1.32352.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Installation & update problems, Crashes, hangs & freezes

Browse all Claude Code issue topics →