[BUG] Cowork VM boots successfully but API is unreachable on Windows
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?
<html>
<body>
<!--StartFragment--><h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Preflight Checklist</h2>
<ul class="contains-task-list">
<li class="task-list-item"><input disabled="" type="checkbox" checked=""> I have searched existing issues and this hasn't been reported yet</li>
<li class="task-list-item"><input disabled="" type="checkbox" checked=""> This is a single bug report</li>
<li class="task-list-item"><input disabled="" type="checkbox" checked=""> I am using the latest version of Claude Code</li>
</ul>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">What's Wrong?</h2>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Cowork workspace VM boots and connects to the network successfully, but the API reachability check fails with <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">PROBABLY_UNREACHABLE</code> → <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">UNREACHABLE</code>. This happens 100% of the time on the new Windows Cowork release (announced Feb 10, 2026).</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The host machine can reach <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">api.anthropic.com:443</code> without issues — the problem is specifically inside the VM's network path.</p>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Environment</h2>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2"><strong>Platform:</strong> Windows 11 24H2 (Build 10.0.26200)</li>
<li class="whitespace-normal break-words pl-2"><strong>CPU:</strong> AMD Ryzen 7 PRO 5850U</li>
<li class="whitespace-normal break-words pl-2"><strong>RAM:</strong> ~30GB</li>
<li class="whitespace-normal break-words pl-2"><strong>Claude Desktop Version:</strong> 1.1.2685</li>
<li class="whitespace-normal break-words pl-2"><strong>Claude Code VM SDK:</strong> 2.1.34</li>
<li class="whitespace-normal break-words pl-2"><strong>Subscription:</strong> Max</li>
</ul>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Network Adapters (active)</h2>
<div class="overflow-x-auto w-full px-2 mb-6">
Adapter | Description
-- | --
Wi-Fi 2 | Intel Wi-Fi 6 AX200 160MHz
vEthernet (WSL (Hyper-V firewall)) | Hyper-V Virtual Ethernet Adapter
Tailscale | Tailscale Tunnel
vEthernet (cowork-vm-nat) | Hyper-V Virtual Ethernet Adapter #2
</div>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Key Log Output (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork_vm_node.log</code>)</h2>
<div class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg"><div class="sticky opacity-0 group-hover/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md active:scale-95 backdrop-blur-md Button_ghost__BUAoh" type="button" aria-label="Copy to clipboard" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3C13.3284 3 14 3.67157 14 4.5V6H15.5C16.3284 6 17 6.67157 17 7.5V15.5C17 16.3284 16.3284 17 15.5 17H7.5C6.67157 17 6 16.3284 6 15.5V14H4.5C3.67157 14 3 13.3284 3 12.5V4.5C3 3.67157 3.67157 3 4.5 3H12.5ZM14 12.5C14 13.3284 13.3284 14 12.5 14H7V15.5C7 15.7761 7.22386 16 7.5 16H15.5C15.7761 16 16 15.7761 16 15.5V7.5C16 7.22386 15.7761 7 15.5 7H14V12.5ZM4.5 4C4.22386 4 4 4.22386 4 4.5V12.5C4 12.7761 4.22386 13 4.5 13H12.5C12.7761 13 13 12.7761 13 12.5V4.5C13 4.22386 12.7761 4 12.5 4H4.5Z"></path></svg></div><div class="absolute inset-0 flex items-center justify-center"><div class="transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.1883 5.10908C15.3699 4.96398 15.6346 4.96153 15.8202 5.11592C16.0056 5.27067 16.0504 5.53125 15.9403 5.73605L15.8836 5.82003L8.38354 14.8202C8.29361 14.9279 8.16242 14.9925 8.02221 14.9989C7.88203 15.0051 7.74545 14.9526 7.64622 14.8534L4.14617 11.3533L4.08172 11.2752C3.95384 11.0811 3.97542 10.817 4.14617 10.6463C4.31693 10.4755 4.58105 10.4539 4.77509 10.5818L4.85321 10.6463L7.96556 13.7586L15.1161 5.1794L15.1883 5.10908Z"></path></svg></div></div></div></button></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;"><span><span>2026-02-11 09:55:41 [info] All files ready in C:\Users\Chris Hadley\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
</span></span><span>2026-02-11 09:55:41 [info] [VM:steps] download_and_sdk_prepare completed (352830ms)
</span><span>2026-02-11 09:55:41 [info] [VM:steps] load_swift_api completed (0ms)
</span><span>2026-02-11 09:55:41 [info] [VM:start] Configuring Windows VM service...
</span><span>2026-02-11 09:55:41 [info] [VM:start] Windows VM service configured
</span><span>2026-02-11 09:55:53 [info] [VM:start] Still waiting for guest connection... 10152ms elapsed, 14 polls
</span><span>2026-02-11 09:55:53 [info] [VM] Network status: NOT_CONNECTED
</span><span>2026-02-11 09:55:53 [info] [VM:steps] sdk_install started
</span><span>2026-02-11 09:55:54 [info] [VM] Network status: CONNECTED
</span><span>2026-02-11 09:55:58 [info] [VM:steps] sdk_install completed (4483ms)
</span><span>2026-02-11 09:55:58 [info] [VM:start] Startup complete, total time: 369633ms
</span><span>2026-02-11 09:55:59 [info] [VM] API reachability: PROBABLY_UNREACHABLE
</span><span>2026-02-11 09:56:23 [info] [VM] API reachability: UNREACHABLE
</span><span>2026-02-11 09:56:23 [warn] [VM:network] API is unreachable</span></code></pre></div></div>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Steps to Reproduce</h2>
<ol class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Install Claude Desktop on Windows 11 24H2 (Build 26200)</li>
<li class="whitespace-normal break-words pl-2">Sign in with a paid subscription</li>
<li class="whitespace-normal break-words pl-2">Switch to the Cowork tab</li>
<li class="whitespace-normal break-words pl-2">Workspace VM downloads, boots, and connects to network</li>
<li class="whitespace-normal break-words pl-2">API reachability check fails — workspace never becomes usable</li>
</ol>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">What Should Happen</h2>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">After <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">[VM] Network status: CONNECTED</code>, the API reachability check should succeed and the workspace should become usable.</p>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Troubleshooting Already Attempted</h2>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">✅ Full reboot</li>
<li class="whitespace-normal break-words pl-2">✅ Deleted <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">%APPDATA%\Claude\vm_bundles</code> and let it re-download</li>
<li class="whitespace-normal break-words pl-2">✅ Cleared all Claude cache/session data (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">%APPDATA%\Claude\Cache</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Code Cache</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">sessions</code>)</li>
<li class="whitespace-normal break-words pl-2">✅ Disabled Tailscale (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">tailscale down</code>) — no change</li>
<li class="whitespace-normal break-words pl-2">✅ Disabled IPv6 on <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">vEthernet (cowork-vm-nat)</code> — no change</li>
<li class="whitespace-normal break-words pl-2">✅ Temporarily disabled Windows Firewall (all profiles) — no change</li>
<li class="whitespace-normal break-words pl-2">✅ Verified no proxy configured (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">netsh winhttp show proxy</code> → Direct access)</li>
<li class="whitespace-normal break-words pl-2">✅ Verified no <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">ANTHROPIC_API_KEY</code> env var set</li>
<li class="whitespace-normal break-words pl-2">✅ Confirmed host can reach API: <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Test-NetConnection api.anthropic.com -Port 443</code> → <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">TcpTestSucceeded: True</code></li>
<li class="whitespace-normal break-words pl-2">✅ Firewall rules for Claude exist (Inbound + Outbound Allow)</li>
<li class="whitespace-normal break-words pl-2">✅ Extensions blocklist is empty</li>
<li class="whitespace-normal break-words pl-2">✅ Only one OAuth account configured (no multi-account conflict)</li>
</ul>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Additional Context</h2>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">This is a fresh Windows Cowork setup — Cowork has never worked on this machine</li>
<li class="whitespace-normal break-words pl-2">Regular Claude Desktop chat works perfectly</li>
<li class="whitespace-normal break-words pl-2">Claude Code CLI works perfectly on this machine</li>
<li class="whitespace-normal break-words pl-2">The <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork-vm-nat</code> Hyper-V adapter is created successfully</li>
<li class="whitespace-normal break-words pl-2">The VM network reports <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">CONNECTED</code> before API reachability fails, suggesting the issue is in the VM's outbound routing to <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">api.anthropic.com</code> specifically, possibly through the internal proxy</li>
<li class="whitespace-normal break-words pl-2">Similar to #18854 (macOS internal proxy blocking API) but on Windows</li></ul><!--EndFragment-->
</body>
</html>
What Should Happen?
After [VM] Network status: CONNECTED, the API reachability check should succeed and the workspace should become usable.
Error Messages/Logs
2026-02-11 09:55:41 [info] All files ready in C:\Users\Chris Hadley\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-02-11 09:55:41 [info] [VM:steps] download_and_sdk_prepare completed (352830ms)
2026-02-11 09:55:41 [info] [VM:steps] load_swift_api completed (0ms)
2026-02-11 09:55:41 [info] [VM:start] Configuring Windows VM service...
2026-02-11 09:55:41 [info] [VM:start] Windows VM service configured
2026-02-11 09:55:53 [info] [VM:start] Still waiting for guest connection... 10152ms elapsed, 14 polls
2026-02-11 09:55:53 [info] [VM] Network status: NOT_CONNECTED
2026-02-11 09:55:53 [info] [VM:steps] sdk_install started
2026-02-11 09:55:54 [info] [VM] Network status: CONNECTED
2026-02-11 09:55:58 [info] [VM:steps] sdk_install completed (4483ms)
2026-02-11 09:55:58 [info] [VM:start] Startup complete, total time: 369633ms
2026-02-11 09:55:59 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-11 09:56:23 [info] [VM] API reachability: UNREACHABLE
2026-02-11 09:56:23 [warn] [VM:network] API is unreachable
Steps to Reproduce
Steps to Reproduce
Install Claude Desktop on Windows 11 24H2 (Build 26200)
Sign in with a paid subscription
Switch to the Cowork tab
Workspace VM downloads, boots, and connects to network
API reachability check fails — workspace never becomes usable
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
1.1.2685
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
13 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I'm experiencing the exact same issue. Fresh Windows 11 install with Claude Desktop (latest version), and the Cowork tab fails with "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace."
Would appreciate any updates on a fix!
I also have this exact problem on Windows 10.
Same issue also for me on windows 11, Claude itself checked what the problem could be but it can't figure it out. These are the conclusions:
Environment:
Windows 11 Enterprise 24H2 (Build 26100.6584), x64
AMD Ryzen 7 5800X, 96 GB RAM
Claude Desktop v1.1.3189 (fresh install from claude.ai/download)
Plan: Pro
Network: Ethernet, no VPN, no proxy
Hyper-V: fully enabled (all features including Hyper-V, Virtual Machine Platform, Hypervisor Platform)
Symptoms:
Cowork fails with "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace." The VM boots successfully, connects to the internal network, and installs the SDK (confirming the VM has internet access), but the API reachability check consistently fails: PROBABLY_UNREACHABLE → UNREACHABLE.
Troubleshooting performed:
Hyper-V was initially disabled — enabled all Hyper-V features (Microsoft-Hyper-V-All, HypervisorPlatform), rebooted. Same error.
Disabled Windows Firewall entirely (all profiles) — no change.
Manually created a NAT switch (New-VMSwitch cowork-vm-nat, New-NetIPAddress 172.20.0.1/24, New-NetNat CoworkNAT) — no change. Removed afterwards.
Restarted Hyper-V networking services (hns, vmcompute) — caused EBUSY lock on smol-bin.vhdx, required full reboot to recover.
Verified API reachability from host — Test-NetConnection api.anthropic.com -Port 443 succeeds, DNS resolves both A (160.79.104.10) and AAAA (2607:6bc0::10), HTTPS connection works.
Checked CoworkVMService — running.
Checked VM switch configuration — only "Default Switch" (Internal) present. Get-NetNat returns no entries, meaning no NAT is configured for the VM to route traffic externally.
Key observation:
The VM can reach the internet (SDK install succeeds) but cannot reach api.anthropic.com specifically. This suggests the issue is in how the VM's networking resolves or routes to the API endpoint, not a general connectivity problem.
Relevant log pattern (cowork_vm_node.log):
[VM] Network status: NOT_CONNECTED
[VM:network] Not connected, will show error in 30000ms if not resolved
[VM:steps] sdk_install started
[VM] Network status: CONNECTED
[VM:steps] sdk_install completed
[VM:start] Startup complete
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable
still present in Claude 1.1.3363 (ee4247) 2026-02-17T15:55:21.000Z
Claude's conclusions after some more troubleshooting:
Update — Feb 18, 2026 (v1.1.3363)
Updated to Claude Desktop v1.1.3363. Problem persists unchanged. Performed extensive diagnostics:
Root cause identified: VM receives a non-existent DNS server
The Cowork VM is assigned DNS 192.168.1.254, which does not exist on the network:
PS> Get-HnsEndpoint | Where {$_.Name -like "cowork"} | Select Name, IPAddress, GatewayAddress, DNSServerList
Name IPAddress GatewayAddress DNSServerList
---- --------- -------------- -------------
cowork-vm-eth0 172.16.0.47 172.16.0.1 192.168.1.254
PS> ping 192.168.1.254
Reply from 192.168.1.47: Destination host unreachable.
PS> Resolve-DnsName api.anthropic.com -Server 192.168.1.254
→ FAILS (server unreachable)
The correct DNS servers (Telefónica Spain) are 80.58.61.254 and 80.58.61.250, configured on the active Ethernet adapter:
PS> Get-DnsClientServerAddress -InterfaceAlias "Ethernet" | Select InterfaceAlias, ServerAddresses
InterfaceAlias ServerAddresses
-------------- ---------------
Ethernet {80.58.61.254, 80.58.61.250}
Why the wrong DNS? The system has ~10 network adapters, most disconnected (Tailscale, VirtualBox Host-Only, VPN Client, Wi-Fi, VirtNet, Realtek, Bluetooth, etc.). The Cowork service appears to pick up DNS from one of these inactive adapters instead of the active Ethernet interface. This matches the bug described in #25144 and #25088.
Additional finding: WinNAT rule missing
The HNS network references a NAT (NatName: NAT50A5544A-...) but Get-NetNat returns empty — no backing WinNAT rule exists. Same issue as #25155.
PS> Get-NetNat
→ (empty)
Despite this, the VM does have partial connectivity — SDK install succeeds every time, confirming the VM can reach CDN endpoints. Only the API reachability check fails, consistent with a DNS resolution failure for api.anthropic.com inside the VM.
Additional troubleshooting performed since initial report:
Disabled Windows Firewall entirely (all profiles) → no change
Manually created NAT switch + NetNat rule → Cowork ignores it, recreates its own HNS network with wrong DNS
Forced DNS on Ethernet adapter via Set-DnsClientServerAddress → Cowork still assigns 192.168.1.254
Removed HNS endpoints and network, restarted CoworkVMService → recreated with same wrong DNS
Restarted HNS and vmcompute services → caused EBUSY lock on smol-bin.vhdx, required full reboot
Conclusion: The DNS selection logic in cowork-svc.exe does not correctly identify the active network adapter on systems with multiple (mostly disconnected) adapters. This is not a user-side networking issue — it's a bug in how the service determines which DNS to assign to the VM endpoint.
Update 2 — RESOLVED with workaround
Root cause confirmed: cowork-svc.exe was picking up DNS from a disconnected Ethernet adapter ("Ethernet 2" / Realtek Gaming 2.5GbE) which had a stale DNS of 192.168.1.254 — a non-existent host on the local network.
Fix applied:
powershellDisable-NetAdapter -Name "Ethernet 2" -Confirm:$false
Then: stop Claude, stop CoworkVMService, remove HNS endpoints/network, restart service, relaunch Claude
Result: VM now receives the correct DNS from the active Ethernet adapter:
Name IPAddress GatewayAddress DNSServerList
cowork-vm-eth0 172.16.0.15 172.16.0.1 80.58.61.254,80.58.61.250
Cowork starts successfully. API is reachable.
Summary: On systems with multiple network adapters (especially disconnected ones with stale DHCP leases), cowork-svc.exe does not correctly identify the active adapter for DNS configuration. Same root cause as #25144 and #25088. The service should either enumerate only connected/active adapters, or use the DNS from the adapter with the default gateway.
Adding data point: Windows 11 Pro 24H2 (Build 26100.7623), Claude Desktop v1.1.3363, Hyper-V enabled, Windows Defender only.
Same PROBABLY\_UNREACHABLE -> UNREACHABLE pattern. Extensive manual troubleshooting attempted: NAT rule confirmed present, IP forwarding enabled on both cowork adapter and Wi-Fi, outbound firewall rule added for TCP/443, default route added manually.
Key finding: the app creates
0.0.0.0/0on the cowork adapter with NextHop 0.0.0.0 (null/black-hole route) instead of172.16.0.1. Manual correction fails with "instance already exists" -- the app-owned route blocks re-creation. No workaround found via host-side network configuration.Debug logs attached to closed issue. Closed #26476 as duplicate of this issue.
Same issue.
Same Issue.
Win 11 pro with Claude for Windows Version 1.1.3541 (1e65e4).
RESOLVED with workaround -- same root cause as #25144 and #25088.
Credit to @gpc1979 for identifying the root cause.
These manual steps are required to temporarily workaround the issue with Cowork.
Root cause:
cowork-svc.exepicks up DNS from a disconnected adapter instead of the active one. In my case, an ExpressVPN TUN adapter ("Local Area Connection") was disconnected but had a stale DNS entry of100.64.100.1-- unreachable on my network. The VM got assigned that DNS server and couldn't resolveapi.anthropic.com.How to identify the bad adapter:
Step 1 -- find disconnected adapters with stale DNS entries:
Step 2 -- verify the DNS is unreachable (replace with your DNS address from above):
If
TcpTestSucceeded: False, that adapter is your culprit.Fix:
Then relaunch Claude Desktop. Cowork started successfully.
Agreeing with @gpc1979's root cause analysis. The fix model seems straightforward: cowork-svc.exe could select DNS only from adapters that are both connected and have a default gateway, rather than iterating all adapters regardless of state.
Something like:
This would unambiguously identify the active internet-facing adapter and use its DNS. On systems with multiple adapters -- especially those with disconnected VPN, Bluetooth, or legacy adapters carrying stale DHCP leases -- the current behavior reliably picks the wrong one.
Hopefully useful context for the fix. Thanks to @gpc1979 for doing the hard diagnostic work that pointed everyone in the right direction.
---
One additional note: the adapter selection logic should cover both IPv4 and IPv6. The adapter selection logic should account for both address families, as a disconnected adapter could carry stale IPv6 DNS independently of its IPv4 configuration. The fix should not be IPv4-only.
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.