[BUG] Cowork VM uses DNS from disconnected adapter on Windows, causing API unreachable

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25088
2. https://github.com/anthropics/claude-code/issues/24918
3. https://github.com/anthropics/claude-code/issues/24962

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

We diagnosed and fixed this exact issue. Root cause is cowork-svc.exe reading DNS from a disconnected Microsoft Wi-Fi Direct Virtual Adapter (192.168.49.1) instead of the active Wi-Fi adapter.

Full root cause analysis, working fix, and suggested code fix here:
https://github.com/anthropics/claude-code/issues/24918#issuecomment-3888119115

Confirming same root cause: empty DNSServerList on HNS network

Environment:

• Windows 11 Pro, Hyper-V enabled
• Claude Desktop 1.1.2685.0
• Active connection: Wi-Fi (Intel Wi-Fi 6E AX211 160MHz)
• Subscription: Max plan

Disconnected adapters present:

• Fortinet Virtual Ethernet Adapter (NDIS 6.30) — Disconnected
• Fortinet SSL VPN Virtual Ethernet Adapter — Disconnected
• ExpressVPN TAP Adapter — Not Present
• ExpressVPN TUN Driver — Disconnected
• ExpressVPN Data Channel Offload — Not Present
• ASIX USB to Gigabit Ethernet — Disconnected

Root cause confirmed: The HNS NAT network cowork-vm-nat is created with no IPv4 DNS at all:

$network = Get-HnsNetwork | Where-Object {$_.Name -like "*cowork*"}
$network.Dns
# (empty)

Get-DnsClientServerAddress -InterfaceAlias "vEthernet (cowork-vm-nat)"
# IPv4 ServerAddresses: {}
# IPv6 ServerAddresses: {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}

Meanwhile the host resolves and connects fine:

nslookup api.anthropic.com
# Resolves to 160.79.104.10 via 192.168.0.1

Test-NetConnection api.anthropic.com -Port 443
# TcpTestSucceeded: True (over Wi-Fi)

VM logs show it boots fine but fails API reachability:

[VM:start] Startup complete, total time: 294615ms
[Keepalive] Starting (interval=2000ms)
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable

Attempted workarounds (all failed):

1. Disabling all disconnected adapters — network still created without DNS
2. Set-DnsClientServerAddress on cowork-vm-nat — Access denied (Hyper-V managed adapter)
3. netsh interface ip set dns on cowork-vm-nat — caused HcnCreateEndpoint failure (Element not found, ErrorCode 2147943568)
4. Full cleanup (Remove-HnsNetwork, delete vm_bundles, restart Hyper-V services, reboot) — network recreated with empty DNS every time
5. Reinstalling workspace via the UI link — same result

Conclusion: The DNSServerList field is never populated during HNS network creation regardless of adapter state. Unlike the OP's case where DNS was inherited from a wrong adapter, in this case no DNS is inherited at all. The fix needs to be in Claude's network creation code to explicitly set DNS from the active adapter.

✅ Workaround: Fix DNS on unused Ethernet adapter (confirmed working)

TL;DR: If you're on Wi-Fi and have an unused Ethernet adapter with stale/wrong DNS, cowork-svc.exe grabs DNS from that adapter instead of your active Wi-Fi. Fix: set the Ethernet adapter's DNS to match your Wi-Fi, disable it permanently, then reset Claude.

Environment

• Windows 11 Pro x64 (Build 26200)
• Claude Desktop 1.1.2998.0 (Microsoft Store)
• Wi-Fi only (Ethernet physically disconnected)
• Wi-Fi DNS: 1.1.1.1, 8.8.8.8
• Ethernet DNS (stale): 192.168.0.254

Symptoms

Exact same pattern as this issue:

[VM] Network status: CONNECTED
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable

Diagnosis

1. Check what DNS the VM is using (Admin PowerShell):

Get-HnsEndpoint | Where-Object { $_.Name -like "cowork*" } | Select Name, IPAddress, GatewayAddress, DNSServerList

Result showed: DNSServerList: 192.168.0.254 ← wrong, grabbed from unused Ethernet

2. Check actual host DNS:

ipconfig /all | findstr "DNS Servers"

Result showed: DNS Servers: 1.1.1.1 (from Wi-Fi) and 192.168.0.254 (from disconnected Ethernet)

3. Identify which adapter has the bad DNS:

Get-NetIPConfiguration | Select InterfaceAlias, @{N='DNS';E={$_.DNSServer.ServerAddresses}} | Format-Table -AutoSize

Confirmed Ethernet adapter had 192.168.0.254, Wi-Fi had 1.1.1.1.

Fix (all commands in Admin PowerShell)

Step 1: Re-enable Ethernet temporarily to configure it:

Enable-NetAdapter -Name "Ethernet"

Step 2: Set its DNS to match your Wi-Fi (use your actual Wi-Fi DNS):

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses "1.1.1.1","8.8.8.8"

Step 3: Verify it took:

Get-DnsClientServerAddress -InterfaceAlias "Ethernet" | Select InterfaceAlias, ServerAddresses

Step 4: Disable Ethernet again:

Disable-NetAdapter -Name "Ethernet" -Confirm:$false

Step 5: Prevent Ethernet from re-enabling on restart:

Get-NetAdapter -Name "Ethernet" | Disable-NetAdapterBinding -ComponentID ms_tcpip

Step 6 (optional, extra safety): Disable at device level:

$adapter = Get-PnpDevice | Where-Object { $_.FriendlyName -like "*Ethernet*" -and $_.Class -eq "Net" }
$adapter | Disable-PnpDevice -Confirm:$false

Step 7: Clean up stale HNS resources:

Get-HnsEndpoint | Where-Object { $_.Name -like "cowork*" } | Remove-HnsEndpoint
Get-HnsNetwork | Where-Object { $_.Name -like "cowork*" } | Remove-HnsNetwork

Step 8: Kill Claude completely:

taskkill /F /IM Claude.exe /T

Step 9: Reset Claude app data:

Go to Settings → Apps → Installed apps → Claude → Advanced options → Repair (or Reset if Repair doesn't work). This forces a clean VM rebuild.

Step 10: Reopen Claude Desktop and launch Cowork.

The VM should now create a fresh HNS endpoint with the correct DNS. Cowork connected to the API successfully after this.

Why this works

cowork-svc.exe doesn't filter for the active network adapter when selecting DNS — it picks up DNS from whichever adapter it finds, including disabled/disconnected ones. By setting the Ethernet adapter's DNS to match our Wi-Fi DNS, even if the service grabs DNS from the wrong adapter, it still resolves api.anthropic.com correctly.

Root cause (for Anthropic)

cowork-svc.exe should filter adapters by operational status (Up) and connection status (Connected) when selecting DNS for the HNS network configuration. Disconnected and disabled adapters should be ignored.

Related issues

• #24962 — Wrong DNS config (192.168.0.1 vs 192.168.1.1)
• #25088 — Wrong DNS server (192.168.1.254 vs 192.168.1.1)
• #24945 — VM boots but API unreachable
• #25024 — CSP blocks a-api.anthropic.com (separate but related)

**FIX*

Ensure Hyper-V is selected and Date/Time is synced and on auto first. Then fix the DNS issue.

Fix: Cowork "Can't reach Claude API" on Windows 10/11 Home — DNS Mismatch from Disconnected Adapter

Environment: Windows 10 Home, Build 26200.7840 | Claude Desktop v1.1.3189 | Max Plan

Root Cause

The Cowork VM inherits DNS from a disconnected network adapter instead of the active Wi-Fi adapter. In my case, a disconnected Realtek USB Ethernet adapter had stale DNS (10.66.152.1), while my active Wi-Fi used 1.1.1.1 / 8.8.8.8. The VM couldn't resolve api.anthropic.com so it showed API UNREACHABLE.

Additionally, the SharedAccess (ICS) service can interfere with Hyper-V NAT routing.

Diagnosis

You can confirm this is your issue by running these in Admin PowerShell:

# Check what DNS the VM endpoint is using
Get-HnsEndpoint | Format-List Name, IPAddress, DNSServerList

# Check your actual Wi-Fi DNS
Get-DnsClientServerAddress -InterfaceAlias "Wi-Fi" | Select ServerAddresses

# Check for disconnected adapters with stale DNS
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status -AutoSize

If the VM's DNSServerList doesn't match your Wi-Fi DNS, and you have a disconnected adapter, this fix is for you.

Fix (Step-by-Step)

Run all commands in PowerShell as Administrator.

Step 1: Identify the bad adapter

# List all adapters and their status
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status -AutoSize

# Check DNS on each disconnected adapter (replace "Ethernet" with your adapter name)
Get-DnsClientServerAddress -InterfaceAlias "Ethernet" | Select ServerAddresses

Look for a disconnected adapter whose DNS doesn't match your Wi-Fi DNS.

Step 2: Disable the disconnected adapter

# Replace "Ethernet" with the name of YOUR disconnected adapter from Step 1
Disable-NetAdapter -Name "Ethernet" -Confirm:$false

Step 3: Disable SharedAccess (ICS) service

Stop-Service SharedAccess -Force
Set-Service SharedAccess -StartupType Disabled

Step 4: Remove the existing Cowork network (forces clean rebuild)

Get-HnsNetwork | Where-Object {$_.Name -eq "cowork-vm-nat"} | Remove-HnsNetwork

Step 5: Enable IP forwarding on the Cowork adapter (if it exists)

# This may error if the adapter was removed in Step 4 — that's fine, skip it
Set-NetIPInterface -InterfaceAlias "vEthernet (cowork-vm-nat)" -Forwarding Enabled -ErrorAction SilentlyContinue

Step 6: Full reboot

Restart-Computer

Step 7: Test Cowork

After reboot, open Claude Desktop and go to the Cowork tab and run any task. It should work.

Step 8: Verify the fix

# Confirm VM now has correct DNS
Get-HnsEndpoint | Format-List Name, IPAddress, DNSServerList

The DNSServerList should now match your Wi-Fi DNS.

If Cowork Breaks Again

Re-run Steps 2 and 3, then reboot. This can happen if:

• Windows re-enables the adapter after an update
• You plug in and unplug a USB Ethernet adapter
• A Windows Update re-enables SharedAccess

What Anthropic Should Fix

The Cowork VM network setup should:

1. Only inherit DNS from the active network adapter, not disconnected ones
2. Create a proper WinNAT rule alongside the HNS network
3. Not depend on SharedAccess/ICS state for NAT routing

Related issues: #25144, #25088, #24918, #25155, #25663

This should have been fixed in the same version that fixed #24918, we switched out networking to a system that doesn't use HNS provided DNS settings and should use whatever your active network adapter is configured to use.

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.