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

[Mike-core]

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?

Environment:

• Claude Desktop: 1.1.2685 (MSIX/Windows Store)
• OS: Windows 10 Pro
• Hyper-V: Enabled (full, not Home edition)
• VPN software installed: Yes (was fully stopped during testing)
• Docker Desktop: Installed but stopped

Problem:
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) on 172.16.0.0/24, but cannot reach the external internet to contact api.anthropic.com. Regular Chat mode works perfectly.

Root cause investigation:

1. The app creates an HNS network (cowork-vm-nat, type: NAT, subnet: 172.16.0.0/24, gateway: 172.16.0.1) but does NOT create a corresponding WinNAT rule (Get-NetNat returns empty).
2. IP Forwarding is NOT enabled on vEthernet (cowork-vm-nat).
3. Without NAT + forwarding, the VM can reach the host but has no route to the internet.
4. Manually creating the NAT rule (New-NetNat) and enabling forwarding does not persist — the app recreates the HNS network on restart without the WinNAT rule.
5. The host machine can reach api.anthropic.com without issues (port 443, DNS, TLS all verified).

What Should Happen?

The app should create both the HNS network AND the corresponding WinNAT rule (New-NetNat), and enable IP forwarding on the vEthernet (cowork-vm-nat) virtual adapter. The Cowork VM should be able to reach api.anthropic.com through the host's internet connection.

Error Messages/Logs

From cowork_vm_node.log — every startup attempt shows this pattern:

[VM] Network status: NOT_CONNECTED
[VM:network] Not connected, will show error in 30000ms if not resolved
[VM] Network status: CONNECTED
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable

Network diagnostics from host:
- Get-NetNat returns empty (no WinNAT rule exists)
- Get-NetIPInterface shows Forwarding=Disabled on vEthernet (cowork-vm-nat)
- Get-HnsNetwork shows cowork-vm-nat exists (type: NAT, 172.16.0.0/24) but without WinNAT backing
- Host can reach api.anthropic.com on port 443 (TLS succeeds, DNS resolves)

Steps to Reproduce

1. Install Claude Desktop (MSIX/Windows Store) on Windows 10 Pro with Hyper-V enabled
2. Open Claude Desktop and navigate to Cowork
3. Attempt any task in Cowork
4. Observe "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace"
5. Verify host can reach api.anthropic.com (it can)
6. Check Get-NetNat in admin PowerShell — returns empty
7. Check Get-HnsNetwork — shows cowork-vm-nat exists as type NAT but no WinNAT backing
8. Check Get-NetIPInterface -InterfaceAlias "vEthernet (cowork-vm-nat)" — Forwarding=Disabled

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.34 (Claude Code in Cowork VM) / Claude Desktop 1.1.2685 (MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

This appears to be a Day 1 issue with Cowork on Windows (launched Feb 10, 2026). Possibly related to #24918.

Manually creating the NAT rule and enabling forwarding via admin PowerShell temporarily allows the VM to work, but Claude Desktop recreates the HNS network on restart without re-establishing the WinNAT rule, so the fix does not persist.

VPN software (ExpressVPN) was installed but fully stopped during all testing — same result with or without it running.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Cowork VM boots successfully but API is unreachable on Windows #24945
2. Cowork VM fails on Windows 11 Home: wrong DNS config, missing sessiondata.vhdx, no NAT #24962
3. Cowork Windows - VM gets wrong DNS server, API unreachable #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

[Josh-boxIT]

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.

[btoaldas]

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

[tcarroll95]

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

[mshuber-proudfoot-com]

I am experiencing the same issue.

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

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

• [BUG] Cowork Windows - VM boots but cannot reach Claude API (Windows 10 Pro, Hyper-V) #25155 - VM boots but API unreachable (no WinNAT rule)
• [BUG] Cowork Windows - Cannot connect to Claude API from workspace (Windows 11 Home) #24918 - Cannot connect to Claude API from workspace
• Cowork Windows - VM gets wrong DNS server, API unreachable #25088 - VM gets wrong DNS, API unreachable
• [BUG] Cowork VM starts but API is UNREACHABLE on Windows 11 #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