[BUG] Cowork Windows — macOS diagnostic code paths running on Windows; VM fails to create network endpoint

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?

Cowork consistently fails with "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace." on Windows 11 Pro. After extensive troubleshooting, two distinct issues were identified:

Issue 1: macOS diagnostic code paths running on Windows
The cowork_vm_node.log shows the app executing macOS-specific network diagnostics on a Windows system:
[networkDiagnostics] === Comprehensive macOS Diagnostics ===
[networkDiagnostics] === ifconfig ===
[networkDiagnostics] Failed to run /sbin/ifconfig: Error: Failed to spawn /sbin/ifconfig: spawn /sbin/ifconfig ENOENT
[networkDiagnostics] === bootpd process status ===
[networkDiagnostics] Failed to run /usr/bin/pgrep: spawn /usr/bin/pgrep ENOENT
[networkDiagnostics] === vmnet/bridge interfaces ===
[networkDiagnostics] Failed to run /sbin/ifconfig: spawn /sbin/ifconfig ENOENT
[networkDiagnostics] === Network configuration ===
[networkDiagnostics] Failed to run /usr/sbin/scutil: spawn /usr/sbin/scutil ENOENT
[networkDiagnostics] === vmnet kext status ===
[networkDiagnostics] Failed to run /usr/sbin/kextstat: spawn /usr/sbin/kextstat ENOENT
The app is attempting to run /sbin/ifconfig, /usr/sbin/scutil, /usr/sbin/kextstat, and /usr/bin/pgrep — none of which exist on Windows. The diagnostics header explicitly says "macOS Diagnostics." This suggests the Windows Cowork build is using macOS code paths for VM network setup and diagnostics.
Issue 2: HcnCreateEndpoint fails with "Element not found"
The VM boot itself succeeds, but creating the network endpoint fails:
[VM:start] Windows VM service configured
[VM:start] VM boot failed: failed to create network endpoint: HcnCreateEndpoint failed:
hr=0x80070490, error={"Success":false,"Error":"Element not found.","ErrorCode":2147943568}

Troubleshooting performed
The following was systematically attempted, none of which resolved the issue:

Hyper-V was not enabled — Get-NetNat returned "Invalid class" (HRESULT 0x80041010). Enabling Hyper-V resolved the WinNAT error but did not fix Cowork.
Default Switch (ICS type) blocks NAT slot — The Hyper-V Default Switch with ICS type occupies Windows' single NAT slot, preventing Cowork from creating a NAT rule for its cowork-vm-nat network. New-NetNat returns "duplicate name exists on the network" (Windows System Error 52).
Attempted to remove Default Switch — Remove-HnsNetwork silently fails; the Default Switch persists through reboots, service disabling (SharedAccess), and registry modifications.
Removed cowork-vm-nat and pre-created NAT rule — After removing the Cowork HNS network, New-NetNat succeeded. However, on restart, Cowork fails at HcnCreateEndpoint with "Element not found" instead of recreating its network.
Cleared VM bundles — Deleted contents of %APPDATA%\Claude\vm_bundles\; Cowork re-downloaded but hit the same endpoint creation error.
NordVPN adapters — NordVPN installed but off. Disabled NordLynx, TAP, and OpenVPN adapters. No change.
Network bypass — Tested with phone hotspot to bypass local network restrictions. No change.
Firewall disabled — No change.

Root cause analysis
There appear to be two compounding bugs:

The Windows Cowork build includes macOS code paths for VM networking and diagnostics, which fail silently on Windows and may be interfering with proper Windows-native VM network setup.
The app does not handle the Hyper-V Default Switch (ICS type) conflict. Windows only allows one NAT configuration, and the auto-created Default Switch claims this slot. The app needs to either work alongside the Default Switch or manage this conflict during setup.

What Should Happen?

Cowork on Windows should use Windows-native networking diagnostics (e.g., Get-NetAdapter, Get-NetIPConfiguration), not macOS tools.
Cowork should handle the Hyper-V Default Switch ICS/NAT conflict gracefully — either by removing it, working alongside it, or informing the user what's needed.
The VM should successfully create its network endpoint and connect to api.anthropic.com.

Error Messages/Logs

2026-02-18 17:12:17 [info] [VM:start] Copying smol-bin.x64.vhdx to bundle
2026-02-18 17:12:17 [info] [VM:start] smol-bin.x64.vhdx copied successfully
2026-02-18 17:12:17 [info] [VM:start] Configuring Windows VM service...
2026-02-18 17:12:17 [info] [VM:start] Windows VM service configured
2026-02-18 17:12:17 [error] [VM:start] VM boot failed: failed to create network endpoint: 
  HcnCreateEndpoint failed: hr=0x80070490, 
  error={"Success":false,"Error":"Element not found.","ErrorCode":2147943568}
2026-02-18 17:12:17 [info] [networkDiagnostics] === Comprehensive macOS Diagnostics ===
  [multiple macOS tool failures — /sbin/ifconfig, /usr/sbin/scutil, etc.]
2026-02-18 17:12:17 [info] [VM:start] Skipping auto-reinstall (already attempted once)

Steps to Reproduce

Have Windows 11 Pro with Hyper-V enabled
Have Hyper-V Default Switch present (auto-created by Windows)
Install Claude Desktop (latest version)
Open Cowork tab
Observe "Failed to start Claude's workspace" error

Environment

OS: Windows 11 Pro
Claude Desktop: 1.1.3363 (ee4247) 2026-02-17
Hyper-V: Enabled
VPN software: NordVPN installed (tested with all adapters disabled)
Docker/WSL2: Not installed
Regular Chat mode: Works perfectly

Related Issues

#24918 — Cowork Windows, cannot connect to API (Windows 11 Home)
#25155 — VM boots but cannot reach API (Windows 10 Pro, missing WinNAT rule)
#25205 — Cowork API connection issue, CSP errors
#25308 — VM starts but API unreachable (Windows 11)

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.1.3363 / Cowork VM SDK

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This appears to be a Day 1 Windows Cowork issue (launched Feb 10, 2026). The macOS code path finding suggests the Windows networking layer may not have been fully ported. The Default Switch NAT conflict is a separate but compounding issue that affects any Windows machine with Hyper-V's default configuration.