›_ Claude Code Issues
Claude Code Issues / #25717

[BUG] Cowork Windows - HNS NAT network blocks WinNAT rule creation, VM cannot reach Claude API (Error 52)

Resolved 💬 3 comments Opened Feb 14, 2026 by JoeFernando Closed Feb 17, 2026

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?

---

Body

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 Code

What's Wrong?

Cowork consistently fails with "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace."

The Cowork Hyper-V VM boots and connects to the host over vEthernet (cowork-vm-nat), but cannot reach the external internet to contact api.anthropic.com. Regular Chat mode works perfectly.

Root Cause

The app creates an HNS network (cowork-vm-nat, Type: NAT) but does NOT create a corresponding WinNAT rule (Get-NetNat returns empty). The HNS NAT-type network internally claims the subnet, which then blocks any manual attempt to create a WinNAT rule on the same subnet with New-NetNat — returning Windows System Error 52 ("duplicate name exists on the network").

This creates a catch-22:

  1. HNS NAT network claims the subnet but doesn't provide actual NAT routing
  2. WinNAT cannot create a rule because HNS already owns the subnet (Error 52)
  3. Without NAT + forwarding, the VM can reach the host but has no route to the internet

This is the same root cause as #25155 and related to #25144, #25088, #25205, and #25241.

Environment

  • Claude Desktop Version: 1.1.2685.0 (latest as of 2026-02-14)
  • Platform: Windows (Home/Pro), x64
  • Subscription: Pro
  • Network: Wi-Fi, home network, no VPN

Diagnostic Output

All services running correctly

Name             Status StartType
----             ------ ---------
CoworkVMService Running Automatic
hns             Running    Manual
SharedAccess    Running    Manual
vmcompute       Running    Manual
winnat          Running    Manual

VM process running

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    356      25     8952      19592      11.61  48596   0 vmwp

HNS networks — cowork-vm-nat exists as NAT type

Network : C08CB7B8-9B3C-408E-8E30-5E16A3AEB444
    Name             : Default Switch
    Type             : ICS
    Subnet Address   : 172.18.208.0/20
    Gateway          : 172.18.208.1

Network : A83A1B2E-1B79-46AF-960D-419BC784A448
    Name             : cowork-vm-nat
    Type             : NAT
    Subnet Address   : 172.16.0.0/24
    Gateway          : 172.16.0.1

No WinNAT rule exists

PS> Get-NetNat
# (empty — no output)

Manual NAT creation blocked by HNS (Error 52)

PS> New-NetNat -Name "CoworkVMNat" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
New-NetNat : You were not connected because a duplicate name exists on the network.
    + FullyQualifiedErrorId : Windows System Error 52,New-NetNat

Host can reach API fine — problem is VM-only

ComputerName     : api.anthropic.com
RemoteAddress    : 160.79.104.10
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.1.108
TcpTestSucceeded : True

Default route is correct

InterfaceAlias NextHop     RouteMetric InterfaceMetric
-------------- -------     ----------- ---------------
Wi-Fi          192.168.1.1           0              45

vEthernet adapter is Up with forwarding enabled

InterfaceAlias            Forwarding
--------------            ----------
vEthernet (cowork-vm-nat)    Enabled
vEthernet (cowork-vm-nat)    Enabled

Workarounds Attempted (None Successful)

  1. Delete HNS network → pre-create WinNAT → let Cowork rebuild: WinNAT was created successfully on 172.17.0.0/24, but Cowork recreated HNS network on a different subnet (172.16.0.0/24), causing mismatch
  2. Restart HNS/vmcompute/CoworkVMService: HNS network recreated but still without WinNAT rule
  3. Reset HNS state via registry: Temporarily allowed NAT creation but Cowork recreated conflicting HNS network
  4. Enable IP forwarding on vEthernet (cowork-vm-nat): Successfully enabled but insufficient without NAT rule
  5. Various service restart sequences: No effect

Expected Behavior

Cowork should either:

  • Create the WinNAT rule alongside the HNS NAT network during setup, OR
  • Use ICS type (like WSL and Default Switch do) instead of NAT type, which handles routing automatically, OR
  • Use a consistent subnet so manual workarounds can persist

Steps to Reproduce

  1. Install Claude Desktop v1.1.2685.0 on Windows
  2. Sign in with a paid plan (Pro)
  3. Open Claude Desktop → Click "Cowork" tab
  4. VM boots, HNS network created, but API is unreachable
  5. Verify with Get-NetNat (empty) and hnsdiag list networks (NAT type present)
  6. Attempt New-NetNat for the same subnet → Error 52

What Should Happen?

---

Body

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 Code

What's Wrong?

Cowork consistently fails with "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace."

The Cowork Hyper-V VM boots and connects to the host over vEthernet (cowork-vm-nat), but cannot reach the external internet to contact api.anthropic.com. Regular Chat mode works perfectly.

Root Cause

The app creates an HNS network (cowork-vm-nat, Type: NAT) but does NOT create a corresponding WinNAT rule (Get-NetNat returns empty). The HNS NAT-type network internally claims the subnet, which then blocks any manual attempt to create a WinNAT rule on the same subnet with New-NetNat — returning Windows System Error 52 ("duplicate name exists on the network").

This creates a catch-22:

  1. HNS NAT network claims the subnet but doesn't provide actual NAT routing
  2. WinNAT cannot create a rule because HNS already owns the subnet (Error 52)
  3. Without NAT + forwarding, the VM can reach the host but has no route to the internet

This is the same root cause as #25155 and related to #25144, #25088, #25205, and #25241.

Environment

  • Claude Desktop Version: 1.1.2685.0 (latest as of 2026-02-14)
  • Platform: Windows (Home/Pro), x64
  • Subscription: Pro
  • Network: Wi-Fi, home network, no VPN

Diagnostic Output

All services running correctly

Name             Status StartType
----             ------ ---------
CoworkVMService Running Automatic
hns             Running    Manual
SharedAccess    Running    Manual
vmcompute       Running    Manual
winnat          Running    Manual

VM process running

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    356      25     8952      19592      11.61  48596   0 vmwp

HNS networks — cowork-vm-nat exists as NAT type

Network : C08CB7B8-9B3C-408E-8E30-5E16A3AEB444
    Name             : Default Switch
    Type             : ICS
    Subnet Address   : 172.18.208.0/20
    Gateway          : 172.18.208.1

Network : A83A1B2E-1B79-46AF-960D-419BC784A448
    Name             : cowork-vm-nat
    Type             : NAT
    Subnet Address   : 172.16.0.0/24
    Gateway          : 172.16.0.1

No WinNAT rule exists

PS> Get-NetNat
# (empty — no output)

Manual NAT creation blocked by HNS (Error 52)

PS> New-NetNat -Name "CoworkVMNat" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
New-NetNat : You were not connected because a duplicate name exists on the network.
    + FullyQualifiedErrorId : Windows System Error 52,New-NetNat

Host can reach API fine — problem is VM-only

ComputerName     : api.anthropic.com
RemoteAddress    : 160.79.104.10
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.1.108
TcpTestSucceeded : True

Default route is correct

InterfaceAlias NextHop     RouteMetric InterfaceMetric
-------------- -------     ----------- ---------------
Wi-Fi          192.168.1.1           0              45

vEthernet adapter is Up with forwarding enabled

InterfaceAlias            Forwarding
--------------            ----------
vEthernet (cowork-vm-nat)    Enabled
vEthernet (cowork-vm-nat)    Enabled

Workarounds Attempted (None Successful)

  1. Delete HNS network → pre-create WinNAT → let Cowork rebuild: WinNAT was created successfully on 172.17.0.0/24, but Cowork recreated HNS network on a different subnet (172.16.0.0/24), causing mismatch
  2. Restart HNS/vmcompute/CoworkVMService: HNS network recreated but still without WinNAT rule
  3. Reset HNS state via registry: Temporarily allowed NAT creation but Cowork recreated conflicting HNS network
  4. Enable IP forwarding on vEthernet (cowork-vm-nat): Successfully enabled but insufficient without NAT rule
  5. Various service restart sequences: No effect

Expected Behavior

Cowork should either:

  • Create the WinNAT rule alongside the HNS NAT network during setup, OR
  • Use ICS type (like WSL and Default Switch do) instead of NAT type, which handles routing automatically, OR
  • Use a consistent subnet so manual workarounds can persist

Steps to Reproduce

  1. Install Claude Desktop v1.1.2685.0 on Windows
  2. Sign in with a paid plan (Pro)
  3. Open Claude Desktop → Click "Cowork" tab
  4. VM boots, HNS network created, but API is unreachable
  5. Verify with Get-NetNat (empty) and hnsdiag list networks (NAT type present)
  6. Attempt New-NetNat for the same subnet → Error 52

Error Messages/Logs

see above

Steps to Reproduce

1) copied claude coworker error msg into a new chat and gave it the following in addition:
https://www.reddit.com/r/ClaudeAI/comments/1r35g6o/fix_claude_failed_to_start_claudes_workspace_and/

then followed Claude's instructions

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.1.3189 (1b7b58) 2026-02-14T00:09:46.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

cowork_bug_report.md

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗