[BUG] Cowork Windows - Cannot connect to Claude API from workspace (Windows 11 Home)
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?
After Cowork Windows launch (Feb 10, 2026), Cowork consistently fails to connect to the Claude API on Windows 11 Home.
The workspace attempts to start but always ends with "ワークスペースからClaude APIに接続できません" (Cannot connect to Claude API from workspace).
Regular Chat mode works perfectly. Only Cowork is affected.
Environment:
- OS: Windows 11 Home (latest updates)
- Claude Desktop: Latest version (downloaded Feb 11, 2026)
- WSL2: Installed (Ubuntu)
- Windows Features: Virtual Machine Platform ✅, Windows Hypervisor Platform ✅, Hyper-V ❌ (not available on Home)
- VPN: None
- Firewall: Windows Defender — Claude allowed on both Private and Public
- Antivirus: AhnLab Safe Transaction installed but not running during tests
What Should Happen?
Cowork workspace should start successfully and connect to the Claude API, allowing task execution — the same way regular Chat mode works without issues.
Error Messages/Logs
Error messages appear in this order:
1. "申し訳ございません。Claude APIへの接続に時間がかかっています..."
(Taking longer than expected to connect to Claude API)
2. "Claude のワークスペースの起動に失敗しました - ワークスペースからClaude APIに接続できません"
(Failed to start workspace - Cannot connect to Claude API from workspace)
Previously also saw (before installing WSL2):
- "お使いのコンピュータがClaudeのワークスペースへのネットワーク接続を提供していません"
(Computer is not providing network connection to workspace)
Note: After installing WSL2, the error changed from "network not provided" to "cannot connect to API", suggesting the VM can now get network access but something still blocks the API connection.Steps to Reproduce
- Install Claude Desktop on Windows 11 Home (latest version, Feb 2026)
- Open Claude Desktop
- Switch to Cowork tab
- Attempt to start any task
- Wait ~60 seconds
- Observe: "Claude APIに接続できません" error appears
Troubleshooting steps attempted (all failed):
- Reinstalled Claude Desktop twice (complete uninstall + fresh install)
- Deleted VM bundles and cache folders
- Verified Windows Defender Firewall allows Claude (Private + Public)
- Installed WSL2 via "wsl --install"
- Ran Claude Desktop as Administrator
- Reset network (netsh winsock reset, netsh int ip reset, ipconfig /flushdns)
- Disabled AhnLab Safe Transaction
- Multiple reboots
Possibly related: #18854, #18006, #24070, #17868 (all macOS, same API connection symptoms)
This is a Day 1 Windows launch issue. Would appreciate clarification on whether Windows 11 Home is officially supported or if Hyper-V (Pro/Enterprise) is required.
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
Claude Desktop latest version (Windows, downloaded Feb 11, 2026). This is Cowork on Claude Desktop, not Claude Code CLI.
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
- This is a Cowork issue on Claude Desktop, not Claude Code CLI
- Windows 11 Home does NOT have Hyper-V — only Virtual Machine Platform + Windows Hypervisor Platform are available
- Cowork for Windows was released Feb 10, 2026 — this is a Day 1 issue
- Regular Chat mode works perfectly in the same app
- It's unclear if Cowork Windows officially supports Windows 11 Home or requires Pro/Enterprise for Hyper-V
- Would appreciate clarification on minimum Windows edition requirements
107 Comments
I had the same issue on Windows 11, and changing DNS solved it for me.
Symptoms:
What fixed it:
After this, Cowork started normally. This might be DNS path/resolution related.
Thanks for sharing! I tried changing DNS to 1.1.1.1 / 8.8.8.8 but unfortunately it didn't resolve the issue on my end (Windows 11 Home, #24918). Still getting the same API connection error.
I'm experiencing the same problem on Windows 11 Home. Cowork consistently fails to connect to the Claude API from workspace, while regular Chat mode works perfectly.
I experienced the same problem, but after a full restart of windows, it resolved that issue. Now i have another one: Impossibile avviare l'area di lavoro di Claude
VM service not running. The service failed to start.
Riavviare Claude o il computer a volte risolve il problema. Se persiste, puoi reinstallare l'area di lavoro o condividere i tuoi log di debug per aiutarci a migliorare.
<img width="362" height="266" alt="Image" src="https://github.com/user-attachments/assets/2887e269-7006-4561-860e-47f241a0b127" />
Experiencing the same issue on Windows 11 Pro (not Home edition).
Environment:
OS: Windows 11 Pro, Version 24H2, Build 26100.7840
Claude Desktop: Latest version, downloaded Feb 11, 2026
Hyper-V: ✅ Enabled (all components checked)
Windows: Fully updated
Virtual Machine Platform: ✅ Enabled
Windows Hypervisor Platform: ✅ Enabled
VPN/Proxy: None
Firewall: Windows Defender - Claude allowed on both Private and Public networks
Symptoms:
Regular Chat mode works perfectly
Cowork shows: "Sorry, it's taking a while to connect to the Claude API... Taking longer than expected to reach the Claude API. Still trying..."
Eventually times out with: "Failed to start Claude's workspace - Can't reach the Claude API from Claude's workspace"
VM appears to start (gets past initialization) but cannot reach api.anthropic.com
Timeline:
Downloaded and installed Claude Desktop today (Feb 11, 2026)
Initially had Hyper-V disabled - enabled it and rebooted
Fully updated Windows
Issue persists after all troubleshooting
Notes:
This confirms the issue affects Windows 11 Pro users (with Hyper-V available and enabled), not just Home edition
The error message doesn't mention Hyper-V requirements, which could help users troubleshoot
This is a Day 1 Windows Cowork launch issue
I'm also experiencing this problem with Windows 11 Pro. Uninstalled Claude, enabled Hyper-V, rebooted, and reinstalled Claude. The problem persists.
Having the same issue as well
I also have the same issue today on Windows 11 Pro.
Tried to reinstall Windows 11 completely by doing a clean Install from a USB drivt (reinstall was planned anyway).
After reinstalling windows 11 pro, and downloading Claude desktop, i don't even see the Copilot tab anymore.
Note: Im now on a fresh windows 11 pro, only installed chrome, git for windows, Node and Claude Desktop. Chat and Code works, but the Copilot tab is not visible.
I have this same issue on Windows 11 Pro. Tried all of the recommended work-arounds and get the same result
Root Cause Found + Working Fix (Windows 11 Home)
Courtesy of Claude Code 4.6 on 2.1.39 as directed by @gabefletcher @ThariqS
After deep-diving into the HNS (Host Networking Service) internals, I found the exact root cause of the DNS misconfiguration.
The Bug
cowork-svc.exereads DNS server addresses from the wrong network adapter. On systems with Microsoft Wi-Fi Direct Virtual Adapters (present on most Windows machines — used for Mobile Hotspot/Miracast), the service picks up a stale DNS address from a disconnected Wi-Fi Direct adapter instead of the active internet-connected adapter.Evidence from HNS endpoint inspection:
The cowork-vm-nat HNS network itself had no DNSServerList set (unlike the WSL network which correctly sets its own). So the endpoints inherit DNS from whatever
cowork-svc.exedetects — and it detects the wrong adapter.Diagnostic Commands Used
Working Fix (3 steps)
Step 1: Set public DNS on the real Wi-Fi adapter
Settings → Network → Wi-Fi → Properties → DNS → Manual →
1.1.1.1/8.8.8.8Step 2: Enable IP forwarding
Step 3: Disable Wi-Fi Direct adapters (the critical fix)
Step 4: Restart Claude Desktop
Quit fully (system tray → Quit), reopen. Cowork VM will recreate endpoints with the correct DNS.
Side effect: Mobile Hotspot and Miracast won't work while Wi-Fi Direct is disabled. Re-enable with:
Suggested Code Fix for
cowork-svc.exeThe DNS detection logic should filter adapters to only those that are:
Something like:
Environment
Additional Observations
New-NetNat). NAT is not the issue on this system.vEthernet (cowork-vm-nat)andWi-Fi— enabling it via registry helped but wasn't sufficient alone.cowork-svc.exealso tries to run macOS commands (/sbin/ifconfig,/usr/sbin/scutil) on Windows — platform detection bug (see #24962).Related: #24962, #24945, #25088
Environment:
Error:
After Cowork tab appeared and a task was submitted:
Notes:
Is the fix verified? This seems to change some fundamental system parameters and I am cautios with that.
Also having the same bug, which is very unfortunate because tomorrow I was to present my first Cowork experiences at our company wide AI Meetup
It seems @gfsaaser24 is on the right track here. Running some of diagnostic commands revealed that the cowork-vm-eth0 got a wrong DNS server. They got DNS server from my ethernet interface which I am not using (my PC has both ethernet and wifi, I am currently using only wifi).
UPDATE: A simpler fix:
Run the following commands in an elevated (admin) powershell:
Get-HnsEndpoint | Select Name, DNSServerListto see which DNS server the VM received.Get-DnsClientServerAddressto find the interface which has the same, wrong dns server, not the Interface IndexSet-DnsClientServerAddress -InterfaceIndex 17 -ServerAddresses ("1.1.1.1","8.8.8.8")to change the DNS server for that interface (replace the value17with the ID you noted in step 2).Restart Claude.
I did also manually change the DNS servers of the cowork network interface. I'm not sure if this step is required.
@Inrego's simpler fix worked for me!
Ran
Get-DnsClientServerAddressin admin PowerShell — found "로컬 영역 연결 2" (Local Area Connection* 2, Interface Index 19) had DNS100.64.100.1, which was being passed to the Cowork VM.Fixed with:
Set-DnsClientServerAddress -InterfaceIndex 19 -ServerAddresses ("1.1.1.1","8.8.8.8")
Restarted Claude Desktop → Cowork works now.
Thanks to @gfsaaser24 for finding the root cause and @Inrego for the simplified fix.
{RESOLVED} Confirmed same issue on Lenovo ThinkPad T14 Gen 6 (Intel Ultra 7 255U, Win 11 Business Build 26200, Intel Wi-Fi 6E AX211). In my case cowork-svc.exe grabbed DNS from a disconnected Ethernet adapter (192.168.1.1) rather than active Wi-Fi. Disabling Wi-Fi Direct adapters alone wasn't enough — had to disable the disconnected Ethernet adapter entirely (
Disable-NetAdapter -Name "Ethernet" -Confirm:$false) and set public DNS (1.1.1.1/9.9.9.9) on Wi-Fi. After stopping CoworkVMService, removing stale HNS network (Get-HnsNetwork | Where-Object { $_.Name -match "cowork" } | Remove-HnsNetwork), and restarting the service — Cowork launched successfully. +1 on the suggested fix for cowork-svc.exe to filter by active adapters with a default gateway.Same symptoms here > DNS fix + manual service restart resolved it.****
Not a developer, just sharing my experience in case it helps others on this issue. Apologies if I'm not following the usual formatting conventions.
Environment:
Context:
Claude Desktop frequently suffers from gray screen freezes (possibly related to what appears to be a common issue with Chromium + NVIDIA RTX 50 series + multi-monitor — not sure though, this one is still a pain). When this happens, the only option is to kill the process via Task Manager. After that, Cowork consistently fails to restart — the
CoworkVMServicestays Stopped and never recovers on its own. A full computer reboot fixes it, but that's a nightmare in the middle of a workflow.Symptoms:
CoworkVMServicestatus: Stopped (StartType: Automatic)vmcomputerunning fineWhat fixed it (without rebooting):
Step 1 — Force public DNS on network adapters (admin PowerShell):
(Indexes 4 and 8 = Ethernet and Wi-Fi adapters, both pointed to local router DNS 192.168.178.1 which the VM couldn't resolve through.)
Step 2 — Manually restart the Cowork VM service:
The service was Stopped despite StartType: Automatic. It does not auto-recover after a force-kill of Claude Desktop.
Step 3 — Full quit of Claude Desktop from system tray, then reopen.
Cowork launched successfully after this.
Update: Since applying this fix, I've had 3 gray screen freezes forcing me to kill Claude Desktop processes. Each time, repeating Steps 2 and 3 was enough to get Cowork back up and running without a full machine reboot. Confirmed working.
Note: The
CoworkVMServiceshould ideally auto-recover or be restarted by Claude Desktop on launch, so users don't have to manually restart it every time.Thanks to @gfsaaser24 for the root cause analysis and @Inrego for the simplified DNS fix.
@Inrego Thank . you solved this !
In my case,
Ethernet (Index 18): DNS = xxx.xxx.xxx.x (NOT ACTIVE)
Wi-Fi 2 (Index 13): DNS = xxx.xxx.xxx.x (ACTIVE - this is what you're using)
vEthernet (cowork-vm-nat) (Index 44): DNS = empty for IPv4, only has IPv6
The VM network adapter doesn't have proper IPv4 DNS configured!
so , i just have run the below command in powershell as adminstrator
Set DNS for the unused Ethernet interface
Set-DnsClientServerAddress -InterfaceIndex 18 -ServerAddresses ("1.1.1.1","8.8.8.8")
Set DNS for the VM network adapter
Set-DnsClientServerAddress -InterfaceIndex 44 -ServerAddresses ("192.168.100.1")
Verify the changes
Get-DnsClientServerAddress | Select-Object InterfaceAlias, InterfaceIndex, ServerAddresses | Format-Table -AutoSize
close and restart - SOLVED
Confirming @Inrego's fix worked on Windows 11 Home.
Environment:
What fixed it:
Followed @Inrego's steps - identified the VM was picking up DNS from the wrong network adapter, changed it to the correct DNS via PowerShell, and restarted Claude. Cowork connected successfully after that.
Separate issue:
Getting this error when attempting to share a screenshot in Cowork:
Confirming @gfsaaser24 's root cause and @Inrego 's fix also works on Windows 11 Pro + wired Ethernet + VirtualBox setup.
Environment: Win 11 Pro, ASUS motherboard, Realtek Gaming 2.5GbE (primary), VirtualBox Host-Only Adapter
Had two issues:
"VM service not running" — CoworkVMService was Stopped. Had to manually run Start-Service CoworkVMService every time.
"Can't reach the Claude API" — VM got DNS from an inactive adapter ("Ethernet 2", Index 5) — a private/internal DNS that couldn't resolve api.anthropic.com from inside the VM.
Fix (admin PowerShell):
Then reopen Claude Desktop → Cowork works.
Note: CoworkVMService does not auto-start after Claude restarts. Workarounds:
Option A — Set service auto-recovery (run once):
Option B — Create a .bat file on desktop for one-click launch (right-click → Run as Administrator):
+1 on the need for Anthropic to fix both DNS adapter detection and service auto-recovery.
The DNS 'fix' is an issue because in my case, it's pulling the DNS servers from my ZTNA VPN virtual adapter, and if I change it, it breaks my VPN, so I can EITHER have cowork OR ZTNA but not both.
@Inrego fix worked for me as well, thanks a lot
I will wait for the official fix rather than using these workarounds. I
hope it will be released soon.
Ing. Giulio Rizzo
Cell: (+39) 3288141675
Email: @.***
Il Gio 12 Feb 2026, 18:26 GP @.***> ha scritto:
I've been bouncing back and forth between the API error and the VM error. Mac works fine with it.
A summary of the work (and a short version of many things tried, including much of the above)
Issue: Persistent "VM service not running" / "Can't reach API" error in Cowork tab.
Environment: Windows 11 Home (Build 26200.x), x64 architecture.
System Integrity: Ran sfc /scannow and DISM /RestoreHealth (both returned 100% clean).
Virtualization: Verified hypervisorlaunchtype is auto. Enabled "Virtual Machine Platform" and "Windows Hypervisor Platform" via DISM. systeminfo confirms a hypervisor is detected.
Networking: Performed netcfg -d reset. Enabled IP Routing (IPEnableRouter=1) and started RemoteAccess service.
App Level: Deleted %AppData%\Claude\vm_bundles and sessions multiple times to force a fresh download.
Conflict Check: Identified Cloudflare WARP and ExpressVPN drivers; disabled them to test, but the VM still failed to reach the API.
Outcome: Despite all services running and vEthernet (cowork-vm-nat) appearing, the workspace fails with a "VM service not running" loop. Turned off local firewall. no effect.
ITS FIXED!!!!
I was seeing similar errors. But in my case the issue was ExpressVPN driver conflict (even though my ExpressVPN was not in the tray or enabled). Disabling the drivers got rid of the issue.
<img width="803" height="599" alt="Image" src="https://github.com/user-attachments/assets/d55398c5-8732-4a9b-8b64-de4dc62aa4a3" />
Thank my problem is with sophos vpn tap interface
Edit as per https://github.com/anthropics/claude-code/issues/24918#issuecomment-3888977751
it is more practical to set the DNS of this adapter, instead of disabling it. Disregard below.
I am on wifi. In addition to other unused adapters, I had to disable my real (unconnected) ethernet adapter.
Caution:
Remember to re-enable it if it doesn't work, or if you need your ethernet port later on
Or you could've changed DNS servers of your Ethernet adapter as I instructed
Inrego your comment was hidden. This is a better solution. Thanks.
Thank you so much!!!
Thanks @Inrego its works perfectly fine after executing this command Disable-NetAdapter -Name "Ethernet" -Confirm:$false
You're welcome, but that is definitely not the command I suggested. Let's hope you won't need your Ethernet port any time soon 😊
I got Co-work to function on my desktop with Windows 11 Pro, but it would not work at all on my laptop with Windows 11 Pro. I asked Claude to write a script to pull the configuration from both computers and diagnose the issue. It was successful and it wrote up what it did. Hopefully this helps other folks!
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>[FIX] Cowork Windows — <code>rootfs.vhdx origin missing</code> / VM fails to start after corrupted or incomplete bundle download</h1>
<h2>Summary</h2>
<p>After installing Claude Desktop for Windows with Cowork (v1.1.2998.0, MSIX), the Cowork tab either fails to launch tasks, shows "Cannot connect to Claude API from workspace," or the VM enters a loop of keepalive ping timeouts. The root cause is a corrupted or incomplete VM bundle — specifically, the <code>rootfs.vhdx</code> origin metadata files are missing, causing the VM to fail startup and enter a perpetual redownload/retry loop that never resolves on its own.</p>
<p>This was diagnosed by comparing a working Windows 11 Pro desktop against a failing Windows 11 Pro laptop with nearly identical configurations, isolating the VM bundle as the sole point of failure.</p>
<h2>Environment</h2>
| Working Machine (Desktop) | Failing Machine (Laptop)
-- | -- | --
OS | Windows 11 Pro 10.0.26200 (x64) | Windows 11 Pro 10.0.26200 (x64)
CPU | Intel i7-13700K (Architecture: 9/x64) | Intel i9-14900HX (Architecture: 9/x64)
RAM | 63.7 GB | 63.6 GB
Claude Desktop | v1.1.2998.0 (MSIX, Developer-signed) | v1.1.2998.0 (MSIX, Developer-signed)
Developer Mode | Enabled | Enabled
VirtualMachinePlatform | Enabled | Enabled
Hyper-V | Disabled (not needed) | Fully enabled (also works)
CoworkVMService | Running / Automatic | Running / Automatic
vmcompute | Running | Running
HNS | Running, cowork-vm-nat present | Running, cowork-vm-nat present
Squirrel (legacy) install | None | None
Setup log | Clean install, exit code 0 | Clean install, exit code 0
<p>Both machines had identical, clean installation paths. The setup logs showed no errors on either machine. All services were running. The <strong>only</strong> difference was in the Cowork VM runtime behavior.</p>
<h2>Symptoms</h2>
<p>The Cowork VM log (<code>%APPDATA%\Claude\logs\cowork_vm_node.log</code>) on the failing machine showed:</p>
<p><strong>Stage 1 — Origin metadata missing, triggering redownload loop:</strong></p>
<pre><code>[Bundle:status] rootfs.vhdx origin missing
rootfs.vhdx origin missing, redownloading...
Downloading rootfs.vhdx...
[downloadVM] Download already in progress, waiting...
[startVM] VM startup already in progress, waiting...
</code></pre>
<p>The <code>.rootfs.vhdx.origin</code> file (a 40-byte hash reference) was missing or corrupted, causing the bundle status check to fail. The download would start but never complete, entering an infinite wait loop.</p>
<p><strong>Stage 2 — Keepalive failures (consequence, not cause):</strong></p>
<pre><code>[Keepalive] Ping failed: Keep-alive ping timed out
[Keepalive] Ping failed: Keep-alive ping timed out
(repeating every 2 seconds indefinitely)
</code></pre>
<p><strong>Stage 3 — Processes spawned but immediately killed:</strong></p>
<pre><code>[Process:...] Created, name=serene-busy-hypatia, total active=1
[CoworkVMProcess:...] kill called with signal: SIGTERM
[CoworkVMProcess:...] kill called with signal: SIGTERM
[Process:...] Exited, code=0, signal=null, duration=3175ms, oom=false
[CoworkVMProcess:...] kill called with signal: SIGKILL
</code></pre>
<p>The VM would attempt to start a Cowork process, but because the underlying VM wasn't healthy, the process would be terminated within ~3 seconds.</p>
<h2>Root Cause</h2>
<p>The VM bundle at <code>%APPDATA%\Claude\vm_bundles\claudevm.bundle\</code> was in an inconsistent state — likely caused by an interrupted download (laptop sleep, Wi-Fi drop, etc.) during initial Cowork setup. The <code>.origin</code> metadata files (which store content hashes for integrity checking) were missing, but the partially downloaded files may have still been present, creating a state where the system knew the bundle was bad but couldn't cleanly recover.</p>
<h2>Fix</h2>
<h3>Step 1 — Stop services and kill Claude processes</h3>
<p>Open <strong>PowerShell as Administrator</strong>:</p>
<pre><code class="language-powershell">Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
Stop-Service vmcompute -Force -ErrorAction SilentlyContinue
Get-Process | Where-Object { $_.ProcessName -match 'claude|cowork' } | Stop-Process -Force
</code></pre>
<h3>Step 2 — Delete the corrupted VM bundle</h3>
<pre><code class="language-powershell">$bundlePath = "$env:APPDATA\Claude\vm_bundles"
if (Test-Path $bundlePath) {
Remove-Item -Path $bundlePath -Recurse -Force
Write-Host "Removed: $bundlePath"
} else {
Write-Host "Bundle path not found (already clean)"
}
</code></pre>
<h3>Step 3 — Clear cached/warm files</h3>
<pre><code class="language-powershell">foreach ($p in @("$env:APPDATA\Claude\vm_cache", "$env:APPDATA\Claude\vm_warm")) {
if (Test-Path $p) {
Remove-Item -Path $p -Recurse -Force
Write-Host "Removed: $p"
}
}
</code></pre>
<h3>Step 4 — Restart services and launch Claude</h3>
<pre><code class="language-powershell">Start-Service vmcompute
Start-Service CoworkVMService
</code></pre>
<p>Then launch Claude Desktop and switch to the Cowork tab. <strong>Ensure you are on a stable, uninterrupted internet connection.</strong> The VM bundle (~1 GB total) will redownload from scratch.</p>
<h3>Step 5 — Verify</h3>
<p>Check the VM log for a healthy startup sequence:</p>
<pre><code class="language-powershell">Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 30
</code></pre>
<p>A successful startup looks like:</p>
<pre><code>rootfs.vhdx.zst checksum validated
vmlinuz.zst checksum validated
initrd.zst checksum validated
All files ready in ...\claudevm.bundle
[VM:steps] download_and_sdk_prepare completed
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[VM:steps] sdk_install completed
[VM:start] Startup complete
[Keepalive] Starting (interval=2000ms)
[startVM] VM already connected
</code></pre>
<p>You can also verify the bundle contents:</p>
<pre><code class="language-powershell">Get-ChildItem "$env:APPDATA\Claude\vm_bundles\claudevm.bundle" |
Select-Object Name, Length | Format-Table -AutoSize
</code></pre>
<p>Expected files include <code>rootfs.vhdx</code> (~900+ MB), <code>initrd</code>, <code>vmlinuz</code>, <code>sessiondata.vhdx</code>, <code>smol-bin.vhdx</code>, their <code>.zst</code> compressed counterparts, and six <code>.origin</code> files (40 bytes each).</p>
<h2>Diagnostic Script</h2>
<p>If you need to gather system information to compare working vs. non-working machines, this PowerShell script (run as Administrator) captures all relevant configuration:</p>
<details>
<summary>Click to expand full diagnostic script</summary>
<pre><code class="language-powershell">$report = @()
$report += "===== COWORK DIAGNOSTICS REPORT ====="
$report += "Generated: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
$report += "Computer: $env:COMPUTERNAME"
$report += ""
--- OS & Hardware ---
$report += "===== OS & HARDWARE ====="
$os = Get-CimInstance Win32_OperatingSystem
$cpu = Get-CimInstance Win32_Processor
$report += "OS: $($os.Caption) $($os.Version) Build $($os.BuildNumber)"
$report += "OS Architecture: $($os.OSArchitecture)"
$report += "Edition ID: $(Get-ItemPropertyValue 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name EditionID)"
$report += "CPU: $($cpu.Name)"
$report += "CPU Architecture: $($cpu.Architecture)"
$report += "RAM (GB): $([math]::Round($os.TotalVisibleMemorySize/1MB, 1))"
$report += ""
--- BIOS Virtualization ---
$report += "===== BIOS VIRTUALIZATION ====="
$report += "VirtualizationFirmwareEnabled: $($cpu.VirtualizationFirmwareEnabled)"
$report += "VMMonitorModeExtensions: $($cpu.VMMonitorModeExtensions)"
$hypervisor = (Get-CimInstance Win32_ComputerSystem).HypervisorPresent
$report += "HypervisorPresent: $hypervisor"
$report += ""
--- Windows Features ---
$report += "===== WINDOWS FEATURES ====="
$features = @(
'Microsoft-Hyper-V-All', 'Microsoft-Hyper-V',
'Microsoft-Hyper-V-Management-PowerShell', 'Microsoft-Hyper-V-Hypervisor',
'Microsoft-Hyper-V-Services', 'VirtualMachinePlatform',
'HypervisorPlatform', 'Microsoft-Windows-Subsystem-Linux', 'Containers'
)
foreach ($f in $features) {
try {
$state = (Get-WindowsOptionalFeature -Online -FeatureName $f -ErrorAction SilentlyContinue).State
$report += "${f}: $state"
} catch { $report += "${f}: NOT AVAILABLE" }
}
$report += ""
--- Services ---
$report += "===== RELEVANT SERVICES ====="
foreach ($s in @('vmcompute', 'vmms', 'CoworkVMService', 'HNS', 'WslService')) {
try {
$svc = Get-Service -Name $s -ErrorAction SilentlyContinue
if ($svc) { $report += "${s}: Status=$($svc.Status), StartType=$($svc.StartType)" }
else { $report += "${s}: NOT FOUND" }
} catch { $report += "${s}: NOT FOUND" }
}
$report += ""
--- HNS Networks ---
$report += "===== HNS NETWORKS ====="
try {
$hns = Get-HnsNetwork -ErrorAction SilentlyContinue
if ($hns) { $hns | ForEach-Object { $report += "Network: $($_.Name) Type=$($_.Type) Id=$($_.Id)" } }
else { $report += "No HNS networks found" }
} catch { $report += "Get-HnsNetwork not available" }
$report += ""
--- Claude Installation ---
$report += "===== CLAUDE DESKTOP INSTALLATION ====="
try {
$msix = Get-AppxPackage -Name "Claude" -ErrorAction SilentlyContinue
if ($msix) {
$msix | ForEach-Object {
$report += "MSIX Package: $($_.Name) v$($_.Version)"
$report += " PackageFullName: $($_.PackageFullName)"
$report += " SignatureKind: $($_.SignatureKind)"
}
} else { $report += "No MSIX Claude package found" }
} catch { $report += "Error checking MSIX packages" }
$report += "Squirrel install exists: $(Test-Path "$env:LOCALAPPDATA\AnthropicClaude")"
$report += ""
--- Developer Mode ---
$report += "===== DEVELOPER MODE ====="
try {
$devMode = Get-ItemPropertyValue 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' -Name 'AllowDevelopmentWithoutDevLicense' -ErrorAction SilentlyContinue
$report += "Developer Mode: $(if ($devMode -eq 1) {'Enabled'} else {'Disabled'})"
} catch { $report += "Developer Mode: Could not determine" }
$report += ""
--- VM Bundle Status ---
$report += "===== VM BUNDLE STATUS ====="
$bundlePath = "$env:APPDATA\Claude\vm_bundles\claudevm.bundle"
if (Test-Path $bundlePath) {
Get-ChildItem $bundlePath | ForEach-Object {
$report += "$($_.Name): $($_.Length) bytes (modified $($_.LastWriteTime))"
}
} else { $report += "VM bundle directory does not exist" }
$report += ""
--- Logs ---
$report += "===== COWORK VM LOG (LAST 30 LINES) ====="
$logPath = "$env:APPDATA\Claude\logs\cowork_vm_node.log"
if (Test-Path $logPath) { $report += Get-Content $logPath -Tail 30 }
else { $report += "Log not found" }
$report += ""
$report += "===== CLAUDE SETUP LOG (LAST 30 LINES) ====="
$setupLog = "$env:LOCALAPPDATA\Temp\ClaudeSetup.log"
if (Test-Path $setupLog) { $report += Get-Content $setupLog -Tail 30 }
else { $report += "Setup log not found" }
--- Output ---
$outFile = "$env:USERPROFILE\Desktop\CoworkDiagnostics.txt"
$report | Out-File -FilePath $outFile -Encoding UTF8
Write-Host "`nReport saved to: $outFile" -ForegroundColor Green
</code></pre>
</details>
<h2>Additional Notes</h2>
<ul>
<li>This issue likely affects anyone whose initial Cowork VM bundle download was interrupted — common on laptops (sleep/wake, Wi-Fi transitions).</li>
<li>The system does not appear to self-recover from this state; manual deletion of the bundle directory is required.</li>
<li>Full Hyper-V is <strong>not</strong> required — <code>VirtualMachinePlatform</code> alone is sufficient (confirmed working on the desktop machine with all Hyper-V features disabled).</li>
<li>The MSIX installation itself is not the issue in this case — both the setup log and package state were clean.</li>
<li>Related issues: #24918 (API connectivity on Win 11 Home), #25136 (yukonSilver unsupported), #25162 (Squirrel-to-MSIX upgrade failure), #25313 (in-app updater not delivering Cowork build).</li>
</ul>
<h2>System Information</h2>
<ul>
<li><strong>Claude Desktop</strong>: v1.1.2998.0 (MSIX, Developer-signed)</li>
<li><strong>OS</strong>: Windows 11 Pro 10.0.26200 Build 26200 (x64)</li>
<li><strong>Platform</strong>: Windows (both Intel 13th and 14th gen confirmed)</li>
</ul></body></html><!--EndFragment-->
</body>
</html>
Same issue — Windows 11 Home, API unreachable from Cowork VM
Environment:
Windows Features enabled:
Services:
HNS Network created correctly:
Root cause confirmed — no WinNAT, no route:
Get-NetNatreturns EMPTY — no NAT rule is createdNew-NetNatfails with "duplicate name exists" error (even though Get-NetNat is empty)route print 172.16.0.0returns NO routes (IPv4 and IPv6 both empty)Troubleshooting attempted (none worked):
Conclusion:
The HNS network is created with type NAT and a NatName, but the corresponding WinNAT rule is never registered in Windows networking stack. Without NAT + routes, the VM has no path to the internet. This appears to be a bug in how Claude Desktop sets up networking on Windows 11 Home.
The @Inrego fix of
Get-HnsEndpoint | Select Name, DNSServerList,Get-DnsClientServerAddress, andSet-DnsClientServerAddress -InterfaceIndex [interface index of the one with the wrong DNS] -ServerAddresses ("1.1.1.1","8.8.8.8")worked for me as well.You're a genius! Great job figuring this out - the fix worked for me! (Had to change network adapter names to match mine of course, but thanks for putting the time into this!)
Also had same issue. API wouldn't connect. Tried most of the other fixes listed including DNS change, flushing the network, multi reinstalls/reboot.
The fix for me (Windows Home 11):
Claude Desktop “validation_failed” and Cowork API errors were caused by Windows Time not syncing (Stratum 0, Local CMOS). TLS validation failed silently.
Re-registering w32time and syncing to time.cloudflare.com fixed everything. If Cowork won’t connect, check your system clock first.
@Inrego smooth solution and worked after 3h trying to solve it, thanks a lot!
1 - open Power Shell on Windows
2 - "Get-HnsEndpoint | Select Name, DNSServerList" command
3 - "Get-DnsClientServerAddress" command
4 - find the ethernet port as Interface Index 20
5 - restart Claude
6 - worked as well
Windows 11 Home
Lenovo laptop
Intel Wi-Fi 6E AX211
Tried:
reload,
reboot,
changing DNS settings,
the powershell fix above,
removing and reloading through powershell with Claude's guidance.
No luck. Still getting:
Failed to start Claude's workspace
Can't reach the Claude API from Claude's workspace.
Excited to actually start working with cowork. But can't spend any more hours right now.
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>[BUG] Cowork VM API unreachable on Windows 11 Pro — phantom DNS, missing NAT rule, time service dead</h1>
<h2>Preflight Checklist</h2>
<ul>
<li>[x] I have searched existing issues and this hasn't been reported yet</li>
<li>[x] This is a single bug report</li>
<li>[x] I am using the latest version of Claude Desktop</li>
</ul>
<h2>Environment</h2>
Detail | Value
-- | --
Device | Lenovo Yoga Slim 7 15ILL9 (Aura Edition)
Processor | Intel Core Ultra 7 258V (2.20 GHz)
RAM | 32 GB DDR5
OS | Windows 11 Pro, Version 25H2, Build 26200.7840
Claude Desktop | v1.1.3189.0 (MSIX)
Hyper-V | Enabled (all components)
Wi-Fi | Intel Wi-Fi 7 BE201 320MHz
Router | eero (mesh network)
VPN | ExpressVPN installed (fully disconnected and adapters disabled during all testing)
WSL | Ubuntu (Stopped, Version 2)
Plan | Max
<h2>What's Wrong</h2>
<p>Cowork consistently fails with "Can't reach the Claude API from Claude's workspace." Regular Chat mode works perfectly. Only Cowork is affected.</p>
<p>The VM boots, network connects, SDK installs, and a process spawns, but the API reachability check always fails: <code>PROBABLY_UNREACHABLE</code> then <code>UNREACHABLE</code>.</p>
<h2>Three Root Causes Identified</h2>
<h3>1. Phantom DNS injection (192.168.49.1)</h3>
<p>The Cowork VM was consistently assigned DNS <code>192.168.49.1</code>, which does not exist anywhere in the system configuration.</p>
<p><strong>Evidence:</strong></p>
<pre><code>PS> Get-HnsEndpoint | Format-List Name, DNSServerList
Name : cowork-vm-eth0
DNSServerList : 192.168.49.1
</code></pre>
<p>This IP is not present on any adapter, hidden or visible:</p>
<pre><code>PS> ipconfig /all | findstr "192.168.49"
(no results)
PS> Get-NetIPAddress | Where-Object { $_.IPAddress -like "192.168.49.*" }
(no results)
</code></pre>
<p>Docker, Minikube, and Kubernetes are not installed. The source of <code>192.168.49.1</code> is unknown.</p>
<p>Manual DNS override via <code>Set-DnsClientServerAddress</code> was immediately overwritten by Cowork on every launch, reverting to <code>192.168.49.1</code>.</p>
<p>After a full VM bundle rebuild (<code>Remove-Item -Path "$env:APPDATA\Claude\vm_bundles" -Recurse -Force</code>), the DNS changed to <code>100.64.100.1</code> (appears to be Cowork's internal resolver), but the API remained unreachable.</p>
<h3>2. Missing NAT rule</h3>
<p><code>Get-NetNat</code> returns empty. No NAT rule exists to route traffic from the VM (172.16.0.0/24) to the internet.</p>
<p>Attempting to create one manually fails:</p>
<pre><code>PS> New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
New-NetNat : You were not connected because a duplicate name exists on the network.
</code></pre>
<p>The HNS network exists with type NAT, but the corresponding WinNAT rule is never registered in the Windows networking stack:</p>
<pre><code>PS> Get-HnsNetwork | Format-List Name, Type, Subnets
Name : cowork-vm-nat
Type : NAT
Subnets : {@{AddressPrefix=172.16.0.0/24; GatewayAddress=172.16.0.1; ...}}
</code></pre>
<h3>3. Windows Time service was stopped</h3>
<p><code>w32tm /query /status</code> returned: "The service has not been started. (0x80070426)"</p>
<p>This caused silent TLS validation failures. After fixing the time service (re-registering w32time and syncing to time.cloudflare.com), the error briefly changed from "Can't reach the Claude API" to "VM service not running. The service failed to start." This confirms time sync was a contributing factor, but fixing it alone did not resolve the issue.</p>
<h2>Full Troubleshooting Steps Attempted (all failed)</h2>
<ol>
<li>Enabled Hyper-V (was disabled by default on this machine)</li>
<li>Set manual DNS to 8.8.8.8 / 8.8.4.4 (IPv4) and 2001:4860:4860::8888 / 2001:4860:4860::8844 (IPv6) with DNS-over-HTTPS enabled</li>
<li>Disabled ExpressVPN adapters (TUN Driver, TAP Adapter, OpenVPN Data Channel Offload)</li>
<li>Disabled Bluetooth Device (Personal Area Network) adapter</li>
<li>Attempted to disable phantom Wi-Fi 3 and Wi-Fi 5 adapters (failed: "requested operation not supported on adapter")</li>
<li>Ran HNS cleanup multiple times (<code>Remove-HnsEndpoint</code> and <code>Remove-HnsNetwork</code>)</li>
<li>Manually overrode DNS on cowork-vm-nat interface (<code>Set-DnsClientServerAddress -InterfaceAlias "vEthernet (cowork-vm-nat)" -ServerAddresses ("8.8.8.8","8.8.4.4")</code>) — Cowork overwrote on every launch</li>
<li>Fixed Windows Time service (<code>w32tm /unregister</code>, <code>/register</code>, synced to time.cloudflare.com) — Stratum 4 confirmed</li>
<li>Set IP forwarding on cowork-vm-nat (<code>Set-NetIPInterface -Forwarding Enabled</code>)</li>
<li>Attempted <code>New-NetNat</code> — failed with "duplicate name exists" despite <code>Get-NetNat</code> returning empty</li>
<li>Clicked "Reinstall the workspace" in Claude Desktop</li>
<li>Full VM bundle deletion and rebuild (<code>Remove-Item "$env:APPDATA\Claude\vm_bundles" -Recurse -Force</code>)</li>
<li>Restarted CoworkVMService and vmcompute services multiple times</li>
<li>Multiple full PC restarts</li>
</ol>
<h2>VM Log (final attempt)</h2>
<pre><code>2026-02-15 16:42:18 [info] [VM:start] Configuring Windows VM service...
2026-02-15 16:42:18 [info] [VM:start] Windows VM service configured
2026-02-15 16:42:27 [info] [VM] Network status: NOT_CONNECTED
2026-02-15 16:42:27 [info] [VM:network] Not connected, will show error in 30000ms if not resolved
2026-02-15 16:42:28 [info] [VM:steps] sdk_install started
2026-02-15 16:42:28 [info] [VM] Network status: CONNECTED
2026-02-15 16:42:30 [info] [VM:steps] sdk_install completed (2351ms)
2026-02-15 16:42:30 [info] [VM:start] Startup complete, total time: 149034ms
2026-02-15 16:42:30 [info] [Keepalive] Starting (interval=2000ms)
2026-02-15 16:42:33 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-15 16:42:36 [info] [Spawn:vm] OAuth token approved with MITM proxy
2026-02-15 16:42:37 [info] [Spawn:vm] Spawn succeeded in 1189ms
2026-02-15 16:42:56 [info] [VM] API reachability: UNREACHABLE
2026-02-15 16:42:56 [warn] [VM:network] API is unreachable
</code></pre>
<p>The VM boots, connects, installs SDK, spawns a process with MITM proxy, but the proxy cannot reach api.anthropic.com.</p>
<h2>Network Adapter Configuration</h2>
<p>Active adapters during testing:</p>
<ul>
<li>Intel Wi-Fi 7 BE201 320MHz (Wi-Fi) — Up, manual DNS 8.8.8.8/8.8.4.4, encrypted</li>
<li>vEthernet (cowork-vm-nat) — Up, Hyper-V Virtual Ethernet Adapter</li>
<li>vEthernet (Default Switch) — Up, Hyper-V Virtual Ethernet Adapter #2</li>
</ul>
<p>Disabled during testing:</p>
<ul>
<li>ExpressVPN TUN Driver</li>
<li>ExpressVPN TAP Adapter (was already disabled)</li>
<li>OpenVPN Data Channel Offload for ExpressVPN (was already disabled)</li>
<li>Bluetooth Device (Personal Area Network)</li>
</ul>
<p>Hidden phantom adapters (cannot be disabled):</p>
<ul>
<li>Wi-Fi 3 — Disconnected, Intel Wi-Fi 7 BE201 320MHz</li>
<li>Wi-Fi 5 — Disconnected, Intel Wi-Fi 7 BE201 320MHz (Hidden)</li>
</ul>
<h2>Expected Behaviour</h2>
<p>Cowork VM should inherit the host's DNS configuration (8.8.8.8) or use its internal resolver (100.64.100.1) and successfully reach api.anthropic.com. The HNS NAT network should create a corresponding WinNAT rule to route VM traffic to the internet.</p>
<h2>Related Issues</h2>
<ul>
<li>#24918 — Cannot connect to Claude API from workspace (Windows 11 Home)</li>
<li>#24945 — VM boots but API unreachable (Windows 11)</li>
<li>#24962 — Wrong DNS config, missing sessiondata.vhdx, no NAT</li>
<li>#25024 — CSP blocks a-api.anthropic.com</li>
<li>#25088 — VM gets wrong DNS server</li>
<li>#25144 — VM uses DNS from disconnected adapter</li>
<li>#25241 — Windows 11 Home, API unreachable</li>
</ul></body></html><!--EndFragment-->
</body>
</html>
Thank you - Claude itself convinced me Claude Cowork was fundamentally broken after a day of troubleshooting and yep turns out Cowork was just grabbing a dormant Ethernet adapter address this whole time and trying to resolve the API there. I mean it's a pretty massive bug for home users who are surely 90% on WiFi while still having an ethernet adapter but ... yeah.
Same issue here. Windows 11 Home, latest Claude Desktop, Cowork fails with "Can't reach the Claude API from Claude's workspace." Regular Chat works fine. No VPN running. Virtual Machine Platform and Windows Hypervisor Platform both enabled. Hyper-V not available on Home edition.
my windows 11 pro is now working with claude cowork.
Environment:
Windows 11 (Build 26100)
Claude Desktop v1.1.3189 (Store install)
12th Gen Intel i3-12100, 16GB RAM
Hyper-V enabled, CoworkVMService running
Issue: "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace." Log shows API Error: Unable to connect to API (ECONNRESET) after ~262 seconds.
What makes this case different — all host-side networking is correct:
Get-NetNat → CoworkVmNat active on 172.16.0.0/24 ✅
IP Forwarding on vEthernet (cowork-vm-nat) → Enabled ✅
Firewall → Claude allowed inbound/outbound ✅
VM reachable from host → ping 172.16.0.2 succeeds ✅
Host reaches API → Test-NetConnection api.anthropic.com -Port 443 succeeds ✅
DNS on host adapter → manually set to 8.8.8.8/8.8.4.4 (was originally empty {} on IPv4) ✅
Note: The cowork adapter originally had no IPv4 DNS servers configured (ServerAddresses: {}). Manually setting DNS did not resolve the issue — VM still fails with ECONNRESET. This suggests the bug is inside the VM's internal network configuration, not host-side setup.
had the same issue but seems to have been due to Cloudflares warp service i had installed, turning it off and it works.
update. I have not done anythong different, but the error has changed to include:
API Error: Unable to connect to API (ECONNRESET)
Investigations seem to point out that Windows Pro can be configured to work. Windows Home might be a dead end, unless there is specific advice for setting that up.
Resolved on Windows 11 Home using the DNS fix from @Inrego and @gfsaaser24.
Environment:
Root cause: Cowork VM was inheriting DNS (150.208.1.3) from a dormant Ethernet adapter instead of the active WiFi connection.
Fix:
Cowork connected successfully after this. Confirmed working on Windows 11 Home — so Home users are not necessarily a dead end, the DNS fix just needs to work for their specific adapter configuration.
Same issue — Windows 11 Home 25H2, Build 26200.7840
Environment
Hyper-V Setup
Hyper-V enabled on Windows 11 Home via DISM workaround script (Home edition lacks native Hyper-V support).
Symptoms
Two alternating errors in Cowork:
Regular Chat mode works perfectly. Only Cowork is affected.
Diagnostics
All required services are running:
VM worker process is active:
HNS network exists with correct config:
Default route is healthy:
Root Cause Confirmed
Get-NetNatreturns empty — no WinNAT rule exists. The HNS network has an internalNatName(NAT805A27C8-73FA-47A1-8866-672E186B21A0) withNATState: 2, but this internal NAT is not routing VM traffic to the internet.Attempting
New-NetNatfails with "duplicate name exists on the network" (Windows System Error 52) because HNS has already claimed the 172.16.0.0/24 subnet internally, even though no functional WinNAT rule exists.Workarounds Attempted (all failed)
``
powershell
`Set-NetIPInterface -InterfaceAlias "vEthernet (cowork-vm-nat)" -Forwarding Enabled
Forwarding confirmed as
``
powershell
`Get-HnsNetwork | Where-Object {$_.Name -eq "cowork-vm-nat"} | Remove-HnsNetwork
New-NetNat -Name "CoworkNAT" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
created successfully (Active: True`), but Claude Desktop recreated the HNS network its own way on startup, and the error changed to "VM service not running".Expected Fix
The app should create both the HNS network and a corresponding WinNAT rule (
New-NetNat), and enable IP forwarding on thevEthernet (cowork-vm-nat)virtual adapter during startup. Currently the HNS network is created without WinNAT backing, so the VM can reach the host but has no route to the internet.Had exactly the SAME issue on my Windows 11 Home.
Restarting the app didn't help at all.
Then i used these powershell commands and saw that cowork VM was bound to the WRONG network adapter.
I have an Ethernet adapter manually configured to 192.168.2.254 - even though there was no cable in it...
My internet adapter was a different one - WiFi USB adapter running on network 192.168.50.X ...
So the claude VM bound to the ethernet adapter that was unplugged yet had manually set IP adresses...
I disabled that ethernet adapter, turned off Claude on Windows, started Claude again...
Then checked the powershell command again - now the cowork VM was correctly attached to 192.168.50.X - the network with the actualy internet connection...
It's running OK now...
Today, I started my Claude subscription. But I find that Claude Cowork doesn't work with Windows11 home. This issue was not informed me before I started the subscription.
I hope this issue is solved as soon as possible.
I am having the same issue with Cowork failing to connect to the Claude API on Windows 11 Home. Details as follows:
Environment
Behaviour
Cowork VM downloads, boots, and reaches CONNECTED status, but API reachability consistently fails PROBABLY_UNREACHABLE → UNREACHABLE on every attempt. Regular Chat works fine.
Log pattern (repeats every attempt):
Four separate attempts today (12:50, 13:35, 14:20, 14:34), same result each time. Full log attached.
Note: Upgrading to Windows 11 Pro is not a viable workaround based on other reports confirming the issue persists on Pro as well.
cowork_vm_node.log
Revisited my setup and successfully addressed the issue. Yes, I know that Warp and VPNs have be mentioned earlier.
Getting Cowork Running - Detailed Summary
Initial Problem: Trying to get Cowork (Claude Desktop's AI agent feature) running on Windows 11 Home. Cowork seems to require running a Hyper-V virtual machine with proper network connectivity.
Environment:
• Windows 11 Home PC
• CloudflareWARP installed and running
• Network: AT&T gateway → Linksys router → PC
• Home network on xxx.xxx.x.x subnet
Diagnostic Steps:
Get-HnsEndpoint | Select Name, DNSServerList
Result: Confirmed Cowork VM endpointcowork-vm-eth0had DNS servers xxx.x.x.x and xxx.x.x.x (localhost-range resolvers inside the VM - these are normal)Get-DnsClientServerAddress
Result: Found Interface Index 9 had problematic DNS, but more importantly discovered CloudflareWARP was activeGet-NetAdapter | Select ifIndex, Name, Status, InterfaceDescription
Key Results:• Interface 13 (Ethernet) - Active physical connection
• Interface 15 (CloudflareWARP) - Active VPN tunnel
• Interface 46 (vEthernet cowork-vm-nat) - Cowork's Hyper-V virtual adapter
Get-DnsClientServerAddress -InterfaceIndex 13,15,46 | Format-Table
Results:• CloudflareWARP (Interface 15): DNS xxx.x.x.x, xxx.x.x.x
• Ethernet (Interface 13): DNS xxx.x.x.x, xxx.x.x.x
• Cowork adapter (Interface 46): No IPv4 DNS configured
Key Finding: CloudflareWARP had taken over DNS resolution on the host machine, using the same localhost-range resolvers (xxx.x.x.x/xxx.x.x.x) as the Cowork VM.
Root Cause Identified:
CloudflareWARP and Cowork are both network virtualization solutions that:
• Create virtual network adapters
• Manage DNS resolution at a low level
• Route/tunnel network traffic
Having both active simultaneously created a conflict - they were stepping on each other trying to control network traffic and DNS.
Solution:
Stop-Service -Name "CloudflareWARP" -Force
Or exit CloudflareWARP from system trayRestart-Service -Name "CoworkVMService" -Verbose
Result: ✅ Cowork started working immediately
Key Takeaway: CloudflareWARP and Cowork cannot run simultaneously. When using Cowork, CloudflareWARP must be disabled. The network virtualization and DNS management from both tools conflict at a fundamental level.
Subsequent DNS Security Configuration (after Cowork was working):
Since CloudflareWARP provided DNS security/privacy but couldn't run with Cowork, we needed an alternative approach:
This provided DNS security without the WARP VPN conflict with Cowork. For me.
On Wed, Feb 18, 2026, at 1:08 PM, Kii-910 wrote:
`
Hey folks, thanks for all the debugging trails here. In the next version of Claude Desktop (hopefully going out tomorrow) we'll be switching the Cowork networking from NAT to ICS (the same virtual network mode that WSL uses), it should be much more resilient and won't have the DNS issues that a bunch of y'all found
my claude cowork on windows 11 PRO cycles through 5 different types of errors. After Fixing one issue, one of the other 4 shows up ..any advice would be gratetly appreciated ...
1.HcnCreateEndpoint 0x800706bf
2.Can't reach Claude API from workspace
4 The specified file could not be encrypted:EFS re-encrypting VHDX on rebuild
Same issue.
Windows information:
When I connect my express vpn, it works. when vpn disconnected, it doesnt work.
Hi, we have the same problem.
Failed to start Claude's workspace
Can't reach the Claude API from Claude's workspace.
Restarting Claude or reconnecting to your network sometimes resolves this.
Windows 11 Pro
Subscription: PRO Plan
Tests:
Nothing works.
There is an offical response of Claude? Some workaround to run at windows?
Did you try the workaround i posted in here, that dozens reported is working for them?
Surprisingly, after spending countless hours trying to make it work on my windows 11 PRO, someone suggested
reinstalling Claude desktop/ cowork
turn on VPN ( I have express VPN)
then try co work
for whatever reason, Claude cowork on windows is working as long as my vpn stays on, albeit slowly
it is not ideal only temporary until anthropic provides a better fix
thanks to whomever suggested this workaround
Totally accidental discovery, counter intuitive..
Surprisingly this fixed the issue on my windows machine as well. VPN must be enabled for claude workspace to run for me
Cowork has now launched with today's update.
However, when trying to connect with Gmail and Google Drive, it shows they are connected, but cowork can't see it.
Windows 11 Pro (I upgraded from home).
1.1.3647was shipped with a fix for this issue, we switched from NAT to ICS and in theory should play a lot nicer with various networking setups like VPNs, custom adapters, DNS, etc.If you have issues that aren't related to core Cowork networking (The specific "Cannot connect to Claude API" error) then this isn't the right issue for you 😅 Gonna close this one out as metrics show we've basically stamped this one out. Any other issues, please raise new ones or for a resurgence in this one please comment below
---
---
Issue persists for me on version 1.1.3770
FWIW - disabling Cloudflare VPN does now resolve the Cowork connection issue. But that's not a workable solution for me.
1.1.3770 works for me. Was slow to load workspace, but I don't need expressVPN running anymore.
I'm on version 1.1.3830 but still have this problem.
Tried:
I'd be happy to share logs or anything else with Anthropic folks.
<img width="1478" height="275" alt="Image" src="https://github.com/user-attachments/assets/53f48fb8-923a-4448-a6d8-badf5a8fe74a" />
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>[BUG] Cowork Windows - "Can't reach the Claude API from Claude's workspace" on Windows 11 Home (Surface Laptop 4)</h1>
<h2>Preflight Checklist</h2>
<ul>
<li>[x] I have searched existing issues and this hasn't been reported yet</li>
<li>[x] This is a single bug report (please file separate reports for different bugs)</li>
<li>[x] I am using the latest version of Claude Code</li>
</ul>
<h2>What's Wrong?</h2>
<p>Cowork consistently fails with "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace." Regular Chat mode works perfectly. Only Cowork is affected. This has never worked on this system since Cowork launched on Windows (Feb 10, 2026).</p>
<h2>Environment</h2>
Property | Value
-- | --
OS | Windows 11 Home 25H2 (Build 26200.7840)
Device | Microsoft Surface Laptop 4
Processor | AMD Ryzen 7 Microsoft Surface (R) Edition (2.00 GHz), x64
RAM | 16.0 GB (15.5 GB usable)
System type | 64-bit operating system, x64-based processor
Claude Desktop | Latest version (downloaded Feb 2026)
Subscription | Paid plan
Hyper-V | Not available (Windows 11 Home edition)
Windows Features | Virtual Machine Platform, Windows Hypervisor Platform
VPN | None
Antivirus | Default Windows Defender
Network | (typically Ethernet, Wi-Fi available)
<h2>Network Adapters Present</h2>
<ul>
<li>Wi-Fi: Intel(R) Wi-Fi 6 AX200 160MHz (connected during testing)</li>
<li>Ethernet: Surface Ethernet Adapter (disabled during testing)</li>
<li>Bluetooth Network Connection (disabled during testing)</li>
<li>vEthernet (cowork-vm-vnet): Hyper-V Virtual Ethernet Adapter (enabled)</li>
</ul>
<h2>Steps to Reproduce</h2>
<ol>
<li>Install Claude Desktop (latest version) on Windows 11 Home</li>
<li>Open Claude Desktop, click "Cowork" tab</li>
<li>Workspace attempts to provision</li>
<li>Fails with "Can't reach the Claude API from Claude's workspace"</li>
</ol>
<h2>Expected Behavior</h2>
<p>Cowork workspace should start successfully and connect to the Claude API, the same way regular Chat mode works without issues.</p>
<h2>Actual Behavior</h2>
<p>Error displayed: "Failed to start Claude's workspace — Can't reach the Claude API from Claude's workspace. Restarting Claude or reconnecting to your network sometimes resolves this."</p>
<h2>Troubleshooting Attempted (all failed)</h2>
<ol>
<li><strong>Uninstall and reinstall Claude Desktop</strong> — same error after fresh install</li>
<li><strong>Full restart of PC</strong> — no change</li>
<li><strong>Disabled unused network adapters</strong> (Bluetooth, Ethernet) leaving only Wi-Fi and Hyper-V adapters enabled — no change</li>
<li><strong>Deleted VM folders</strong> at <code>%APPDATA%\Claude\</code> (vm_bundles and claude-code-vm) to force clean rebuild — workspace re-provisioned but same API unreachable error</li>
<li><strong>Verified services running</strong> via PowerShell:
<ul>
<li><code>Get-Service hns</code> — Running (Host Network Service)</li>
<li><code>Get-Service vmcompute</code> — Had to manually start via <code>Start-Service vmcompute</code> (was Stopped after reboot), confirmed Running before launching Claude</li>
</ul>
</li>
<li><strong>Rebooted and retried</strong> with clean VM folders + services confirmed running + only Wi-Fi active — same error</li>
<li><strong>Ran Claude as Administrator</strong> — no change</li>
<li><strong>Flushed DNS</strong> — no change</li>
</ol>
<h2>Notes</h2>
<ul>
<li>This appears to be the same root cause as #24918, #25155, #24945, #25308, and #27010</li>
<li>Windows 11 Home does NOT have native Hyper-V, only Virtual Machine Platform and Windows Hypervisor Platform</li>
<li>Host machine can reach the internet and api.anthropic.com without issues (Chat mode works fine)</li>
<li>The VM appears to boot and connect, but cannot route to the API</li>
<li>It is unclear whether Windows 11 Home is officially supported for Cowork. If it is not, the download page should state this clearly rather than offering Cowork to all Windows users.</li>
</ul>
<h2>Request</h2>
<p>Please clarify minimum Windows edition requirements for Cowork (Home vs Pro vs Enterprise) and fix the VM networking/NAT routing so it works on Windows 11 Home, or provide a clear unsupported message if Home edition will not be supported.</p></body></html><!--EndFragment-->
</body>
</html>
I'm experiencing the same issue on Windows 11 Home.
Environment:
Windows 11 Home 25H2 (Build 26200.7840)
Intel64 Family 6 Model 165 (~2208 MHz)
64GB RAM
MSI GS66 Stealth 10UG
Claude Desktop latest version (reinstalled)
What I've done:
BIOS: Intel Virtualization Technology = Enabled, VT-d = Enabled
Windows Features: Virtual Machine Platform ✅, Windows Hypervisor Platform ✅, Linux Subsystem for Windows ✅
Installed Hyper-V on Windows Home via DISM package installation script ✅
bcdedit /set hypervisorlaunchtype auto ✅
WSL2 with Ubuntu installed (version 2.6.3) ✅
systeminfo confirms: "A hypervisor has been detected"
Reinstalled Claude Desktop — no change
Log output (cowork_vm_node.log):
yukonSilver not supported (status=unsupported), checking for stale bundle...
[startVM] VM not supported (win32/x64), skipping
The app marks the platform as "unsupported" and skips VM startup entirely, even though all virtualization components are confirmed working. Regular Chat mode works fine — only Cowork is affected.
Would appreciate clarification on whether Windows 11 Home will be supported, or if Pro/Enterprise is required.
<img width="823" height="146" alt="Image" src="https://github.com/user-attachments/assets/b06944b6-1b57-4348-898d-5d06af90ff71" />
[BUG] Cowork — "Virtualization is not enabled" on Windows 11 Home 25H2 (Build 26200)
Environment
What's Wrong?
Cowork tab shows "Virtualization is not enabled — Claude's workspace requires hardware virtualization (Hyper-V)" and refuses to start. Enabling Virtual Machine Platform via PowerShell does not resolve the issue. Chat mode works perfectly.
Steps to Reproduce
``
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All
→ Returns
Note:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -Allreturns "功能名稱未知" — Hyper-V is not available on Windows Home edition.Expected Behavior
Cowork should either:
Additional Context
Related to #24918. MSIX installs correctly to the right user account (verified via
Get-AppxPackage -AllUsers). The root issue is Cowork's hard dependency on Hyper-V, which is not available on Windows 11 Home edition.Update: After auto-updating to 1.1.3918.0 today (Feb 21, 2026), the issue persists on this version as well.
Confirming this bug — Windows 11 Home, Lenovo IdeaPad Flex 5
Same issue here. My setup:
Exact error sequence — triggered by switching models from Sonnet 4.6 to Opus 4.6 during an active Cowork task:
Error 1:
Error 2:
Error 3 (after full system reboot):
---
Core issue: This is a product responsibility, not a user responsibility
The fundamental problem is not that users need better guidance or workarounds —
it is that Anthropic shipped a product with system requirements that exclude a
significant portion of their target audience without any prior notice.
Windows 11 Home is the most widely used system among freelancers,
consultants, and knowledge workers — precisely the people Cowork is designed for.
Importantly: this issue is also reported by Windows 11 Pro users with Hyper-V
fully enabled (see #27316, #25136, #25876). This confirms that the root cause
is not simply a missing Windows edition feature — it is a fundamental
architectural instability in Cowork's VM implementation on Windows.
The ask is not "warn users better." The ask is: lower the system requirements
and fix the underlying architecture.
Cowork should work on Windows 11 Home/ Pro out of the box. If the current VM
architecture requires Hyper-V, that architecture needs to change — not the
user's operating system. WSL2, which is available on Windows Home, would be
a viable alternative backend worth exploring.
Users should never need to enter BIOS settings, investigate their Windows
edition, or research virtualization technology just to use a standard feature
of a paid product.
---
Additional UX issues to fix:
model selector should be disabled/greyed out while a task is running.
Basic UX principle: if an action cannot be safely executed, it should not
be offered. A single model switch should never be able to crash the daemon
and require a full system restart to recover.
file system intervention.
users cannot act on
RPC error -1orsdk-daemon not connected.Hi, I'm also affected by this issue on Windows 11 Home (25H2, Build 26200.7840).
I followed every suggested step before finding this thread:
Cowork still shows: "Virtualization is not enabled. Claude's workspace requires hardware virtualization (Hyper-V)."
Hyper-V is simply not available on Windows 11 Home, and there is currently no workaround that resolves the issue. Regular Chat mode works perfectly — only Cowork is affected.
Please prioritize a fix or provide an official workaround for Windows 11 Home users. Many users are in this situation as Home is the most common edition for individual consumers.
Thank you.
edition, or research virtualization technology just to use a standard feature
of a paid product.
users cannot act on RPC error -1 or sdk-daemon not connected.
<html>
<body>
<!--StartFragment--><html><head></head><body><h2>Update: Extensive troubleshooting confirms ICS vs NAT network type is the root cause</h2>
<p>Following up on #24918 with detailed findings from two days of troubleshooting on a Surface Laptop 4 (originally Windows 11 Home, now upgraded to Pro).</p>
<h3>Environment Changes Since Original Report</h3>
Property | Before | After
-- | -- | --
OS Edition | Windows 11 Home | Windows 11 Pro (upgraded via Microsoft Store)
Hyper-V | Not available | Fully enabled via optionalfeatures GUI
vmcompute service | Had to manually start | Running on boot
hns service | Running | Running
<h3>Root Cause Identified</h3>
<p>After all troubleshooting, I ran <code>Get-HnsNetwork | Format-List Name, Type</code> and found:</p>
<pre><code>Name : CoworkNAT
Type : Internal
Name : Default Switch
Type : ICS
Name : cowork-vm-vnet
Type : ICS
</code></pre>
<p><strong>Claude Desktop creates <code>cowork-vm-vnet</code> as type ICS (Internet Connection Sharing), not NAT.</strong> This happens on every launch and workspace rebuild, overriding any manually configured NAT infrastructure.</p>
<p>The manually created NAT rule (<code>Get-NetNat</code> shows CoworkNATRule, Active: True, 172.16.0.0/24) is functional, but Claude's VM connects through the ICS network instead, which cannot route to api.anthropic.com.</p>
<p><code>New-NetNat</code> also fails when Claude's ICS networks exist, returning "You were not connected because a duplicate name exists on the network" (Windows System Error 52), confirming the ICS and NAT approaches conflict.</p>
<h3>Conclusion</h3>
<p>This is not a user configuration issue. The fix needs to happen in Claude Desktop's Windows network creation code:</p>
<ul>
<li><strong>Current behavior:</strong> Claude creates HNS networks with Type: ICS</li>
<li><strong>Expected behavior:</strong> Claude should create HNS networks with Type: NAT, backed by a proper WinNAT rule</li>
</ul>
<p>Hyper-V, VMSwitch, and NAT all work correctly when configured manually on this system. Only Claude's ICS network type prevents the VM from reaching the API.</p>
<h3>System Details</h3>
<ul>
<li>Device: Microsoft Surface Laptop 4</li>
<li>Processor: AMD Ryzen 7 Microsoft Surface (R) Edition (2.00 GHz), x64</li>
<li>RAM: 16 GB</li>
<li>OS: Windows 11 Pro 25H2 (Build 26200.7840)</li>
<li>Hyper-V: Fully enabled</li>
<li>Claude Desktop: Latest version (updated Feb 22, 2026)</li>
<li>Network: Fibre, Ethernet primary, no VPN</li>
<li>Debug logs: Submitted via error banner</li>
</ul></body></html><!--EndFragment-->
</body>
</html>
Device HP Z4 G5
Processor: Intel(R) Xeon(R) w5-2465X (3.10 GHz)
RAM: 64.0 GB
OS: Windows 11 Enterprise
Hyper V Fully Enabled
Claude Desktop Latest version
Network Ethernet No VPN
Claude finding:
Get-NetNat returns empty but New-NetNat still reports a duplicate subnet — that specific detail (invisible phantom NAT in kernel memory) is actually new information that could help them diagnose the root cause faster.
I can confirm that Cowork does work on Windows 11 Home with a VPN connection (kill-switch enabled). I was using it without any issues prior to this bug appearing.
The issue for me started when I reopened my project today — it now returns the "Cannot connect to Claude API" error and remains unresolved. No configuration changes were made between the last successful session and now.
My setup:
I'm also having this issue. I'm not on Home though. I think the issue is because I use 172.16.0.0/16 and it may be conflicting.
They have fixxed with the latest update today.
Best regards
Ing. Giulio Rizzo
Cell: (+39) 3288141675
Email: @.***
Il Mar 24 Feb 2026, 22:44 Dariel Marlow @.***> ha
scritto:
They have not fixed this at all. still an issue cannot reach the API.
Why is this considered CLOSED? It is still an open issue.
<html>
<body>
<!--StartFragment--><html><head></head><body><h2>Update #2: Three days of troubleshooting, root cause confirmed as ICS network type</h2>
<p>Following up on my previous comment. Spent a third day troubleshooting after a new Claude Desktop update was released. Additional findings below.</p>
<h3>New Claude Desktop Version (Feb 24, 2026)</h3>
<p>Updated to the latest Claude Desktop version. Cleared cache, deleted vm_bundles and claude-code-vm folders, and let the workspace rebuild from scratch.</p>
<h3>New Error: Missing sessiondata.vhdx</h3>
<p>After the update, the error changed to:</p>
<pre><code>HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80070002
"The system cannot find the file specified."
Attachment 'C:\Users\walke\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx (Lun 2)' could not be found
</code></pre>
<p>The workspace reinstall and rebuild both fail to create <code>sessiondata.vhdx</code>. The file is never downloaded or generated. All other VM files are present (rootfs.vhdx, smol-bin.vhdx, vmlinuz, initrd).</p>
<p><strong>Workaround:</strong> Manually created the missing disk:</p>
<pre><code class="language-powershell">New-VHD -Path "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx" -SizeBytes 4GB -Dynamic
$vhd = Mount-VHD -Path "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx" -Passthru
$disk = $vhd | Get-Disk
Initialize-Disk -Number $disk.Number -PartitionStyle GPT
$partition = New-Partition -DiskNumber $disk.Number -UseMaximumSize
Format-Volume -Partition $partition -FileSystem NTFS -NewFileSystemLabel "sessiondata" -Confirm:$false
Dismount-VHD -Path "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx"
</code></pre>
<p>This resolved the missing file error. The VM then progressed to the next failure.</p>
<h3>Error Progression With sessiondata.vhdx Fix</h3>
Attempt | Error
-- | --
Without sessiondata.vhdx | HRESULT 0x80070002: "The system cannot find the file specified" (sessiondata.vhdx missing)
With empty (unformatted) sessiondata.vhdx | "VM connection timeout after 60 seconds" (VM booted but couldn't connect)
With formatted (NTFS/GPT) sessiondata.vhdx | "Your computer isn't providing a network connection to Claude's workspace" (VM booted, network failed)
After removing ICS networks, leaving only our NAT network | "HcnCreateEndpoint failed: Element not found" (Claude can't use non-ICS networks)
Full clean rebuild letting Claude create everything | "Can't reach the Claude API from Claude's workspace" (back to original ICS routing failure)
<h3>Additional Findings</h3>
<p><strong>CoworkVMService doesn't auto-start.</strong> After deleting vm_bundles, the CoworkVMService exists but stays Stopped. Claude reports "VM service not running. The service failed to start." Must be manually started via <code>Start-Service CoworkVMService</code> before Claude will attempt workspace provisioning.</p>
<p><strong>Claude only uses ICS networks.</strong> Tested the following:</p>
<ol>
<li>
<p>Removed Claude's ICS networks, left only a properly configured NAT network (VMSwitch + NetIPAddress + NetNat, all active and verified). Result: "HcnCreateEndpoint failed: Element not found." Claude cannot use NAT-type networks.</p>
</li>
<li>
<p>Let Claude recreate its own networks. Result: Creates <code>cowork-vm-vnet</code> as Type: ICS every time. ICS cannot route to api.anthropic.com.</p>
</li>
<li>
<p>This is a catch-22: Claude requires its own ICS network, but ICS networks can't reach the API.</p>
</li>
</ol>
<p><strong>Network state after Claude creates its networks:</strong></p>
<pre><code>Get-HnsNetwork | Format-List Name, Type
Name : CoworkNAT <-- manually created, works, Claude ignores it
Type : Internal
Name : Default Switch
Type : ICS
Name : cowork-vm-vnet <-- Claude creates this, can't route to API
Type : ICS
</code></pre>
<pre><code>Get-NetNat
Name : CoworkNATRule
Active : True
InternalIPInterfaceAddressPrefix : 172.16.0.0/24
</code></pre>
<h3>Two Distinct Bugs Identified</h3>
<p><strong>Bug 1: sessiondata.vhdx not created during workspace provisioning.</strong> The workspace install/reinstall downloads rootfs.vhdx, smol-bin.vhdx, vmlinuz, and initrd, but never creates sessiondata.vhdx. The VM config references it at Lun 2 and fails to boot without it.</p>
<p><strong>Bug 2: ICS network type cannot route to API.</strong> Claude creates cowork-vm-vnet as HNS Type: ICS. This network type does not properly route traffic to api.anthropic.com. A manually created NAT network on the same machine with the same subnet (172.16.0.0/24) routes correctly, but Claude's code cannot use NAT-type networks. The network creation code needs to use Type: NAT instead of Type: ICS.</p>
<h3>Full Environment</h3>
<ul>
<li>Device: Microsoft Surface Laptop 4</li>
<li>Processor: AMD Ryzen 7 Microsoft Surface (R) Edition (2.00 GHz), x64</li>
<li>RAM: 16 GB</li>
<li>OS: Windows 11 Pro 25H2 (Build 26200.7840) — upgraded from Home</li>
<li>Hyper-V: Fully enabled (VMSwitch, NAT, VHD creation all functional)</li>
<li>Claude Desktop: Latest version (updated Feb 24, 2026)</li>
<li>CoworkVMService: Present, requires manual start</li>
<li>Network: Telus Optik, Ethernet primary, no VPN</li>
<li>Debug logs: Submitted multiple times via error banner</li>
</ul>
<h3>Summary</h3>
<p>The VM infrastructure on this machine is fully functional. Hyper-V creates switches, NAT rules work, VHDs mount and format correctly. The issues are entirely in Claude Desktop's Windows workspace provisioning code: it fails to create sessiondata.vhdx and hardcodes ICS network type instead of NAT.</p></body></html><!--EndFragment-->
</body>
</html>
Windows 10 Pro, ICS scope 192.168.137.1 doesn't match the VM subnet 172.17.0.0/24.
Diagnosed ICS subnet mismatch causing VM internet connectivity failureDiagnosed ICS subnet mismatch causing VM internet connectivity failureThe ICS scope address is 192.168.137.1 - that's the default Windows ICS subnet, not 172.17.0.1 which is what the cowork VM adapter is using. This means ICS is configured for a different subnet than what Cowork is using. ICS isn't actually sharing through the cowork adapter properly.
Also, the vms_pp binding failed to enable on Ethernet.
Looking at the multicast joins - the cowork-vm-vnet interface has multicast group memberships similar to Default Switch and Ethernet, which suggests it's at least partially functional at L2.
The real problem is that ICS is set up for 192.168.137.1 while the VM is on 172.17.0.0/24, so ICS isn't routing traffic for that subnet. The VM has local connectivity but can't reach the internet because ICS isn't configured to share internet access to its network - this looks like a Windows 10 ICS configuration issue that needs to be fixed on Anthropic's end.Show moreDoneFound the core problem. ICS is configured with scope 192.168.137.1 (the default Windows ICS subnet) but the Cowork VM is on 172.17.0.0/24. ICS is not sharing internet to the Cowork subnet at all — they're completely mismatched.
This is Anthropic's bug. Their Windows 10 ICS setup is failing to configure the scope correctly for the VM's subnet. The VM gets "CONNECTED" because it can talk to the host adapter, but has no internet path because ICS isn't routing for 172.17.x.x.
Update #3: SOLVED — 192.168.100.0/24 subnet workaround
After four days of troubleshooting, Cowork is now working on Windows 11 Pro (Surface Laptop 4). Sharing the full fix for others hitting this issue.
What Finally Worked
The root cause on my system was that the default 172.16.0.0/24 subnet used by Cowork is ghost-claimed by Windows internally when Hyper-V is enabled. It doesn't show up in
Get-NetNatbut still blocks NAT creation (returns "duplicate name exists on the network" error). Using an alternate subnet (192.168.100.0/24) avoids the conflict entirely.Credit to a Reddit post for this insight.
The Fix (Step by Step)
Prerequisites: Windows 11 Pro with Hyper-V enabled. If on Windows 11 Home, upgrade to Pro first ($130 CAD via Settings > System > Activation) and enable Hyper-V via
optionalfeatures.Step 1 — Shut down WSL if installed:
Step 2 — Restart your PC. Open PowerShell as Administrator before opening Claude or anything else.
Step 3 — Find the Cowork network adapter:
Note the
ifIndexvalue for thevEthernet (cowork-vm-vnet)adapter (not the CoworkNAT one if you have it).Step 4 — Assign an IP to the adapter:
Replace
YOUR_IFINDEXwith your actual ifIndex number.Step 5 — Create the NAT:
Should return
Active: True.Step 6 — Open Claude and go to the Cowork tab. It should connect.
Optional: Clean Rebuild Before Applying Fix
If you've been troubleshooting and have corrupted VM state, do a clean rebuild first:
Note on Persistence
The NAT rule is stored as
Store: Localand may not persist across reboots. If Cowork stops working after a restart, re-run Steps 4 and 5. Alternatively, create a scheduled task to run these commands at startup automatically.What Didn't Work (For Reference)
Over four days, the following were attempted and did NOT resolve the issue on their own:
Why 172.16.0.0/24 Doesn't Work
Claude creates its
cowork-vm-vnetHNS network as Type: ICS (Internet Connection Sharing) on the 172.16.0.0/24 subnet. On Windows 11 with Hyper-V enabled, this subnet is internally claimed in a ghost state.Get-NetNatreturns empty, butNew-NetNatthrows a duplicate error. The ICS network type cannot route to api.anthropic.com. Switching to 192.168.100.0/24 avoids the ghost claim and allows proper NAT routing.Environment
Underlying Bugs (Still Present in Claude Desktop)
These should be fixed in Claude Desktop so users don't need manual NAT workarounds.
@mountainmavericks great write up and suggestion. I tried following it and still get an error
Is there a way to confirm Claude's configuration to ensure it's set properly? The IP and NAT look correct to me, but I'm unsure if Claude recognizes it properly.
@dmarlow thanks for trying it out. A few things to check:
First, confirm the NAT is actually active:
You should see your NAT rule with
Active: True. If it showsActive: Falseor nothing, that's your problem.Second, check what network Claude actually created:
Look at the
Typefield. If it saysICSinstead ofNAT, that's the core issue. Claude creates an ICS (Internet Connection Sharing) network on 172.16.0.0/24, which can't route to api.anthropic.com.The key fix that worked for me was using an alternate subnet. Windows has a ghost reservation on 172.16.0.0/24 when Hyper-V/WSL2 is enabled. It won't show in Get-NetNat but silently blocks it. Here's the exact sequence:
wsl --shutdownGet-NetAdapter | Where-Object {$_.Name -like "*cowork*"}and note the ifIndexNew-NetIPAddress -InterfaceIndex <your_ifIndex> -IPAddress "192.168.100.1" -PrefixLength 24New-NetNat -Name "cowork-vm-nat" -InternalIPInterfaceAddressPrefix "192.168.100.0/24"%APPDATA%\Claude\vm_bundlesand%APPDATA%\Claude\claude-code-vmfoldersThe switch from 172.16.0.0/24 to 192.168.100.0/24 was what finally got it working after 4 days of troubleshooting. Let me know if you hit a different error and I can help narrow it down.
Get-NetNat shows active for me. The type field shows ICS for me.
Ok, so this is really strange. I was going to retry all of the steps again and now things seem to work. After wsl --shutdown and reboot. I noticed I didn't have the cowork network adapter anymore (
Get-NetAdapter | Where-Object {$_.Name -like "*cowork*"}returns nothing, whereas previously it did), so I opened Claude Desktop and went to cowork, and didn't see any errors.Here's my Claude for Windows version:
Claude 1.1.4328 (d8e391) 2026-02-25T17:04:36.000ZI'm going to poke around and see if everything works as expected.
Hey folks, we just pushed out a new update today
v1.1.4328that should fix, well, most of these networking issues.If you're still facing "Cannot connect to Claude API" please update to
v1.1.4328or higher and give it a go 🤞@MarshallOfSound I'm running
Claude 1.1.4328 (d8e391) 2026-02-25T17:04:36.000Zand still have the same issue as above@MarshallOfSound Manually running
Get-Service CoworkVMServicefixed the issue for me but not sure why it shutdown in the first place. Edit: Its back to failing now with: "RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address"on latest version tasks fails after a few back and forth messages... still a buggy mess :/
Still getting this today. V.1.1.4498
<img width="1000" height="971" alt="Image" src="https://github.com/user-attachments/assets/f6ba042a-58a2-4704-8338-27c85bb86384" />
me too.
used to work with the previous version, after I updated yesterday it stopped working again.
The issue still exists. Version 1.1.4498 (24f768)
<img width="1128" height="534" alt="Image" src="https://github.com/user-attachments/assets/0fe55620-e4ca-40af-93af-52691615b897" />
Windows 11 Home
Error: "VM service not running"
You've tried restarting, reinstalling, enabling Hyper-V via DISM, and enabling all virtualization features
I cannot get COWORK to work, and I did pay for it, "VM Machine not running" on windows home 26200
I installed the VM machine and all the services are running, but still get the error message.
Additional report — Windows 11 Home, CoworkVMService ERROR_INVALID_FUNCTION
Environment:
Error observed:
CoworkVMService starts (gets a PID, STATE: START_PENDING) then immediately crashes.
Event Viewer — System log (ID 7024):
"Le service Claude s'est arrêté avec l'erreur spécifique au service suivante : Fonction incorrecte."
(= ERROR_INVALID_FUNCTION, Win32 error 0x1)
What was tried:
Root cause (suspected):
Windows Containers API unavailable on Windows 11 Home edition.
The cowork-svc.exe calls a Windows API that simply does not exist on Home.
Request:
Please clarify minimum Windows edition requirements in the documentation,
and/or provide a workaround for Windows 11 Home users.
As a Pro plan subscriber, this is highly frustrating to see others with the same issues. Adding to my frustration, the in-app support/chat has gone cold.
Environment
Issue
Cowork fails with "VM service not running. The service failed to start." The VM never initializes. This has been ongoing since I first installed Claude Desktop.
What I've tried
Of Note
A colleague running Windows 11 Home 24H2 (Build 26100) has Cowork working perfectly. Same edition, same subscription. The only difference is my machine is on 25H2. This strongly suggests a 25H2 compatibility issue on the Anthropic side, not a user configuration problem.
I would think that Cowork should work on Windows 11 Home 25H2 since it's been the current stable release of Windows since September of last year.
Windows 11 Home 25H2, Build 26200.8037
Version 1.1.6679 (MSIX)
CoWork hat früher funktioniert, nach einem Bild-Fehler dauerhaft kaputt
WSL2 installiert, DNS geändert, IP-Forwarding aktiviert – alles ohne Erfolg
Environment:
Issue:
Cowork has never worked since first installing Claude Desktop. Always fails with "VM service not running. The service failed to start."
What I've tried:
Potential Root cause found in logs:
EXDEV: cross-device link not permitted, rename
C:\Users\[username]\AppData\Local\Temp\wvm-xxx\rootfs.vhdx->C:\Users\[username]\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdxThe MSIX sandbox remaps AppData\Roaming to
D:\WpSystem\...while the temp download lands on C:, causing the cross-device rename to fail every time. The fix would be to use a file copy instead of rename.Note: Confirming the 25H2 pattern reported by Jeedub-Q — same build, same failure.
It is now 17th March and I'm still experiencing these issues. Win11 Pro. Cowork will run for a bit, then timeout and fail to connect to the API, then it fails to start the workspace. Restarting the OS solves it temporarily. This seems to be related to the VM that Cowork uses. Would love to hear some updates from Anthropic as many of us are paying to use this broken service.
The latest version of macOS also has this problem.
Same issue on Windows 11 Pro, Build 26100.
Already tried:
Upgraded from Home to Pro
Enabled Hyper-V (State: Enabled)
Enabled VirtualMachinePlatform
bcdedit /set hypervisorlaunchtype auto
Deleted vm_bundles cache
Reinstalled the app
Still stuck on "Setting up Claude's workspace" indefinitely. Never gets past the loading screen.
<img width="2398" height="1594" alt="Image" src="https://github.com/user-attachments/assets/7489e4f5-31ad-4c78-9784-2be036ac5ebc" />
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.