[BUG] Cowork Windows: API UNREACHABLE despite working NAT — MITM proxy not binding to VM gateway (172.16.0.1), multi-IP NIC routing mismatch

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 on Windows boots the VM successfully, reaches CONNECTED state, but always fails with API reachability: UNREACHABLE → ConnectionRefused. Extensive debugging over multiple sessions has identified two distinct root causes not covered by existing issues (#24962, #25136, #25155, #25205, #25474, #25513).

Environment

| Component | Details |
|-----------|---------|
| OS | Windows 11 Pro for Workstations (Build 26200, 25H2) |
| CPU | AMD Ryzen Threadripper PRO 9955WX 16-Cores (32 threads) |
| Claude Desktop | v1.1.3189.0 |
| Subscription | Max |
| Hyper-V | Enabled |
| Virtual Machine Platform | Enabled |
| Windows Hypervisor Platform | Enabled |

Network Configuration (Unusual)

NSi HQ (Intel X710-TL):
  IPv4 Address: 192.168.1.62  ← NAT picks this as ExternalSourceAddress
  IPv4 Address: 192.168.2.62
  IPv4 Address: 192.168.3.62
  Default Gateway: 192.168.3.247  ← Gateway is on .3.x subnet!

vEthernet (cowork-vm-nat): 172.16.0.1/24 (Up)
vEthernet (Default Switch): 172.30.176.1/16 (Up)
Bluetooth: Disconnected
Ethernet 2 (Intel X710-TL #2): Disconnected

3 IP addresses on one NIC — this is a production server-class workstation configuration.

---

Root Cause 1: WinNAT creation silently fails (TCP NAT broken)

Problem

The HNS service creates the cowork-vm-nat network (type: NAT), but New-NetNat fails silently because Windows only allows one NAT network and the Default Switch's hidden ICS NAT conflicts.

Evidence

PS> Get-NetNat
# Returns EMPTY — no NAT rules exist
# Yet HNS network exists and VM gets IP 172.16.0.124

PS> New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
# FAILS: "An attempt was made to create an object and the object name already existed"
# Even though Get-NetNat shows NOTHING

Hidden NAT discovered

PS> Get-NetNatSession
# Shows UDP sessions through hidden NAT "NATA557FDEC-F10E-4607-9C91-277A58227833"
# BUT only UDP (Protocol 17) — NO TCP sessions

The VM can resolve DNS (UDP 53 works through HNS NAT) but cannot make TCP connections (HTTPS/443 fails).

Workaround found

Stop-Service winnat
New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
Start-Service winnat

After this, Get-NetNat shows the rule as Active, and TCP NAT sessions appear:

Protocol: 6 (TCP), InternalPort: various → ExternalPort: 443
ExternalSourceAddress: 192.168.1.62

This needs to be automated by cowork-svc.exe — the service should detect when NAT creation fails and apply this workaround.

---

Root Cause 2: MITM proxy not listening on 172.16.0.1

Problem

Even after fixing NAT (Root Cause 1), API calls still fail with ConnectionRefused. The MITM proxy that the VM needs to connect through does not bind to the cowork-vm-nat interface.

Evidence (from admin PowerShell)

PS> netstat -an | Select-String "172.16"
  TCP    172.16.0.1:139      0.0.0.0:0    LISTENING   # NetBIOS only
  UDP    172.16.0.1:137      *:*                       # NetBIOS
  UDP    172.16.0.1:138      *:*                       # NetBIOS
  UDP    172.16.0.1:1900     *:*                       # SSDP
  UDP    172.16.0.1:51199    *:*
  UDP    172.16.0.1:58874    *:*
  UDP    172.16.0.1:58877    *:*

No MITM proxy listening on 172.16.0.1. Only Windows system services (NetBIOS, SSDP).

PS> netstat -anb | Select-String "claude" -Context 2,0
# All Claude.exe connections are OUTBOUND on 192.168.3.62:
  TCP  192.168.3.62:51982  160.79.104.10:443  ESTABLISHED  [Claude.exe]
  TCP  192.168.3.62:57200  34.36.57.103:443   ESTABLISHED  [Claude.exe]
  TCP  192.168.3.62:64160  18.97.36.9:443     ESTABLISHED  [Claude.exe]

Claude.exe connects out on the physical NIC but nothing listens for inbound VM connections on the cowork network.

The log confirms the proxy initializes:

OAuth token approved with MITM proxy
Spawn succeeded in 656ms

But the VM process then hits ConnectionRefused when trying to reach the API through the proxy.

Multi-IP NAT routing mismatch

NAT sessions show ExternalSourceAddress: 192.168.1.62 but the default gateway is 192.168.3.247. Response packets destined for 192.168.1.62 may not route correctly back since the gateway expects traffic from the .3.x subnet. This could cause the NAT to appear functional (sessions created) while actual TCP connections fail or reset.

---

Root Cause 3: cowork-svc.exe has no network listeners

PS> Get-Process cowork-svc
# PID 11904, running

PS> netstat -ano | findstr 11904
# EMPTY — no listeners, no connections

The Cowork service process has zero network activity. It's not listening on any port and not connected to anything. On macOS this likely works differently (perhaps vsock or a local socket), but on Windows the service appears to not be bridging the VM to the API at all.

---

Timeline & Log Evidence

Phase 1: yukonSilver unsupported (Jan 23 – Feb 10)

2026-01-23 10:46:36 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported)
2026-01-23 10:46:38 [error] [SwiftVM] Failed to load module: Cannot find package '...\resources\@anthropic-ai\claude-swift'

Repeated at every startup. Windows Cowork was not yet released.

Phase 2: Module loads, API unreachable (Feb 11+)

2026-02-11 10:39:25 [info] [VM] Module loaded successfully
2026-02-12 09:05:41 [info] [VM] Network status: CONNECTED
2026-02-12 09:05:46 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-12 09:06:14 [info] [VM] API reachability: UNREACHABLE

Phase 3: After app update to v1.1.2998+ (Feb 13)

2026-02-13 18:24:46 [info] [VM] Network status: CONNECTED
2026-02-13 18:24:51 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-13 18:26:58 [info] [VM] API reachability: UNREACHABLE

Phase 4: Process spawns but API fails (Feb 13, after further updates)

2026-02-13 ... [info] Process "adoring-epic-curie" created
2026-02-13 ... [info] OAuth token approved with MITM proxy
2026-02-13 ... [info] Spawn succeeded in 656ms
... (process runs 28 minutes) ...
2026-02-13 ... [error] API Error: Unable to connect to API (ConnectionRefused)

The VM has NEVER once reached API reachability: REACHABLE across dozens of attempts.

---

What Should Happen

1. cowork-svc.exe should detect and fix WinNAT conflicts — apply the Stop-Service winnat → New-NetNat → Start-Service winnat workaround when NAT creation fails
2. MITM proxy must bind to 172.16.0.1 (the VM gateway) — currently nothing listens there for VM connections
3. Multi-IP NIC support — NAT should use the IP address that shares a subnet with the default gateway (192.168.3.62), not an arbitrary one (192.168.1.62)
4. cowork-svc.exe should have active network listeners — the service currently has zero network connections

Additional Diagnostic Data

IP forwarding is enabled on the VM adapter:

PS> Get-NetIPInterface -InterfaceIndex 11 | Select ifIndex, InterfaceAlias, Forwarding
  11  vEthernet (cowork-vm-nat)  Enabled

Firewall was disabled during testing (no improvement):

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
# No change — API still unreachable

Existing related issues

• #24962 — DNS config + missing sessiondata.vhdx + no NAT (Windows Home)
• #25136 — yukonSilver marked unsupported
• #25155 — NAT creation fails
• #25205 — Cowork tab disappears after API failure
• #25474 — Windows NAT networking
• #25513 — VPN incompatibility with Hyper-V NAT

This report differs from all of the above in that:

• NAT has been manually fixed and confirmed working (TCP + UDP sessions visible)
• The issue persists AFTER NAT fix — pinpointed to MITM proxy not binding to VM gateway
• Multi-IP NIC configuration creates additional NAT routing mismatch
• Full netstat evidence shows zero listeners on 172.16.0.1

Error Messages/Logs

API Error: Unable to connect to API (ConnectionRefused)
[VM] API reachability: UNREACHABLE

Steps to Reproduce

1. Install Claude Desktop on Windows 11 Pro for Workstations with multi-IP NIC
2. Enable Hyper-V, VMP, WHP
3. Open Cowork tab
4. VM boots to CONNECTED but API always UNREACHABLE
5. Even after manually creating WinNAT rule, ConnectionRefused persists
6. netstat shows no process listening on 172.16.0.1

Claude Model

Sonnet (default)

Is this a regression?

Not applicable (first time Windows Cowork available)

Claude Code Version

1.1.3189

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Hardware: AMD Ryzen Threadripper PRO 9955WX on ASUS Pro WS WRX90E-SAGE SE (server-class workstation)

Network adapter: Intel X710-TL (enterprise dual-port 10GbE) with 3 IPs on one NIC — this is a legitimate production configuration, not a misconfiguration.

Unique aspects of this report:

• Most thorough diagnostic of the Windows Cowork networking stack to date
• Identified and resolved the WinNAT creation bug (workaround provided)
• Proved the remaining issue is MITM proxy binding, not NAT/firewall/DNS
• Multi-IP NIC creates a NAT routing mismatch (ExternalSourceAddress on wrong subnet)
• Full packet-level evidence via Get-NetNatSession showing TCP vs UDP behavior

Happy to provide any additional diagnostics or test proposed fixes.