Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] [Cowork] Threads stuck in "Starting up" / "Pondering" — VM virtual network never initializes (vzgvisor AcceptBess hangs) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#45396•Fetched 2026-04-09 08:06:23
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
kaleb-pattkaleb-patt
Participants
github-actions[bot]github-actions[bot]kaleb-pattkaleb-patt
Timeline (top)
labeled ×3closed ×1commented ×1

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.

Error Message

[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 [warn] [Keepalive] Ping failed: Keep-alive ping timed out ← fails immediately after

Error Messages/Logs

[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 [warn] [Keepalive] Ping failed: Keep-alive ping timed out ← fails immediately after

Root Cause

Root Cause (from logs)

Fix Action

Workaround

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

Code Example

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

---

[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

---

[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

---

[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

---

### 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
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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

extent analysis

TL;DR

The issue can be temporarily resolved by performing a full Mac reboot, which allows the VM networking to function correctly for a short period.

Guidance

  • The problem seems to be related to the AcceptBess function in the vzgvisor process, which is hanging and preventing the VM's NIC from routing traffic.
  • The issue is likely caused by a change in the Virtualization.framework's usernet / Bess packet processing API or behavior in macOS 26.4 (25E246).
  • To troubleshoot, try to isolate the issue by checking the system logs for any errors related to the vzgvisor process or the Virtualization.framework.
  • Consider downgrading to a previous version of macOS or waiting for an update that addresses this issue.

Example

No code snippet is provided as the issue seems to be related to a specific system configuration and framework behavior.

Notes

The issue is specific to macOS 26.4 (25E246) and may be resolved by a future update. The temporary workaround of performing a full Mac reboot may not be a reliable solution.

Recommendation

Apply the workaround of performing a full Mac reboot to temporarily resolve the issue, as upgrading to a fixed version is not currently available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#mixed precision#training loop#device allocation#model download

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING