[BUG] Cowork regression in v1.1.3963: cowork-svc.exe HcnCreateNetwork ICS fails with 0x80070057 (Windows 11 25H2 Build 26200)

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 worked on v1.1.3918 (Feb 21), but broke after auto-update to v1.1.3963 (Feb 22). The CoworkVMService crashes immediately on startup because cowork-svc.exe fails to create an ICS-type HCN network.

Key finding: The exact same HcnCreateNetwork API call with identical JSON parameters succeeds via C# P/Invoke but fails from cowork-svc.exe — proving this is a bug in the binary itself, not a system/policy/Windows issue.

Environment

| Property | Value |
|----------|-------|
| OS | Windows 11 Enterprise 25H2 (Build 26200.7623) |
| CPU | AMD Ryzen AI MAX+ PRO 395 |
| RAM | 96 GB |
| Claude Desktop | v1.1.3963.0 (MSIX, Windows Store) |
| Previous working version | v1.1.3918.0 |
| Hyper-V | Enabled, all services running |
| Corporate environment | Yes (9altitudes), Group Policies present |

Root Cause Analysis

1. Service crashes with "Incorrect function"

Windows Event Log:

The Claude service terminated with the following service-specific error: Incorrect function.

2. Running cowork-svc.exe interactively reveals the failure

[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: ["29adfbf8-da5f-4c44-97c6-755ece343bf3"]
Found 2 HCN networks, querying properties...
  Network: Name=nat Id=29adfbf8-da5f-4c44-97c6-755ece343bf3 Type=nat
  Trying subnet: 172.16.0.0/24, Gateway: 172.16.0.1
[HCN] Creating ICS network: {"Flags":9,"IsolateSwitch":true,"Name":"cowork-vm-vnet",
  "Subnets":[{"AddressPrefix":"172.16.0.0/24","GatewayAddress":"172.16.0.1",
  "IpSubnets":[{"IpAddressPrefix":"172.16.0.0/24"}]}],"Type":"ICS"}
  Failed to create network: HcnCreateNetwork failed: hr=0x80070057,
  error={"Success":false,"Error":"The parameter is incorrect.","ErrorCode":2147942487}

The service tries all subnets 172.16–31.x.x/24 and fails on every one with the same error.

3. Identical API call succeeds via C# P/Invoke

Script that calls HcnCreateNetwork from computenetwork.dll with the exact same JSON:

$json = '{"Flags":9,"IsolateSwitch":true,"Name":"cowork-vm-vnet","Subnets":[{"AddressPrefix":"172.16.0.0/24","GatewayAddress":"172.16.0.1","IpSubnets":[{"IpAddressPrefix":"172.16.0.0/24"}]}],"Type":"ICS"}'
$hr = [HCN]::HcnCreateNetwork($id, $json, [ref]$net, [ref]$err)
# Result: HR=0x00000000 — SUCCESS

All 4 combinations tested (with/without Flags:9, with/without IsolateSwitch:true) succeed via P/Invoke. The ICS network is created, persists, and is visible in Get-HnsNetwork.

4. This strongly suggests a parameter marshaling bug in the Go binary

Since the same API, same DLL, same parameters, and same user context work from C# but fail from the Go binary (cowork-svc.exe), the issue is likely in how the Go runtime marshals parameters for HcnCreateNetwork (e.g., GUID passed by value instead of by reference, or UTF-8 string instead of UTF-16).

5. Secondary bug: "Found 2 HCN networks" when only 1 exists

The enumerate result ["29adfbf8-..."] contains 1 GUID, but the service reports "Found 2 HCN networks". This is a minor counting bug but indicates broader parsing issues.

6. Secondary bug: HcnOpenNetwork uses wrong GUID

When a pre-created network exists, the service detects "already exists" but then tries HcnOpenNetwork with the wrong GUID (the newly generated one, not the existing network's GUID), resulting in "network not found":

[HCN] Network already exists, opening instead
Failed: HcnOpenNetwork failed: hr=0x803b0001, error={"Error":"The network was not found."}

cowork_vm_node.log comparison

Feb 21 — v1.1.3918 (WORKING)

14:41:00 [VM:steps] load_swift_api completed (0ms)
14:41:00 [VM:start] Configuring Windows VM service...
14:41:01 [VM:start] Windows VM service configured
14:41:16 [VM] Network status: CONNECTED
14:41:16 [VM] API reachability: REACHABLE
14:41:20 [VM:start] Startup complete, total time: 135835ms

Feb 22 — v1.1.3963 (BROKEN)

13:25:23 All files ready in ...\claudevm.bundle
13:33:18 [VM] Loading vmClient (TypeScript) module...
13:33:18 [VM] Module loaded successfully
(log ends — no [VM:start] sequence ever fires because service crashes)

What Should Happen?

cowork-svc.exe should successfully create the ICS network on Windows 11 25H2 (Build 26200), as the underlying Windows HCN API fully supports it (proven by P/Invoke testing).

Steps to Reproduce

1. Have Windows 11 Enterprise 25H2 (Build 26200)
2. Install Claude Desktop v1.1.3963 from Microsoft Store (MSIX)
3. Open Claude Desktop → Cowork tab
4. Observe "VM service not running. The service failed to start."
5. Check Event Viewer → System → "The Claude service terminated with service-specific error: Incorrect function"
6. Run cowork-svc.exe interactively to see HcnCreateNetwork failed: hr=0x80070057

Related Issues

• #27316 — The yukonSilver bug that v1.1.3963 was supposed to fix (v1.1.3963 fixed that but introduced this regression)
• #25505 — CoworkVMService crashes on Windows Insider MSIX (Build 26220)
• #25206 — VM crashes within 5 minutes (commenter on Build 26200)
• #25944 — API unreachable on Build 26200 (different issue — VM starts but API fails)

Claude Model

Opus

Is this a regression?

Yes — v1.1.3918 worked, v1.1.3963 broke it

Last Working Version

v1.1.3918

Claude Code Version

Claude Desktop v1.1.3963 (MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

The v1.1.3963 hotfix (#27316) fixed the yukonSilver/virtualization detection bug for most users, but introduced this ICS network creation regression. The Go binary's HcnCreateNetwork call fails with E_INVALIDARG while identical C# P/Invoke calls succeed, pointing to a parameter marshaling issue in the compiled Go code.