Skip to content

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

Closed
Closed
[BUG] Cowork Windows: API UNREACHABLE despite working NAT — MITM proxy not binding to VM gateway (172.16.0.1), multi-IP NIC routing mismatch#25944
Labels
bugSomething isn't workingplatform:windowsIssue specifically occurs on Windows

Description

@antar4
antar4
opened on Feb 15, 2026

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 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

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    platform:windowsIssue specifically occurs on Windows
    on Feb 15, 2026

  2. github-actions commented on Feb 15, 2026

    @github-actions
    github-actionsbot
    on Feb 15, 2026 – with GitHub Actions

    Found 3 possible duplicate issues:

    1. [BUG] Cowork Windows - VM boots but cannot reach Claude API (Windows 10 Pro, Hyper-V) #25155
    2. [BUG] Cowork Windows - HNS NAT network blocks WinNAT rule creation, VM cannot reach Claude API (Error 52) #25717
    3. [BUG] Cowork VM boots successfully but API is unreachable on Windows #24945

    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

  3. antar4 commented on Feb 15, 2026

    @antar4
    antar4
    on Feb 15, 2026
    Author

    Update: Root cause identified — NAT is irrelevant, hvsock MITM proxy is the actual API path

    After 6+ hours of deep debugging across 4 sessions, I can now confirm this is not a NAT/routing issue. The VM does not use TCP NAT to reach the Anthropic API. Here's what's actually happening:

    Architecture (confirmed via reverse engineering + network forensics)

    The Cowork VM uses Hyper-V sockets (hvsock) to communicate with cowork-svc.exe on the host. Inside the VM, sdk-daemon (Go binary) uses goproxy as a MITM proxy for OAuth token validation. API calls follow this path:

    VM (Claude Code) → sdk-daemon → hvsock → cowork-svc.exe → host internet → api.anthropic.com

    The HNS NAT network (172.16.0.0/24) is only used for DNS resolution (UDP 53). API traffic never touches NAT.

    Evidence

    1. Zero TCP NAT sessions — ever

    PS> Get-NetNatSession | Where-Object { $_.Protocol -eq 6 }
# Empty — no TCP sessions through NAT
# Only UDP (protocol 17) sessions exist — all DNS

    2. No MITM proxy listener exists on Windows

    PS> netstat -an | findstr "172.16.0"
TCP  172.16.0.1:139  0.0.0.0:0  LISTENING   # NetBIOS only
# No proxy on any port — not 172.16.0.1, not localhost, nowhere

    3. cowork-svc.exe has zero network connections

    PS> netstat -anob | findstr "cowork"
# Empty — cowork-svc communicates only via named pipe + hvsock

    4. Named pipe confirms non-TCP architecture

    PS> Get-ChildItem \\.\pipe\ | Where-Object { $_.Name -match "cowork" }
# cowork-vm-service   ← Claude Desktop ↔ cowork-svc communication

    5. Hyper-V socket registrations exist

    PS> Get-ItemProperty "HKLM:\...\GuestCommunicationServices\*"
# 999E53D4-... → VM Session Service
# A5201C21-... → VM Session Service-2

    6. Adding NAT + forwarding does nothing
    Manually created New-NetNat rule + enabled IP forwarding on vEthernet (cowork-vm-nat) — still UNREACHABLE. Confirms API path doesn't use NAT.

    What works vs what doesn't

    Component Status Evidence
    HNS NAT network creation ✅ Type: NAT, 172.16.0.0/24, gateway 172.16.0.1
    VM boots ✅ Startup complete in ~6s
    L2 connectivity (host ↔ VM) ✅ ping 172.16.0.72 succeeds
    DNS (UDP NAT) ✅ 26+ UDP NAT sessions active
    DNS server config ✅ 192.168.3.1, 192.168.3.252 matches active adapter
    hvsock VM↔host communication ✅ Network status: CONNECTED
    SDK install ✅ Completes in ~1.5s
    MITM proxy / API egress ❌ Zero TCP connections from VM, zero proxy listeners
    API reachability ❌ Always PROBABLY_UNREACHABLE → UNREACHABLE

    The one time it worked (Feb 13)

    On 2026-02-13 18:27:12, Cowork successfully spawned a process:

    [Spawn:vm] OAuth token approved with MITM proxy
[Spawn:vm] Spawn succeeded in 656ms

    This was with SDK version 2.1.40 (current is 2.1.41) and followed a rootfs update. The session ran for ~28 minutes before being killed. Something about that specific boot allowed the hvsock proxy path to function. Every boot before and after has failed.

    Additional confirmed issues

    CSP blocks a-api.anthropic.com (same as #25024):

    [error] 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..."

    This fires every ~10 minutes in claude.ai-web.log. While this appears to only affect Segment analytics, it indicates the CSP connect-src is missing *.anthropic.com.

    Network diagnostics runs macOS commands on Windows (same as #25474):

    [error] Failed to spawn /sbin/ifconfig: spawn /sbin/ifconfig ENOENT
[error] Failed to spawn /usr/sbin/scutil: spawn /usr/sbin/scutil ENOENT

    What we tried (all ineffective for API reachability)

    1. ✅ Verified DNS is correct (not wrong-adapter bug from [BUG] Cowork VM uses DNS from disconnected adapter on Windows, causing API unreachable #25144)
    2. ❌ Created explicit New-NetNat rule — no effect on API
    3. ❌ Enabled IP forwarding on cowork adapter — no effect on API
    4. ❌ Disabled Windows Firewall entirely — no effect on API
    5. ❌ Disabled Hyper-V firewall rules — no effect on API
    6. ❌ Created HNS NAT network via P/Invoke HcnCreateNetwork — no effect
    7. ❌ Removed Default Switch to eliminate NAT conflicts — no effect
    8. ❌ SkipAsSource on multi-IP NIC — no effect
    9. ❌ Multiple HNS/WinNAT service restart sequences — no effect

    Conclusion

    The Windows MITM proxy (inside cowork-svc.exe) is not reliably forwarding API traffic from the VM to the internet. The hvsock communication works (VM reports CONNECTED), but the proxy layer that should route api.anthropic.com requests from the VM through the host's internet connection is broken.

    This cannot be fixed from the host side. cowork-svc.exe has zero logging — no proxy logs, no hvsock connection logs, no error output. Adding diagnostic logging to the Windows proxy path would be the single most impactful improvement for debugging this.

    Requested fixes

    1. Add logging to cowork-svc.exe — especially the hvsock proxy/MITM component
    2. Fix the hvsock MITM proxy so it reliably forwards API traffic on Windows
    3. Add a-api.anthropic.com to CSP connect-src (same fix as [BUG] Claude Cowork "API Error: Connection error" #18006 for macOS)
    4. Replace macOS diagnostic commands with Windows equivalents (ipconfig, Get-NetAdapter, netsh)

    Current state (clean baseline for Anthropic testing)

    All manual modifications have been reverted. The system is in the default state that Claude Desktop creates:

    • HNS network: cowork-vm-nat (Type: NAT, 172.16.0.0/24) — created by cowork-svc
    • No manual New-NetNat rules
    • IP forwarding: Disabled (default)
    • Windows Firewall: Enabled (default)
    • VM boots to CONNECTED → UNREACHABLE consistently

    Environment

    • Windows 11 Pro 25H2 (Build 26200)
    • Claude Desktop v1.1.3189.0 (MSIX)
    • Hyper-V enabled (full)
    • Multi-IP NIC (192.168.3.62 + 192.168.3.252)
    • No VPN, no corporate proxy
    • Firewall tested both on and off

    Related issues

  4. mojjow commented on Feb 17, 2026

    @mojjow
    mojjow
    on Feb 17, 2026

    Very thorough @antar4 I'm having the same issue!

  5. ErosEleutherios commented on Feb 17, 2026

    @ErosEleutherios
    ErosEleutherios
    on Feb 17, 2026

    Excellent analysis @antar4! This may explain issues I documented in #25513 (VPN incompatibility).

    I found Cowork worked intermittently with VPN - sometimes connecting, sometimes timing out. If the API path uses hvsock (not TCP NAT), that would explain why extensive routing/NAT configuration had inconsistent results.

    My experience:

    • v1.1.3189: Briefly worked with VPN on (luck?)
    • v1.1.3363: Back to failing with VPN on
    • VPN off: Works (when it works at all)

    Your discovery that cowork-svc.exe has zero logging is critical - debugging these issues without proxy logs is impossible.

    Adding my vote for:

    • Add logging to cowork-svc.exe
    • Fix the hvsock MITM proxy reliability

  6. MarshallOfSound commented on Feb 26, 2026

    @MarshallOfSound
    MarshallOfSound
    on Feb 26, 2026

    We just released v1.1.4328 which should fix these networking issues some users were facing, please update and you should be able to use Cowork now 🥳

  7. MarshallOfSound
    closed this as completedon Feb 26, 2026

  8. github-actions commented on Mar 7, 2026

    @github-actions
    github-actionsbot
    on Mar 7, 2026 – with GitHub Actions

    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.

  9. github-actions
    locked as resolved and limited conversation to collaborators on Mar 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingplatform:windowsIssue specifically occurs on Windows

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions