[BUG] Cowork Windows - VM boots but cannot reach Claude API (Windows 10 Pro, Hyper-V)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/24945
2. https://github.com/anthropics/claude-code/issues/24962
3. https://github.com/anthropics/claude-code/issues/25088

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

I have a client that is also running into this issue. From his claude.ai-web.log:

2026-02-12 10:41:10 [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 https://.google.com https://.facebook.com https://.facebook.net https://.doubleclick.net". The action has been blocked.

Mismo problema, intentando resolver con Claude Code me dice que es el conflicto con Docker Desktop que quieren utilizar los mismos recursos

Environment:

Windows 11 Pro
Claude Desktop 1.1.2685
No VPN, no third-party antivirus
Network: stable, host can reach api.anthropic.com via curl without issues

Symptoms:
Cowork fails with "Failed to start Claude's workspace — Can't reach the Claude API"
Later changed to: "failed to create network endpoint: HcnCreateEndpoint failed with HRESULT 0x800706bf"

Troubleshooting attempted (none resolved):
Verified host reaches api.anthropic.com (auth error confirms connectivity)
Manually created WinNAT rule for 172.16.0.0/24 and 172.17.0.0/24 (subnet changed after reinstall)
Enabled IP forwarding on vEthernet (cowork-vm-nat)
Set DNS to 8.8.8.8 / 1.1.1.1 on the cowork adapter
Removed HNS network + NAT rules + restarted HNS service + recreated NAT before launching Claude
Full reboot, clean reinstall of Claude Desktop (including deleting %APPDATA%\Claude)
Disabled firewall — no change

Observations:
HNS network gets created as NAT type but no WinNAT rule is created by the app
Subnet changed from 172.16.0.0/24 to 172.17.0.0/24 after reinstall
Even with correct NAT rule and forwarding enabled, VM fails to create network endpoint
After full cleanup, app fails at HcnCreateEndpoint before the adapter is even created
Debug logs shared via the error banner

I am experiencing the same issue.

[BUG] Cowork Windows - WinNAT creation fails when Hyper-V Default Switch (ICS) is active

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

Environment

• OS: Windows 11 Enterprise
• Claude Desktop Version: Latest (February 2026)
• Hyper-V: Enabled and actively used for other VMs
• Existing Hyper-V Configuration: Default Switch (Internal, ICS-based)

Problem Summary

Cowork fails with "Failed to start Claude's workspace - Can't reach the Claude API from Claude's workspace" on a Windows 11 Enterprise machine with an existing Hyper-V Default Switch configuration.

Root cause identified: Windows cannot run WinNAT and ICS (Internet Connection Sharing) simultaneously. The Hyper-V Default Switch uses ICS for networking. Claude Desktop creates an HNS network (cowork-vm-nat) but fails to create the backing WinNAT rule because ICS is already running. Without the WinNAT rule, the Cowork VM can reach the host but has no route to the internet.

Diagnostic Evidence

1. Host API connectivity confirmed

PS> Test-NetConnection api.anthropic.com -Port 443
TcpTestSucceeded : True

2. Cowork virtual adapter exists

PS> Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like "*cowork*"}

ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicyStore
------- --------------                  ------------- ------------ --------------- ----     --------------- -----------
79      vEthernet (cowork-vm-nat)       IPv6                  1500            5000 Enabled  Connected       ActiveStore
79      vEthernet (cowork-vm-nat)       IPv4                  1500            5000 Disabled Connected       ActiveStore

3. HNS networks show both Default Switch (ICS) and Cowork (NAT)

PS> Get-HnsNetwork | Format-List Name, Type, Subnets

Name    : Default Switch
Type    : ICS
Subnets : {@{AddressPrefix=172.23.80.0/20; GatewayAddress=172.23.80.1; ...}}

Name    : cowork-vm-nat
Type    : NAT
Subnets : {@{AddressPrefix=172.16.0.0/24; GatewayAddress=172.16.0.1; ...}}

4. No WinNAT rule exists (this is the problem)

PS> Get-NetNat
# Returns empty - no NAT rules configured

5. Manual WinNAT creation fails due to ICS conflict

PS> New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
New-NetNat: You were not connected because a duplicate name exists on the network. 
If joining a domain, go to System in Control Panel to change the computer name and 
try again. If joining a workgroup, choose another workgroup name.

6. ICS service is running (required by Default Switch)

PS> Get-Service SharedAccess | Format-List Name, Status, StartType

Name      : SharedAccess
Status    : Running
StartType : Manual

7. Cannot stop ICS or remove Default Switch

PS> Stop-Service SharedAccess -Force
Stop-Service: Service 'Internet Connection Sharing (ICS) (SharedAccess)' stop failed.

PS> Remove-VMSwitch -Name "Default Switch" -Force
Remove-VMSwitch: Failed while removing virtual Ethernet switch.
The automatic Internet Connection Sharing switch cannot be modified.

Root Cause Analysis

Windows has a fundamental limitation: WinNAT and ICS cannot coexist. They both manage NAT at the kernel level.

The Hyper-V Default Switch is a protected, built-in switch that:

• Uses ICS (not WinNAT) for network address translation
• Cannot be removed or modified by users
• Keeps the SharedAccess service running

Claude Desktop's Cowork feature:

• Creates an HNS network of type "NAT" (cowork-vm-nat)
• Expects to create a WinNAT rule to back it
• Fails silently when WinNAT creation is blocked by ICS
• Results in a VM that can reach the host (172.16.0.1) but not the internet

This affects any Windows user who has Hyper-V enabled with the Default Switch present—which is the default configuration for Hyper-V on Windows 10/11.

Workarounds Attempted (All Failed)

| Attempt | Result |
|---------|--------|
| Manual New-NetNat creation | Blocked by ICS conflict |
| Stop ICS service | Service refuses to stop (Default Switch dependency) |
| Remove Default Switch | Protected, cannot be removed |
| Reboot and create NAT before ICS starts | ICS starts automatically with Default Switch |
| Different NAT name (ClaudeVMNat) | Same error |

Expected Behavior

Claude Desktop should either:

1. Detect the ICS conflict and warn the user, or
2. Use an alternative networking approach that doesn't require WinNAT (e.g., External switch, or leverage ICS instead of WinNAT), or
3. Document the incompatibility with Hyper-V Default Switch in system requirements

Suggested Fix

Consider using an External virtual switch connected to the host's physical NIC instead of creating a NAT network. This would:

• Avoid the WinNAT/ICS conflict entirely
• Work on machines with existing Hyper-V configurations
• Provide more reliable networking

Alternatively, detect when ICS is running and either:

• Use ICS for the Cowork VM instead of WinNAT
• Prompt the user to disable the Default Switch (with clear instructions)

Related Issues

This appears related to the broader pattern of Windows Cowork networking failures:

• #25155 - VM boots but API unreachable (no WinNAT rule)
• #24918 - Cannot connect to Claude API from workspace
• #25088 - VM gets wrong DNS, API unreachable
• #25308 - API reachability UNREACHABLE

However, this issue identifies a specific root cause (ICS/WinNAT conflict) that may not be covered in those reports.

Additional Context

• Regular Chat mode works perfectly—only Cowork is affected
• The machine actively uses Hyper-V for other VMs, so disabling Hyper-V or the Default Switch is not a viable workaround
• This likely affects a significant portion of Windows Hyper-V users since the Default Switch is created automatically when Hyper-V is enabled

I just got a new work laptop, and Cowork works on my new one, but fails on my old one. I have had Docker Desktop, Tailscale and several VMs on my old one, but have not installed any of those on my new one yet.

New laptop, Windows 11 Business

PS> Get-HnsNetwork | Format-List Name, Type, Subnets

Name    : cowork-vm-nat
Type    : NAT
Subnets : {@{AdditionalParams=; AddressPrefix=172.16.0.0/24; Flags=0; GatewayAddress=172.16.0.1; Health=;
          ID=DC1F34DE-756B-42FE-910B-FDB4900E4AE2; IpSubnets=System.Object[]; ObjectType=5; Policies=System.Object[];
          State=0}}

Old laptop, Windows 10 Pro

PS> Get-HnsNetwork | Format-List Name, Type, Subnets

Name    : Ethernet
Type    : ICS
Subnets : {@{AdditionalParams=; AddressPrefix=172.20.176.0/20; Flags=0; GatewayAddress=172.20.176.1; Health=;
          ID=9C967D1B-5B9E-4E56-B02D-03CCF215B6B5; IpSubnets=System.Object[]; ObjectType=5; Policies=System.Object[];
          State=0}}

Name    : Wi-Fi
Type    : ICS
Subnets : {@{AdditionalParams=; AddressPrefix=172.22.240.0/20; Flags=0; GatewayAddress=172.22.240.1; Health=;
          ID=63C8D936-4A0C-4FA5-845D-B0C56851326E; IpSubnets=System.Object[]; ObjectType=5; Policies=System.Object[];
          State=0}}

Name    : Default Switch
Type    : ICS
Subnets : {@{AdditionalParams=; AddressPrefix=172.21.224.0/20; Flags=0; GatewayAddress=172.21.224.1; Health=;
          ID=89413D2B-C15C-4468-B589-136F9212A486; IpSubnets=System.Object[]; ObjectType=5; Policies=System.Object[];
          State=0}}

Name    : cowork-vm-nat
Type    : NAT
Subnets : {@{AdditionalParams=; AddressPrefix=172.16.0.0/24; Flags=0; GatewayAddress=172.16.0.1; Health=;
          ID=BF7178A1-4EE6-4071-AE17-ADA5D9708912; IpSubnets=System.Object[]; ObjectType=5; Policies=System.Object[];
          State=0}}

Confirming the same issue here.

Environment:

• Windows (standard setup, no modifications)
• Claude Desktop latest version (installed from claude.com/download)
• Max plan subscriber
• No VPN
• Windows Defender Firewall (also tested with firewall completely disabled — same result)

Error:
"Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace."

What I've tried (none resolved it):

• Restarting Claude Desktop
• Restarting PC
• Disabling Windows Defender Firewall entirely

Regular Chat mode works perfectly on the same machine and network. This is isolated to Cowork's VM networking.

This is a completely default Windows setup — no VPN, no third-party security software, no unusual network configuration. If this doesn't work out of the box on a standard Windows machine, it's going to affect the majority of Windows users.

Following this solved my issue https://github.com/anthropics/claude-code/issues/25144#issuecomment-3894386161

Confirmed still reproducible on Claude Desktop 1.1.3541.0 (MSIX, Windows 11 25H2) as of 2026-02-19.

Environment:

• Claude Desktop: 1.1.3541.0 (MSIX package: Claude_1.1.3541.0_x64__pzs8sxrjxfjjc)
• Claude Code VM SDK: 2.1.45
• OS: Windows 11 25H2 (Build 10.0.26200)
• CPU: Intel Core i7-8550U
• Hyper-V: Enabled
• VPN: None
• Subscription: Pro

Diagnostic output (admin PowerShell):

# HNS network exists but no WinNAT rule:
Get-NetNat  →  (empty)

# IP Forwarding disabled:
vEthernet (cowork-vm-nat)  IPv4  Disabled
vEthernet (cowork-vm-nat)  IPv6  Disabled

# HNS Endpoint — DNS correctly inherited (not the DNS issue from #25088):
Name           : cowork-vm-eth0
IPAddress      : 172.16.0.152
GatewayAddress : 172.16.0.1
DNSServerList  : 192.168.1.1

# Host reaches API on both IPv4 and IPv6:
Test-NetConnection api.anthropic.com -Port 443  →  TcpTestSucceeded: True
nslookup api.anthropic.com  →  160.79.104.10 (IPv4), 2607:6bc0::10 (IPv6)

Log pattern (cowork_vm_node.log):

[VM] Network status: CONNECTED
[VM] API reachability: PROBABLY_UNREACHABLE
[VM:start] Startup complete, total time: 53803ms
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable
[Keepalive] Ping failed: Keep-alive ping timed out

Same root cause as described in this issue. Bug not fixed in latest MSIX release. My separate issue (#26846) was flagged as duplicate and is being closed in favour of this thread.

Environment

• Claude Desktop Version: Latest (February 2026)
• Platform: Windows 11 Pro
• Windows Build: 26200.7840
• Hyper-V: Enabled (full, including all sub-features)
• Subscription: Pro

What's Wrong?

Cowork consistently fails to connect to the Claude API. The workspace starts and the VM boots, but API reachability always ends as UNREACHABLE. Regular Chat mode works perfectly — only Cowork is affected.

Troubleshooting Steps Already Attempted

• Cleared cache via Help → Troubleshooting → Clear cache and restart
• Verified Hyper-V is fully enabled
• Created NAT rule manually: New-NetNat returned a duplicate name error, suggesting an internal conflict
• Identified HNS network type is ICS (not NAT): Get-HNSNetwork shows cowork-vm-vnet of type ICS with subnet 172.16.0.0/24
• Enabled IP forwarding: Set-NetIPInterface -InterfaceAlias "vEthernet (cowork-vm-vnet)" -Forwarding Enabled → confirmed Enabled
• Enabled ICS sharing manually via ncpa.cpl: Ethernet → Properties → Sharing → enabled and pointed to vEthernet (cowork-vm-vnet)
• Disabled NordVPN adapters (TAP-NordVPN and OpenVPN Data Channel Offload)
• Temporarily disabled Norton antivirus
• Host machine reaches api.anthropic.com:443 successfully: TcpTestSucceeded: True

Observed Behavior

After enabling ICS sharing, Cowork now shows "Taking longer than expected to connect to Claude API... retrying" before eventually failing with "Can't reach the Claude API from Claude's workspace." This is an improvement over the immediate failure seen before ICS configuration, suggesting the VM gets partial network access but still cannot route traffic to api.anthropic.com.

Expected Behavior

Cowork workspace should start successfully and connect to the Claude API, the same way regular Chat mode works without issues.

Related Issues

This appears related to #25155 and #25308.

Networking issues like this were fixed in v1.1.4328

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.