[BUG] [Cowork] Threads stuck in "Starting up" / "Pondering" — VM virtual network never initializes (vzgvisor AcceptBess hangs)

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?

[Cowork] Threads stuck in "Starting up" / "Pondering" — VM virtual network never initializes (vzgvisor AcceptBess hangs)`

Body:

Environment

• App: Claude Desktop 1.1062.0 (b81bcd) — 2026-04-06
• macOS: 26.4 (25E246) — developer beta
• Hardware: Apple M4

Description

Cowork threads consistently get stuck in "Starting up" (sometimes transitioning to "Pondering a complex response") and never resolve. The issue is in the VM's virtual network initialization — the packet processor never starts, so the VM's NIC never comes up and the host's keepalive connection times out indefinitely.

Already tried: Clear Cache and Restart, full app quit + relaunch, disabling VPN.

Root Cause (from logs)

~/Library/Logs/Claude/vzgvisor.log — always ends here, never proceeds:

usernet: starting with sockFD=118
usernet: vmMAC=7a:3d:2a:6d:2c:7f
usernet: virtual network created successfully
usernet: net.Conn created from socket, type=*net.UnixConn
usernet: network stack started successfully
usernet: calling AcceptBess...        ← stuck here every time

~/Library/Logs/Claude/coworkd.log — VM starts but route never becomes available (9 out of 9 recent startups):

[coworkd] waiting for IPv4 route
[coworkd] IPv4 route not yet available, emitting NOT_CONNECTED
[coworkd] configuring static IP on enp0s1: 172.16.10.3/24 gateway=172.16.10.1 dns=172.16.10.1

IPv4 route only became available on 2 occasions (Apr 6 13:27, Apr 8 17:29) — both suspected to be right after a full Mac reboot.

~/Library/Logs/Claude/cowork_vm_node.log — host-side keepalive fails continuously once the NIC is stuck:

[warn] [Keepalive] Ping failed: Keep-alive ping timed out   ← every 7 seconds, indefinitely
[warn] [Keepalive] Ping failed: Keep-alive ping timed out
[warn] [Keepalive] Ping failed: Keep-alive ping timed out

Also observed: multiple rapid postConnect / SDK install cycles as the app retries:

[info] [startVM] VM already connected
[info] [postConnect] Installing SDK: version=2.1.92
[warn] [Keepalive] Ping failed: Keep-alive ping timed out    ← fails immediately after
[info] [startVM] VM already connected                        ← retries
[info] [postConnect] Installing SDK: version=2.1.92

What's Happening

The vzgvisor process starts the usernet virtual network stack successfully but hangs on AcceptBess (the packet processing loop). Because the packet processor never starts:

• The VM's NIC (enp0s1) gets a static IP assigned but can't route traffic
• coworkd inside the VM emits NOT_CONNECTED and waits
• The host's keepalive channel (which goes through the virtual NIC) times out
• The RPC layer still reports "connected" (different vsock transport), masking the failure

Suspected Cause

macOS 26.4 (25E246) is a pre-release OS. A change in Virtualization.framework's usernet / Bess packet processing API or behavior likely causes AcceptBess to block indefinitely instead of returning a connection. The issue persists across app restarts but appears to clear after a full Mac reboot (state not preserved across OS restart).

Workaround

Full Mac reboot very temporarily restores VM networking. Enough for 1 or two messages. App-level restart / Clear Cache does not fix it.

What Should Happen?

VM should boot up successfully and i should be able to use cowork

Error Messages/Logs

### Root Cause (from logs)

**`~/Library/Logs/Claude/vzgvisor.log`** — always ends here, never proceeds:

usernet: starting with sockFD=118
usernet: vmMAC=7a:3d:2a:6d:2c:7f
usernet: virtual network created successfully
usernet: net.Conn created from socket, type=*net.UnixConn
usernet: network stack started successfully
usernet: calling AcceptBess...        ← stuck here every time


**`~/Library/Logs/Claude/coworkd.log`** — VM starts but route never becomes available (9 out of 9 recent startups):

[coworkd] waiting for IPv4 route
[coworkd] IPv4 route not yet available, emitting NOT_CONNECTED
[coworkd] configuring static IP on enp0s1: 172.16.10.3/24 gateway=172.16.10.1 dns=172.16.10.1

IPv4 route only became available on 2 occasions (Apr 6 13:27, Apr 8 17:29) — both suspected to be right after a full Mac reboot.

**`~/Library/Logs/Claude/cowork_vm_node.log`** — host-side keepalive fails continuously once the NIC is stuck:

[warn] [Keepalive] Ping failed: Keep-alive ping timed out   ← every 7 seconds, indefinitely
[warn] [Keepalive] Ping failed: Keep-alive ping timed out
[warn] [Keepalive] Ping failed: Keep-alive ping timed out


Also observed: multiple rapid `postConnect` / SDK install cycles as the app retries:

[info] [startVM] VM already connected
[info] [postConnect] Installing SDK: version=2.1.92
[warn] [Keepalive] Ping failed: Keep-alive ping timed out    ← fails immediately after
[info] [startVM] VM already connected                        ← retries
[info] [postConnect] Installing SDK: version=2.1.92


### What's Happening

The `vzgvisor` process starts the usernet virtual network stack successfully but hangs on `AcceptBess` (the packet processing loop). Because the packet processor never starts:
- The VM's NIC (`enp0s1`) gets a static IP assigned but can't route traffic
- `coworkd` inside the VM emits `NOT_CONNECTED` and waits
- The host's keepalive channel (which goes through the virtual NIC) times out
- The RPC layer still reports "connected" (different vsock transport), masking the failure

Steps to Reproduce

Steps to Reproduce

1. Open any Cowork thread
2. Send any message
3. Thread enters "Starting up" for ~60 seconds, then switches to "Pondering a complex response"
4. Never resolves

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

1.1062.0 (b81bcd)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_