Claude Cowork fails on Windows for five reasons: (1) the CoworkVMService stops after reboot or sleep, (2) the "yukonSilver" platform detection bug marks capable systems as unsupported, (3) Windows Home edition lacks the full Hyper-V stack Cowork needs, (4) network conflicts with VPNs or Docker on the 172.16.0.0/24 range, and (5) corrupted installs from the old Squirrel installer. Each has a different fix.
Cowork shipped on Windows on February 10, 2026, and went GA across all paying subscribers on April 9, 2026. The Claude Code GitHub repo has been collecting Windows-specific bugs since launch: cryptic "yukonSilver not supported" errors, missing Cowork tabs on fully capable machines, and a VM service that resists removal. We've tracked the major failure modes and what actually fixes each one. No fluff.
Try this first: restart CoworkVMService
Before anything else, check whether Cowork's background service is actually running. CoworkVMService ships with startup type Manual, which means it stops after reboots, Windows updates, and sleep/wake cycles. Once it stops, Cowork hangs or fails to connect even though everything else looks fine. This is the most common Cowork issue on Windows and the fastest one to fix.
Open PowerShell as Administrator and run:
sc start CoworkVMService
If that fixes Cowork until the next reboot, make it stick by switching the service to automatic startup (mind the space after =):
sc config CoworkVMService start= auto
If sc start returns "service not found," skip to the install-related sections below — your Cowork installation may be broken. Otherwise, restart Claude Desktop and check the Cowork tab.
Check your system before you debug
Anthropic ships a downloadable Cowork readiness checker linked from the "Get started with Claude Cowork" article in Anthropic's help center (separate utility, not part of Claude Desktop). Run it first — it reports whether your machine has the Hyper-V components Cowork needs. Caveat: on Windows 11 Home it can falsely report "ready" because Windows 11 internally still reports as 10.0 and the checker misidentifies the OS (GitHub #50621). If the checker says ready but Cowork won't load, run Get-Service vmms in PowerShell — if that service doesn't exist, you're on Home and Cowork won't work.
The Five Ways Cowork Breaks on Windows
The problems aren't random. They fall into five distinct patterns, and knowing which one you're hitting is half the battle.
1. The Missing Tab (yukonSilver bug)
You install Claude Desktop, open it, and the Cowork tab simply isn't there. Only "Chat" shows up. This is the "yukonSilver not supported" bug, tracked in GitHub issues #25136, #32004, and #32837. Claude's internal platform detection incorrectly marks your system as incompatible, even when all virtualization features are enabled.
2. The Infinite Setup Spinner
The Cowork tab appears, but clicking it shows "Setting up Claude's workspace" with a loading bar stuck at 80 to 90%. It never completes. Users have reported leaving it running for 12+ hours with no progress. No error message. Just spinning.
3. The API Connection Failure
The workspace starts but can't reach Claude's API. You get "Cannot connect to Claude API from workspace" or its Japanese equivalent. This was a day-one launch bug on Windows 11 Home and has resurfaced multiple times since.
4. The Network Conflict
Cowork uses a hardcoded network range (172.16.0.0/24) for its internal NAT. If your home network, corporate VPN, or another VM tool uses the same range, Cowork's VM can't reach the internet. Worse, it can break your WSL2 and Docker networking in the process.
5. The Update Regression
Auto-updates have introduced Cowork-breaking regressions more than once. The most-reported example was v1.1.5749 on March 9, 2026, which broke working installs and required a patch release to recover. Anthropic has since shipped multiple updates; if you're stuck on a known-bad version, updating to the current Claude Desktop release is usually the fix.
The Windows Home Problem That Anthropic Still Hasn't Documented
This is where it gets messy.
Claude Cowork runs inside a lightweight Hyper-V virtual machine on your Windows machine. That's how it creates its sandboxed environment for file access and code execution. The problem? Windows 11 Home doesn't include the full Hyper-V stack.
Home edition has Virtual Machine Platform and Windows Hypervisor Platform. But it's missing the vmms (Virtual Machine Management) service that Cowork's VM requires. Without it, the VM either fails silently or throws a cryptic "Plan9 mount failed: bad address" error.
At least seven separate GitHub issues have been filed by Windows Home users who spent hours troubleshooting before discovering that their Windows edition simply can't run Cowork. One user explicitly noted they "subscribed to Max specifically to use this feature" and only discovered the incompatibility after paying.
A documentation request (GitHub issue #27906) was filed in February asking Anthropic to add this information clearly. That issue is now closed and the help center's deployment article has been updated to be more explicit about edition requirements.
The quickest check is to open PowerShell and run Get-Service vmms. If the service isn't found, Cowork won't work without upgrading to Windows 11 Pro or Enterprise. Don't rely on Anthropic's readiness checker alone — GitHub #50621 documents that it falsely reports "ready" on Windows 11 Home because Windows 11 internally still reports its version as 10.0 and the checker misclassifies the OS. A handful of community reports describe partial functionality on Home, but the official position is that Cowork requires the Pro/Enterprise Hyper-V stack.
The "yukonSilver" Bug and Why Your Pro Machine Still Fails
Stay with me here, because this one is especially frustrating.
Even if you're running Windows 11 Pro with every virtualization feature enabled (Hyper-V, VMP, WHP, WSL2), you might still see the Cowork tab missing entirely. The logs will show "yukonSilver not supported (status=unsupported)" followed by the VM bundle cleanup routine running instead of the actual VM boot.
"yukonSilver" is Claude's internal codename for its VM configuration on Windows. The bug is in the platform detection logic: it incorrectly classifies fully capable x64 Windows 11 Pro systems as unsupported.
But that's not even the real problem. The installer also creates a Windows service called CoworkVMService, and this service sometimes becomes impossible to remove. Running sc.exe delete CoworkVMService as Administrator returns "Access denied." The service blocks clean reinstalls and creates a circular failure where you can't fix the problem and you can't start fresh.
The documented workaround from community debugging: manually run Add-AppxPackage as the target user to install the MSIX package correctly for your account. It's a PowerShell command that most of Cowork's target audience (non-developers) would never discover on their own.
Squirrel vs. MSIX: which installer do you have?
Anthropic switched Claude Desktop on Windows from a Squirrel .exe installer to an MSIX/Microsoft Store package around February 10-13, 2026. If you installed Claude Desktop before that, you have the Squirrel build, and the in-app "Reinstall" button can silently fail (tracked in GitHub issues #25162, #25385, #26457; error code 0x80073CFA in some logs). The fix is a manual uninstall via "Add or remove programs," followed by downloading the fresh MSIX from the official Claude download page. Note that MSIX installs also require Windows "Sideload apps" / "Trusted App Installs" to be enabled — without it, the MSIX install fails before it starts.
As one developer debugging the issue put it: "Cowork is marketed at the people least equipped to debug it when it breaks."
If you've been running into similar infrastructure headaches with AI agents and want something that works out of the box, our comparison of self-hosted vs managed OpenClaw deployments covers why some teams are moving away from local setups entirely.
The Network Bug That Breaks Docker Too
Here's what nobody tells you about Cowork's networking on Windows.
Cowork creates its own Hyper-V virtual switch and NAT network. It's separate from WSL2's networking and separate from Docker Desktop's networking. Three different tenants sharing the same hypervisor, each with their own plumbing.
The specific failure: Cowork creates an HNS (Host Network Service) network called "cowork-vm-nat" but sometimes fails to create the corresponding WinNAT rule. The HNS network exists, but there's no NAT translation. The VM boots, but it has no internet access.
And in a particularly fun bug, Cowork's virtual network has been reported to permanently break WSL2's internet connectivity until you manually find and delete the offending network configuration using PowerShell HNS diagnostic tools.
The fix, discovered by community members, involves stopping all Claude processes, killing the Cowork VM via hcsdiag, removing the broken HNS network, and recreating it on a non-conflicting subnet like 172.24.0.0/24 or 10.200.0.0/24.
This is three PowerShell commands for someone who knows what they're doing. For someone who just wanted to organize their Downloads folder with AI, it's a wall.
What Actually Fixes Each Bug (Quick Reference)
Missing Cowork Tab (yukonSilver bug)
First, confirm you're not on Windows Home. If you're on Pro or Enterprise and still don't see the tab, fully uninstall Claude Desktop, remove the leftover service, and clear residual files before reinstalling:
sc.exe stop CoworkVMService
sc.exe delete CoworkVMService
Remove-Item -Recurse "$env:APPDATA\Claude"
Remove-Item -Recurse "$env:LOCALAPPDATA\Packages\Claude_*"
Then reinstall fresh from the official Claude download page.
Infinite Setup Spinner
Two common causes here. First, the VM download itself. Look in %APPDATA%\Claude\vm_bundles\ — if the directory is empty or incomplete, your download was interrupted and a clean reinstall usually resolves it.
Second, the cross-drive storage path bug (GitHub #36642, #30584, #37754). Cowork writes rootfs.vhdx to C:\Windows\Temp first and then tries to rename it into its final location. If Windows "Where new content is saved" sends user data to a non-C: drive, that rename crosses devices and Node.js throws EXDEV: cross-device link not permitted. Symptom: the spinner hangs forever with no visible error. Fix: open Settings → System → Storage → Advanced storage settings → Where new content is saved, switch "New apps" back to the C: drive, and retry.
If the spinner persists on Windows Home, it's the Hyper-V incompatibility and there's no fix short of upgrading your edition.
API Connection Failure
Disable your VPN temporarily (fully quit, don't just disconnect). Check whether your network uses the 172.16.0.0/24 range. If Chat works but Cowork doesn't, the problem is the VM's network stack, not your internet. Update to the latest Claude Desktop — v1.1.4328 or higher specifically addressed early API connection bugs.
Network Conflict
Check whether Cowork's HNS network exists but the NAT rule doesn't:
Get-NetNat
Get-HnsNetwork | Where-Object {$_.Name -eq "cowork-vm-nat"}
If Get-NetNat is empty but the HNS query returns a result, you're in the "missing NAT rule" state. Remove the broken network and recreate it on a non-conflicting subnet like 172.24.0.0/24 or 10.200.0.0/24.
Update Regression (v1.1.5749)
If Cowork broke after the March 9 update, there's no user-side fix. Update to the latest Claude Desktop release — Anthropic has shipped multiple patches since.
If all of this sounds like a lot of infrastructure debugging for a tool that's supposed to "just work," that's because it is. This is the kind of operational friction we built BetterClaw to eliminate. Your OpenClaw agent runs on managed infrastructure: no local VMs, no Hyper-V, no NAT conflicts. $19/month, BYOK, first deploy in ~60 seconds.
Cowork vs. a managed agent: pick what matches your job
Cowork is a desktop co-pilot. It runs a local Hyper-V VM, which is why every Windows edition quirk, network conflict, and update regression becomes a potential failure point. If you need a co-pilot you sit beside, that trade-off makes sense.
If you need an always-on agent that handles tasks across messaging platforms while your computer is asleep, the architecture has to be different. Managed OpenClaw hosting runs your agent on cloud infrastructure with Slack, Discord, WhatsApp, and 15+ channels. No local VM, no Hyper-V, no PowerShell on a Tuesday night. $19/agent/month, BYOK, first deploy in ~60 seconds. Start free.
Frequently Asked Questions
Why is Claude Cowork not working on my Windows machine?
Top causes: CoworkVMService stopped after reboot or sleep, Windows Home edition missing the full Hyper-V stack, the "yukonSilver" platform detection bug, network conflicts with VPNs or Docker on 172.16.0.0/24, or a corrupted install from the old Squirrel package. Check your Windows edition, then your VM service state, then the Claude Code GitHub issues for your exact error.
How do I restart CoworkVMService on Windows?
Open PowerShell as Administrator and run sc start CoworkVMService to start it for the current session. To make it survive reboots, run sc config CoworkVMService start= auto (mind the space after =). The service ships with startup type Manual, so it stops after reboots, Windows updates, and sleep/wake cycles. This is the single most common Cowork fix on Windows.
Does Claude Cowork work on Windows 11 Home?
No, officially. Cowork requires the Hyper-V vmms service, which Home editions lack. Anthropic's readiness checker can falsely report Home as "ready" (it misidentifies the OS), so don't trust it alone — run Get-Service vmms in PowerShell. If it's missing, upgrade to Windows 11 Pro or Enterprise.
How do I fix the "yukonSilver not supported" error in Claude Cowork?
This is a platform detection bug on Claude's side, still open as of May 2026. The workaround: fully uninstall Claude Desktop, stop and delete CoworkVMService via elevated PowerShell, clear %APPDATA%\Claude and the %LOCALAPPDATA%\Packages\Claude_* folder, then reinstall fresh from the official download.
Is Claude Cowork on Windows stable enough for daily use in 2026?
Cowork went GA in April 2026, but Windows is still the rougher platform. The yukonSilver bug remains open, the CoworkVMService Manual-startup behavior catches users after every reboot, and update regressions appear periodically. Fine for desktop tasks if your system is compatible. For workloads where downtime means lost work, a managed agent is more reliable.
