[BUG] Cowork API connection issue + Coworke Tab disappears on restart

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25136
2. https://github.com/anthropics/claude-code/issues/25142
3. https://github.com/anthropics/claude-code/issues/25034

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

What's Wrong?

Cowork workspace fails to connect to Claude API on Windows 11 Pro. VM starts successfully, SDK installs, but API is unreachable. This matches issues #24945, #25024, #24918, #25205.

Environment

• OS: Windows 11 Pro 24H2 (Build 26200)
• Claude Desktop: 1.1.2685 (MSIX)
• Claude Code VM SDK: 2.1.34
• Subscription: Max
• CPU: Intel i7-11800H
• RAM: 32GB
• Hyper-V: Enabled (vmms running)
• cowork-vm-nat adapter: UP, 172.16.0.1/24
• Host API connectivity: api.anthropic.com:443 reachable (160.79.104.10)

Steps to Reproduce

1. Open Claude Desktop 1.1.2685 on Windows 11 Pro
2. Navigate to Cowork tab
3. Workspace setup begins, VM starts, network connects
4. Error: "Failed to start Claude's workspace — Can't reach the Claude API"

VM Log (cowork_vm_node.log)

2026-02-12 11:27:24 [info] [VM] Network status: CONNECTED
2026-02-12 11:27:28 [info] [VM:steps] sdk_install completed (4171ms)
2026-02-12 11:27:29 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-12 11:27:53 [info] [VM] API reachability: UNREACHABLE
2026-02-12 11:27:53 [warn] [VM:network] API is unreachable

CSP Block Evidence (claude.ai-web.log — 193 occurrences)

Refused to connect to 'https://a-api.anthropic.com/v1/m' because it violates the following Content Security Policy directive: "connect-src 'self' https://api.segment.io https://*.segment.io https://*.segment.com https://a-cdn.anthropic.com https://*.google.com https://*.facebook.com https://*.doubleclick.net"

a-api.anthropic.com is missing from the connect-src directive.

Network Diagnosis

• NetNat: Cannot create — WinNAT slot occupied by Default Switch (Windows limitation: only one NetNat instance allowed)
• IP Forwarding: Manually enabled on cowork-vm-nat and Wi-Fi
• DNS: Manually set to 192.168.2.1 on cowork-vm-nat (was empty)
• Firewall: Inbound/Outbound rules added for 172.16.0.0/24 port 443
• Norton VPN adapters: Present but inactive

Despite all manual network fixes, the CSP block at the Electron level prevents API communication regardless.

Root Causes Identified

1. CSP header missing a-api.anthropic.com in Electron's connect-src (reportedly fixed on macOS but not Windows)
2. VM egress proxy not implemented on Windows (macOS uses vsock-based MITM proxy for VM→API traffic)
3. macOS diagnostic commands hardcoded (/sbin/ifconfig, /usr/sbin/scutil) causing ENOENT on Windows

What I've Already Tried (none resolved the issue)

• Full Hyper-V enabled with vmms/vmcompute running
• IP Forwarding enabled on both interfaces
• DNS manually configured on cowork-vm-nat
• Windows Firewall rules for 172.16.0.0/24
• Attempted NetNat creation (blocked by Default Switch)
• Attempted ICS (COM-based, failed)
• Port proxy configuration
• Claude Desktop restart (multiple times)

Expected Behavior

Cowork workspace should successfully connect to Claude API after VM startup and SDK installation.

Related Issues

• #24945 — Same symptom (VM boots, API unreachable)
• #25024 — CSP block identified
• #24918 — Windows Cowork general connection failure
• #25205 — API connection + Cowork tab disappears on restart
• #24962 — DNS/NAT/sessiondata analysis

My debug efforts (with Claude) led to the following summary that Claude recommended I share here as potentially advancing understanding the issue beyond what's already reported.

---

Cowork Windows: MITM Proxy Never Starts — Root Cause Analysis

Environment

• Windows 11 Pro (Build 26200), x64
• Claude Desktop: 1.1.2998 (MSIX package)
• Hyper-V: Fully enabled (vmms running)
• Subscription: Pro
• VPN: Tailscale installed but not running
• Network: Wi-Fi (Intel Wi-Fi 6E AX211)

Summary

After extensive debugging, the root cause of the API unreachable error on Windows is that Claude Desktop does not start its MITM proxy. The VM boots, HNS networking is configured correctly, but there is no proxy listening for the VM to route API traffic through.

Evidence

VM startup succeeds, API check fails

2026-02-13 08:19:09 [info] [VM] Network status: CONNECTED
2026-02-13 08:19:13 [info] [VM:start] Startup complete, total time: 16621ms
2026-02-13 08:19:14 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-13 08:19:42 [info] [VM] API reachability: UNREACHABLE
2026-02-13 08:19:42 [warn] [VM:network] API is unreachable

The log also contains an earlier entry confirming the proxy architecture is expected:

2026-02-12 13:28:00 [info] [Spawn:vm] id=ba4808f6-... OAuth token approved with MITM proxy

HNS NAT is correctly configured

Name              Type  Subnets
----              ----  -------
cowork-vm-nat     NAT   172.16.0.0/24

Host-side adapter has 172.16.0.1/24. The VM gets an IP in this range and can reach the host (network status goes to CONNECTED).

Claude Desktop has zero TCP listeners

With Claude Desktop running (8 processes), none of them listen on any TCP port:

$claudeIds = (Get-Process claude*).Id
Get-NetTCPConnection -State Listen |
    Where-Object { $_.OwningProcess -in $claudeIds }
# Returns: empty

Nothing on 172.16.0.1, nothing on 127.0.0.1, nothing on 0.0.0.0. The MITM proxy that should broker VM-to-API traffic is not starting.

For comparison, on macOS (#18854) the proxy was confirmed running on a localhost port (visible via lsof) and was returning 403 Forbidden with X-Proxy-Error: blocked-by-allowlist. On Windows, the proxy doesn't exist at all.

CSP also blocks the API endpoint (separate issue)

The Electron webview CSP does not include a-api.anthropic.com:

Connecting to 'https://a-api.anthropic.com/v1/m' violates the following
Content Security Policy directive: "connect-src 'self' https://api.segment.io
https://*.segment.io https://*.segment.com https://a-cdn.anthropic.com
https://*.google.com https://*.facebook.com https://*.facebook.net
https://*.doubleclick.net"

This may be a secondary issue or may be the same underlying problem if the proxy is supposed to handle this internally.

What doesn't help

• Enabling full Hyper-V (was previously only Virtual Machine Platform) — no change
• Deleting VM bundle and letting it re-download — no change
• New-NetNat — fails because HNS already owns the NAT correctly
• No VPN running, no system proxy, no firewall blocks, host can reach api.anthropic.com fine on both IPv4 and IPv6

Conclusion

The Windows Cowork implementation appears to be missing the proxy startup code path. The VM networking (HNS NAT, adapter, routing) works correctly, but there is no proxy for the VM to send API requests through. On macOS this proxy exists (even if its allowlist is misconfigured per #18854/#18006). On Windows it simply never starts.

Steps to Reproduce

1. Install Claude Desktop 1.1.2998 on Windows 11 Pro with Hyper-V enabled
2. Open Cowork tab, let VM start
3. Observe "Can't reach the Claude API from Claude's workspace"
4. Verify with Get-NetTCPConnection that Claude has no TCP listeners

After more debugging and looking at #24945, Claude prepped this update of a workaround that got Claude CoWork functional on my Win11 Pro laptop.

---

Confirmed: Stale DNS from disconnected adapter — same root cause as #24945 (Update 2)

Environment

• Windows 11 Pro (Build 26200), x64
• Claude Desktop: 1.1.2998 (MSIX)
• Hyper-V: Fully enabled
• Active network: Wi-Fi (Intel Wi-Fi 6E AX211)
• Subscription: Pro

Root Cause

After extensive debugging, confirmed the same root cause described in #24945's "Update 2 — RESOLVED with workaround" by @chrishadley1983.

A disconnected Ethernet adapter (Realtek PCIe GbE) retained stale DNS servers (71.10.216.1, 71.10.216.2) from a previous network. cowork-svc.exe picked up DNS from this disconnected adapter instead of the active Wi-Fi adapter (172.20.10.1). The VM received unreachable DNS servers, couldn't resolve api.anthropic.com, and reported UNREACHABLE.

Key evidence: The cowork adapter had zero IPv4 DNS servers — only the default fec0:: IPv6 placeholders:

InterfaceAlias            AddressFamily ServerAddresses
vEthernet (cowork-vm-nat)          23  {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
vEthernet (cowork-vm-nat)           2  {}   <-- no IPv4 DNS

Meanwhile the disconnected Ethernet adapter still advertised DNS:

Ethernet (Disconnected)    2  {71.10.216.1, 71.10.216.2}

Additional findings from debugging

Before identifying the DNS issue, I also confirmed:

1. HNS NAT is correctly configured — Get-HnsNetwork shows cowork-vm-nat as type NAT on 172.16.0.0/24. Get-NetNat returns empty because HNS manages the NAT separately from WinNAT cmdlets (so New-NetNat fails with a misleading "duplicate name" error — this is expected).

1. Claude Desktop starts no TCP listeners — Get-NetTCPConnection -State Listen filtered by Claude process IDs returns empty. The MITM proxy referenced in the logs (OAuth token approved with MITM proxy) does not expose a TCP listener on Windows, unlike the macOS implementation where it's visible via lsof. The proxy may use a different IPC mechanism on Windows (named pipes, vsock) or may not start at all when the VM's API health check fails early.

1. CSP blocks a-api.anthropic.com in claude.ai-web.log:

``
Connecting to 'https://a-api.anthropic.com/v1/m' violates the following
Content Security Policy directive: "connect-src 'self' https://api.segment.io ..."
``
This appears to be a separate issue from the VM networking (possibly already addressed by the #18006 fix).

Workaround applied

Following the same approach from #24945 Update 2:

Disable-NetAdapter -Name "Ethernet" -Confirm:$false
Get-Process claude* | Stop-Process -Force
# Stop CoworkVMService, remove HNS cowork-vm-nat network
# Relaunch Claude Desktop

Recommendation for Anthropic

This is the same bug as #24945 and #25144 and #25088. cowork-svc.exe should:

1. Only enumerate connected/active adapters when selecting DNS configuration for the VM
2. Prefer the adapter with the default gateway as the DNS source
3. At minimum, validate that selected DNS servers are reachable before passing them to the VM

This would be a straightforward fix in the adapter enumeration logic and would resolve the issue for all users with disconnected adapters retaining stale DHCP leases.

This should have been fixed in the same version that fixed #24918, we switched out networking to a system that doesn't use HNS provided DNS settings and should use whatever your active network adapter is configured to use.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.