[BUG] Cowork Windows: VM boots and authenticates but has zero internet connectivity — all outbound TCP fails (Win 11 Pro, Build 26200)

[damudao]

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?

Cowork on Windows fails with "Can't reach the Claude API from Claude's workspace." The VM boots successfully, authenticates via vsock/MITM proxy, and spawns the Claude process — but every outbound TCP connection from inside the VM fails. DNS queries from the VM to the gateway (172.16.0.1) go completely unanswered, so the VM never even reaches the point of attempting a TCP connection.

After extensive diagnostics, the networking state after Cowork startup looks like this:

• ICS sharing is disabled on all host connections (checked via HNetCfg.HNetShare COM object)
• No NAT rules exist (Get-NetNat returns empty)
• IP forwarding is disabled on the cowork virtual adapter
• No DNS or TCP listeners on 172.16.0.1 (the gateway IP the VM uses)
• Packet capture over ~95s shows 0 DNS responses and 0 TCP packets from/to the VM

An ASCII string search of cowork-svc.exe (v1.1.4010) finds no instances of EnableSharing, HNetCfg, NetNat, or INetSharing — suggesting the ICS activation step may be missing from the binary. Note: this search does not cover Unicode/wide strings; however, COM ProgIDs such as HNetCfg.HNetShare are typically stored as ANSI strings in Windows PE binaries.

Note on CSP: A separate CSP bug (#25024) that also blocked Cowork appears to have been silently fixed in v1.1.4010 — no CSP errors observed after the update, compared to consistent errors on every v1.1.3963 attempt, with no workaround active (ELECTRON_EXTRA_LAUNCH_ARGS env var verified empty). This is based on a single post-update session so cannot be stated with certainty. This report covers only the networking bug, which remains fully broken in v1.1.4010.

What Should Happen?

The Cowork VM should be able to reach the internet and connect to the Anthropic API.

Error Messages/Logs

**User-facing error:**

Can't reach the Claude API from Claude's workspace.
Restarting Claude or reconnecting to your network sometimes resolves this.


**VM-side errors** from SDK debug logs (Help → Troubleshooting → Enable Cowork VM Debug Logging):

[API:auth] OAuth token check complete                          ← vsock/MITM proxy works
[API:request] Creating client, has Authorization header: false
API error (attempt 1/11): undefined Connection error.          ← TCP to API fails
1P event logging: events failed to export (code=ECONNRESET)
API error (attempt 2/11): undefined Connection error.          ← retry fails
Failed to export events (code=ECONNRESET)
API error (attempt 3/11): undefined Connection error.          ← all retries fail
Failed to fetch plugin security messages: Request failed with status code 403

Every outbound TCP connection from the VM fails (ECONNRESET or ECONNABORTED) — API calls, telemetry, and GitHub fetches all fail identically. Only vsock (MITM proxy for OAuth) works.

**Log pattern (consistent across all attempts, both versions):**

[VM:start] Startup complete, total time: ~22-34s
[Keepalive] Starting (interval=2000ms)
[VM] API reachability: PROBABLY_UNREACHABLE
[Spawn:vm] OAuth token approved with MITM proxy
[Spawn:vm] Spawn succeeded in ~3-7s
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable
[Process] Exited, code=0, duration=~270s

Steps to Reproduce

1. Install Claude Desktop (MSIX) on Windows 11 Pro with Hyper-V enabled
2. Open the Cowork tab and attempt any task
3. Observe: "Can't reach the Claude API from Claude's workspace"

To confirm the networking state after the failure:

4. Check ICS sharing via COM — disabled on all connections:

$netShare = New-Object -ComObject HNetCfg.HNetShare
$connections = $netShare.EnumEveryConnection
foreach ($conn in $connections) {
    $props = $netShare.NetConnectionProps($conn)
    $config = $netShare.INetSharingConfigurationForINetConnection($conn)
    Write-Host "$($props.Name) - Sharing: $($config.SharingEnabled)"
}
# Result: all connections return Sharing: False

5. Confirm no NAT rules exist: Get-NetNat — returns empty
6. Confirm IP forwarding is disabled: Get-NetIPInterface -InterfaceAlias "vEthernet (cowork-vm-vnet)" -AddressFamily IPv4 | Select Forwarding — returns Disabled

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — an auto-update may have changed the version during the reboot period.

Claude Code Version

Claude Desktop v1.1.4010 (Windows MSIX) — this is Claude Desktop, not the Claude Code CLI. Also reproduced on v1.1.3963.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

System configuration

• Windows Features: Hyper-V ✅, Virtual Machine Platform ✅, Windows Hypervisor Platform ✅, WSL2 ✅, Developer Mode ✅
• CoworkVMService: Running (Automatic start)
• vmcompute (Hyper-V Host Compute Service): Running
• Network: Wi-Fi (Private profile), no VPN, no proxy
• Firewall: Windows Defender with explicit allow rules for Claude (both directions)
• Host connectivity: Test-NetConnection api.anthropic.com -Port 443 succeeds from host

Detailed diagnostic evidence

No NAT rules:

Get-NetNat
# (empty)

IP forwarding disabled:

Get-NetIPInterface -InterfaceAlias "vEthernet (cowork-vm-vnet)" -AddressFamily IPv4 | Select Forwarding
# Forwarding: Disabled

No DNS listener on gateway (VM queries go unanswered — confirmed by packet capture):

Get-NetUDPEndpoint -LocalAddress 172.16.0.1 -LocalPort 53
# (empty)

No TCP listeners on gateway:

Get-NetTCPConnection -LocalAddress 172.16.0.1 -State Listen
# (empty)

Packet capture (pktmon on cowork-vm + vEthernet adapters, 96 packets over ~95s):

Protocol breakdown: 78 UDP, 18 non-IP (ARP/IPv6 multicast), 0 TCP
DNS queries sent:   api.anthropic.com (×24), ntp.ubuntu.com (×40) — all from VM to 172.16.0.1
DNS responses:      0 (zero — every query goes unanswered)
TCP SYNs:           0 (zero — VM never attempts a TCP connection)

ICS service log: silent during Cowork attempts:

Get-WinEvent -ProviderName "Microsoft-Windows-SharedAccess" -MaxEvents 20
# (empty — zero events during active Cowork startup and failure)

If EnableSharing() were called, it would be expected to log here. Absence of events is consistent with CoworkVMService not interacting with the ICS service, though not conclusive on its own.

Hyper-V VMMS Networking/Admin: also silent:

Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-VMMS-Networking/Admin" -MaxEvents 20
# (empty)

Binary string search — ICS/NAT strings absent from cowork-svc.exe:

$svc = Get-WmiObject Win32_Service | Where-Object { $_.Name -eq "CoworkVMService" }
$exePath = $svc.PathName.Trim('"') -replace '".*$',''
$content = [System.IO.File]::ReadAllText($exePath, [System.Text.Encoding]::ASCII)
$findings = @("EnableSharing","HNetCfg","NetNat","INetSharing") | Where-Object { $content -match [regex]::Escape($_) }
# Result: "None of the ICS/NAT strings found in binary"

Run twice against the same binary with confirmed clean path — same result both times.

ICS ScopeAddress mismatch (observed when manually enabling ICS):

reg query "HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters" /v ScopeAddress
# ScopeAddress    REG_SZ    192.168.137.1
# Cowork uses 172.16.0.0/24

Host networking confirmed functional:
Chromium netlog (30s capture, Help → Troubleshooting → Record Net Log) shows host-side requests to a-api.anthropic.com all return HTTP 200 via QUIC/H3 — the networking issue is isolated to the VM.

Only one ICS network present:

Get-HnsNetwork | Select-Object Name, Type
# cowork-vm-vnet   ICS

No competing ICS networks — the dual-ICS conflict seen on some other systems is not a factor here.

Observations

• vsock works, TCP does not: Every spawn succeeds (OAuth token approved with MITM proxy, Spawn succeeded). The VM-side Claude process starts, authenticates, retries API calls 11 times over ~270s, then exits cleanly (exit_code=0). Only vsock-based communication works; all outbound TCP fails.
• DNS asymmetry: Resolve-DnsName api.anthropic.com -Server 172.16.0.1 succeeds from host PowerShell, but packet capture shows the VM's DNS queries to the same address get zero responses. The mechanism behind this asymmetry is unclear to us.
• Possible incomplete egress proxy on Windows: The vsock channel works for OAuth token exchange, but per community observations in [BUG] Cowork Windows - CSP blocks a-api.anthropic.com, VM starts but API unreachable (Win 11 25H2) #25024, the Windows build may lack a broader VM egress proxy layer that routes general API traffic on macOS. No references to a general-purpose outbound proxy or hvsock appear in the Windows Cowork logs, in contrast to the macOS architecture described in that thread.

User-side fix attempts (all failed)

1. Manually enabling IP forwarding — no effect without NAT
2. Creating NetNat — blocked ("duplicate name exists on network" — ICS creates a hidden NAT)
3. Replacing with NAT-type HNS network — CoworkVMService terminates immediately (appears to expect ICS type)
4. Manually enabling ICS sharing — adds conflicting 192.168.137.1 IP (ScopeAddress mismatch with 172.16.0.0/24), still causes ECONNRESET
5. Changing ICS ScopeAddress registry — ICS ignores it, still assigns 192.168.137.1
6. Restarting SharedAccess — no effect
7. Setting DNS on all adapters to 1.1.1.1/8.8.8.8 — doesn't fix routing
8. Removing Default Switch — Windows recreates it automatically
9. Modifying HNS endpoint DNS via Invoke-HnsRequest — returns Success=False
10. Complete uninstall + reinstall (only Wi-Fi active, all other adapters disabled, all HNS networks removed, vm_bundles deleted) — fresh install creates an identical broken ICS network with sharing disabled. Strongly suggests this is not a stale state issue.
11. Help → Troubleshooting → Delete Cowork VM Bundle and Restart — bundle re-downloads and workspace starts successfully, but identical failure immediately follows.

Diagnostic files

Three datasets available on request (collected via Help → Troubleshooting):

• SDK debug logs (zip) — VM-side process logs showing API retry pattern
• Chromium netlog (json) — confirms host networking fully functional
• pktmon packet capture (pcapng) — 96 packets, 0 TCP, 0 DNS responses

Related issues

• [BUG] Claude Cowork "API Error: Connection error" #18006 — CSP blocks a-api.anthropic.com (macOS, FIXED)
• [BUG] Cowork Windows - CSP blocks a-api.anthropic.com, VM starts but API unreachable (Win 11 25H2) #25024 — CSP blocks a-api.anthropic.com (Windows, appears fixed in v1.1.4010)
• [BUG] Cowork Windows - Cannot connect to Claude API from workspace (Windows 11 Home) #24918 — API unreachable from VM (Windows 11 Home)
• [BUG] Cowork VM boots successfully but API is unreachable on Windows #24945 — VM boots but API unreachable on Windows
• Cowork VM fails on Windows 11 Home: wrong DNS config, missing sessiondata.vhdx, no NAT #24962 — Wrong DNS config, missing sessiondata.vhdx, no NAT
• Cowork Windows - VM gets wrong DNS server, API unreachable #25088 — VM gets wrong DNS server
• [BUG] Cowork VM uses DNS from disconnected adapter on Windows, causing API unreachable #25144 — DNS from disconnected adapter
• [BUG] Cowork Windows - VM boots but cannot reach Claude API (Windows 10 Pro, Hyper-V) #25155 — VM boots but cannot reach API (Windows 10 Pro, Hyper-V)
• [BUG] Cowork API connection issue + Coworke Tab disappears on restart #25205 — API connection issue + Cowork tab disappears on restart
• [BUG] [Cowork] Windows: VM starts successfully but crashes within 5 minutes, service unrecoverable (Win 11 Pro, Hyper-V) #25206 — VM crashes within 5 minutes (Windows 11 Pro)
• [BUG] windows 11 home issue #25241 — API unreachable (Windows 11 Home)
• [BUG] Cowork VM starts but API is UNREACHABLE on Windows 11 #25308 — API unreachable, exhausted user-side fixes
• Cowork: CoworkVMService crashes repeatedly, API unreachable from VM on Windows 11 Insider (MSIX) #25505 — CoworkVMService crashes repeatedly, API unreachable (Win 11 Insider)
• [BUG] Cowork Windows: API unreachable from VM + 12GB vm_bundle on never-working install (Win 11 Home, Intel Ultra 7) #26258 — API unreachable + 12GB vm_bundle (Win 11 Home)

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Cowork VM boots but API unreachable on Windows - HNS NAT missing WinNAT rule #26613
2. [BUG] Cowork Windows - VM boots but cannot reach Claude API (Windows 10 Pro, Hyper-V) #25155
3. [BUG] Cowork Windows 11 Pro: Ghost NAT blocks API connectivity — NetNat rule never created by CoworkVMService #26912

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

[damudao]

Found 3 possible duplicate issues:

1. [BUG] Cowork VM boots but API unreachable on Windows - HNS NAT missing WinNAT rule #26613
2. [BUG] Cowork Windows - VM boots but cannot reach Claude API (Windows 10 Pro, Hyper-V) #25155
3. [BUG] Cowork Windows 11 Pro: Ghost NAT blocks API connectivity — NetNat rule never created by CoworkVMService #26912

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

Thanks for the links — these are related but not the same issue.

The three issues cited as duplicates (#25155, #26613, #26912) all describe an HNS network of type NAT (cowork-vm-nat) with a missing WinNAT rule. My system shows type ICS (cowork-vm-vnet) — a different network configuration that appears in newer versions of Claude Desktop. The failure mechanism is different: rather than a missing NAT rule, ICS sharing is never activated (SharedAccess event log is completely silent during Cowork startup) and an ASCII string search of cowork-svc.exe v1.1.4010 finds no instances of EnableSharing, HNetCfg, NetNat, or INetSharing. Notably, the final comment in #25155 from @dlefebure (posted yesterday) describes the same ICS-type network and partial improvement from manually enabling ICS sharing — consistent with this being a distinct variant worth tracking separately.

[MarshallOfSound]

Networking issues like this were fixed in v1.1.4328

[damudao]

Confirmed fixed in v1.1.4328. Thank you.

[github-actions]

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.