[BUG] [Cowork] Windows 10 Pro: HNS NAT network created with WFP extension disabled, no WinNAT rule, MITM proxy never binds — API permanently unreachable

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?

WHAT'S WRONG? (Paste into the "What's Wrong?" Write box)

Cowork on Windows 10 Pro consistently fails with "Can't reach the Claude API from Claude's workspace." After extensive diagnostic work, I've identified a specific failure chain that adds new detail to the existing reports (#25155, #25024, #24918, #24945, #25088):

The cowork-vm-nat HNS network is created with the Windows Filtering Platform (WFP) virtual switch extension disabled. WinNAT depends on WFP for connection tracking and NAT translation. With WFP disabled on the switch, no WinNAT rule can be established, and the MITM proxy cannot bind to the NAT gateway interface. The VM gets partial connectivity (enough to install the SDK) but cannot reach the API.

This is not caused by firewall, VPN, DNS, or virtualization misconfiguration — I've systematically eliminated all of those.

New diagnostic finding — WFP disabled on the virtual switch:

Dumping the full HNS network JSON for cowork-vm-nat reveals:

"Extensions": [
  {
    "Id": "E7C3B2F0-F3C5-48DF-A43E-17B1B554E7B1",
    "IsEnabled": false,
    "Name": "Microsoft Windows Filtering Platform"
  },
  {
    "Id": "430BE869-E84E-4213-A3FF-E426B1FB8BE2",
    "IsEnabled": true,
    "Name": "Microsoft Azure VFP Switch Extension"
  },
  {
    "Id": "F74F241B-440F-4433-BB28-00F89EAD20D8",
    "IsEnabled": true,
    "Name": "Microsoft NDIS Capture"
  }
]

Microsoft Windows Filtering Platform: IsEnabled = false — this causes the following failure chain:

1. HNS creates the NAT network on 172.16.0.0/24 with gateway 172.16.0.1
2. WFP is disabled on the virtual switch → WinNAT cannot perform connection tracking
3. Get-NetNat returns empty (expected for HNS-managed NAT per Windows Server 2025 docs)
4. New-NetNat fails with "duplicate name exists" (HNS reservation blocks it)
5. MITM proxy either cannot bind to 172.16.0.1 or cannot route traffic without WFP
6. VM gets PROBABLY_UNREACHABLE → UNREACHABLE every time

Relation to existing issues:

| Issue | Relation |
|-------|----------|
| #25155 | Same root symptoms (Win 10 Pro, no WinNAT rule, manual NAT works temporarily). This report adds the WFP-disabled finding. |
| #25024 | Confirms no MITM proxy listener exists on Windows. My diagnostics corroborate — netstat shows no listener on 172.16.0.1. |
| #24918, #24945, #25088, #25241, #25308 | Same PROBABLY_UNREACHABLE → UNREACHABLE pattern across various Windows editions. |
| #26216 | The orphaned cowork-vm-nat HNS network also breaks WSL2 — same HNS/WinNAT disconnect. |

Environment:

• OS: Windows 10 Pro, Build 10.0.26200
• Hardware: AMD Ryzen 9 5950X, 64GB RAM
• Claude Desktop: v1.1.3541 (Windows Store/MSIX)
• Claude Code: v2.1.45
• Node.js: v22.18.0
• VPN: None (Surfshark was installed but fully uninstalled — no residual drivers)
• Firewall: Windows Defender — Claude, claude.exe, and Node.js all allowed on Private + Public
• Windows Features: Microsoft-Hyper-V ✅, VirtualMachinePlatform ✅, HypervisorPlatform ✅
• HypervisorPresent: True

What I've already tried (all failed):

• Removed and let Cowork recreate the cowork-vm-nat HNS network (multiple times)
• Full HNS/vmcompute/WinNat service reset with HNS.data deletion
• Deleted locked smol-bin.vhdx, let Cowork copy fresh
• Deleted vm_bundles and claude-code-vm directories, let Cowork rebuild from scratch
• Confirmed curl.exe -v https://api.anthropic.com succeeds from host
• Verified DNS resolution works on host
• Reversed prior Hyper-V disablement (had been disabled for game anti-cheat) — re-enabled VBS, hypervisor, Memory Integrity, HypervisorPlatform
• Confirmed all firewall rules allow Claude on Private + Public
• Fully uninstalled Surfshark VPN — no residual network adapters or filter drivers

What Should Happen?

WHAT SHOULD HAPPEN? (Paste into the "What Should Happen?" Write box)

Cowork should create the cowork-vm-nat HNS network with the WFP extension enabled on the virtual switch, establish a working NAT path, and bind the MITM proxy to the gateway interface so the VM can route API calls through the host.

Specifically:

1. Ensure WFP is enabled on the cowork-vm-nat virtual switch
2. Create a corresponding WinNAT rule and enable IP forwarding on vEthernet (cowork-vm-nat)
3. Bind the MITM proxy to 172.16.0.1 so the VM can reach api.anthropic.com

Error Messages/Logs

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

From cowork_vm_node.log (identical pattern every attempt since Feb 16):
[VM] Network status: NOT_CONNECTED
[VM] Network status: CONNECTED
[VM:steps] sdk_install completed
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE

HNS Network State:
PS> Get-HnsNetwork | Select-Object Name, Type, Subnets
Name              Type  Subnet
cowork-vm-nat     NAT   172.16.0.0/24 (gateway 172.16.0.1)
Default Switch    ICS   172.28.208.0/20 (gateway 172.28.208.1)

PS> Get-NetNat
(empty — expected for HNS-managed NAT)

PS> New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
FAILS: "duplicate name exists on the network"

WFP Extension State (from HNS network JSON):
"Microsoft Windows Filtering Platform": IsEnabled = false

Steps to Reproduce

1. Install Claude Desktop v1.1.3541 on Windows 10 Pro (Build 26200) with all virtualization features enabled (Hyper-V, VirtualMachinePlatform, HypervisorPlatform)
2. Open Claude Desktop → Switch to Cowork tab
3. Cowork creates cowork-vm-nat HNS network — inspect with Get-HnsNetwork | ConvertTo-Json -Depth 10 to confirm WFP is disabled
4. VM boots, gets Network status: CONNECTED, installs SDK successfully
5. API reachability check fails: PROBABLY_UNREACHABLE → UNREACHABLE (~24 seconds)
6. Error: "Can't reach the Claude API from Claude's workspace"
7. Repeat — identical result every time, across reboots, clean installs, and service resets

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop v1.1.3541 / Claude Code v2.1.45

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Suggested fix: The HNS network creation should ensure the WFP extension is enabled on the virtual switch. Without WFP, WinNAT cannot perform connection tracking required for NAT translation. This likely affects all Windows users where WFP defaults to disabled on HNS-created NAT switches.

Note on Get-NetNat returning empty: Multiple reporters have flagged this as the problem, but per Windows Server 2025 container networking documentation, HNS-managed NAT networks are intentionally not surfaced via Get-NetNat. The empty result is by design — the real issue is WFP being disabled upstream.

Full diagnostic briefs available — I have two detailed troubleshooting documents covering every diagnostic step, HNS JSON dumps, adapter bindings, registry state, and service configurations. Happy to share if helpful for triage.

This is a Cowork-on-Claude-Desktop issue, not a Claude Code CLI issue. Filing here as there is no dedicated Claude Desktop repository.