[BUG] Cowork fails with Network status: NOT_CONNECTED even when API reachability: REACHABLE

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 fails with Network status: NOT_CONNECTED even when API reachability: REACHABLE

Related issues:

• #25513 — VPN / NAT architecture incompatibility with Cowork seems related in spirit, but my case is distinct because API reachability is reported as REACHABLE in the same startup attempt. ([#25513](https://github.com/anthropics/claude-code/issues/25513))
• #24070 — misleading VPN attribution / guest startup confusion also seems related, but in my case guest_vsock_connect completes successfully. ([#24070](https://github.com/anthropics/claude-code/issues/24070))

Environment

• macOS
• Claude Desktop / Cowork
• Clash Verge on host
• Tailscale installed but not running during reproduction

Summary

Cowork startup fails in my environment because the VM remains in NOT_CONNECTED state, even though API reachability is reported as REACHABLE in the same startup attempt.

This does not look like a basic outbound connectivity failure. It looks more like Cowork's network-state detection or startup state machine is getting stuck.

Key evidence

From the same startup attempt:

```text id="5htqhz"
[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
[VM] Network status: NOT_CONNECTED
[VM] API reachability: REACHABLE
[VM:network] Not connected, will show error in 30000ms if not resolved

Also:

```text id="hy844g"
[VM:steps] guest_vsock_connect completed
[VM] Sent static IP assignment: ip=172.16.10.3/24 gateway=172.16.10.1

Expected

If API reachability is already REACHABLE, Cowork should either:

• transition out of NOT_CONNECTED, or
• continue startup instead of timing out

Actual

Cowork stays in NOT_CONNECTED and fails after timeout.

Notes

• This reproduces even when Tailscale is not running.
• VM boot and vsock connection both succeed.
• Static IP assignment succeeds.
• The failure appears to happen after vm_boot, during Cowork's network validation / readiness phase.

Why I think this is a distinct bug

My case seems different from a pure VPN-routing failure because the VM can already reach the API according to Cowork's own logs (API reachability: REACHABLE), yet startup still fails because network state remains NOT_CONNECTED.

That makes this look less like “API is unreachable” and more like a mismatch or race inside Cowork's network readiness detection.

What Should Happen?

Cowork should finish starting successfully once the VM is up and API reachability is REACHABLE, instead of staying in NOT_CONNECTED and timing out.

Error Messages/Logs

Steps to Reproduce

1. Launch Claude Desktop on macOS.
2. Start Cowork.
3. Let the workspace boot normally.
4. In logs, observe:

• guest_vsock_connect completed
• static IP assignment to 172.16.10.3/24
• Network status: NOT_CONNECTED
• API reachability: REACHABLE

1. Wait for the startup timeout window.
2. Cowork fails instead of transitioning out of NOT_CONNECTED.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.1.8629 (befdfc) 2026-03-24T22:13:01.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_