Skip to content

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

Closed as not planned
Closed as not planned
[BUG] Cowork Windows - HNS NAT network blocks WinNAT rule creation, VM cannot reach Claude API (Error 52)#25717
Labels
invalidIssue doesn't seem to be related to Claude Code

Description

@JoeFernando
JoeFernando
opened on Feb 14, 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?

Body

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report
  • 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

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report
  • 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

Activity

  1. JoeFernando
    added
    bugSomething isn't working
    on Feb 14, 2026
  2. github-actions
    added
    invalidIssue doesn't seem to be related to Claude Code
    and removed
    bugSomething isn't working
    on Feb 14, 2026

  3. zoldier-admin commented on Feb 16, 2026

    @zoldier-admin
    zoldier-admin
    on Feb 16, 2026

    Same issue here — additional diagnostic details
    Environment:

    Windows 10/11, Hyper-V enabled (had to enable it manually — was disabled)
    Claude Desktop latest version

    Symptoms:
    Exact same Error 52 on New-NetNat. Here's what I found digging deeper:

    1. Get-NetNat returns empty, but New-NetNat fails:
      powershellPS> Get-NetNat

    (empty - no results)

    PS> New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"

    Error 52: "duplicate name exists on the network"

    1. HNS shows the cowork NAT exists but is non-functional:
      Get-HnsNetwork | ConvertTo-Json shows:

    cowork-vm-nat — Type: NAT, NatName: NAT3A7C7061-... — has a NatName registered at HNS level but it never gets created as a WinNAT rule
    Default Switch — Type: ICS, NatName: ICS3846EF4A-... — this is claiming the single NAT slot

    1. Can't remove or disable the Default Switch ICS NAT:
      powershellPS> Remove-VMSwitch "Default Switch" -Force

    "The automatic Internet Connection Sharing switch cannot be modified"

    PS> Stop-Service SharedAccess -Force

    "Service stop failed"

    Root cause: Windows only allows one WinNAT instance. The Default Switch's ICS-type NAT is claiming it, preventing cowork-vm-nat from creating a functional NAT rule. The HNS network is created correctly (172.16.0.0/24, gateway 172.16.0.1) but traffic has no route out.
    Suggested fix: Cowork should either use the Default Switch instead of creating its own, or handle the ICS NAT conflict during network setup (e.g., by using HNS NAT directly instead of relying on WinNAT).

  4. github-actions commented on Feb 17, 2026

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

    Closing for now — this doesn't appear to be about Claude Code. Please open a new issue if this is still relevant.

  5. github-actions
    closed this as not plannedon Feb 17, 2026

  6. github-actions commented on Feb 24, 2026

    @github-actions
    github-actionsbot
    on Feb 24, 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.

  7. github-actions
    locked as resolved and limited conversation to collaborators on Feb 24, 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

    invalidIssue doesn't seem to be related to Claude Code

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions