[BUG] Cowork: "Failed to start Claude's workspace" — VM service not running, persists after reboot

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/26743
2. https://github.com/anthropics/claude-code/issues/24699
3. https://github.com/anthropics/claude-code/issues/25177

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Getting the same issue!

same here.. with windows 11

Same here for about 2 days; Windows 10 Pro -- all three of my computers.

What's been tried:
-full uninstall of Claude Code & desktop
-confirm virtualization set in BIOS/UEFI
-updated & validated WSL2 install
-reinstall Claude Code (no issues found with "claude doctor" command
-reinstall Claude desktop with no errors
-cleared Claude VM caches; Claude restart; full windows restart

Bottom Line: "creating claude workspace" either fails with error "Failed to Start Claude Workspace ... EBADF: bad file descriptor, rename ..." <OR> it stops at 80% and returns to main Claude Desktop screen with no errors

same issue

same

same issue. havent been able to test it since got the cowork. its really a shame

same here

same here, all ready update to Claude 1.1.4498 (24f768)

Experiencing the same issue on Windows 11 Pro (Build 26200), Intel Xeon E5-2680 v4, 192 GB RAM, Claude Desktop v1.1.4498. The VM downloads all bundle files successfully (rootfs.vhdx, vmlinuz, initrd) but silently crashes after 'All files ready' — never reaches 'Configuring Windows VM service'. All Hyper-V features/services are healthy. Tried: full reinstall, VM bundle wipe, vmcompute restart, registry cleanup, multiple reboots. Nothing works. Please prioritize a fix.

go to services.msc and start Claude service for checking if it works

Getting the same issue as well from Claude:

The key error is still:

signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

This is an MSIX packaging issue — the service can't find its own path because MSIX apps run in a virtualized filesystem and Windows services don't have access to it. This is a fundamental incompatibility between how Windows services work and how MSIX packages work.

Same issue here.

Environment:

• Windows 11 Pro 24H2 (Build 26200)
• Claude Desktop v1.1.4498.0 (MSIX)
• Lenovo ThinkPad, Intel CPU (16 cores, 40GB RAM)
• Hyper-V fully enabled, VT-x enabled in BIOS
• WSL2 running fine via HCS

Symptoms:

• Cowork shows "VM service not running. The service failed to start."
• CoworkVMService starts then immediately stops
• System event log: "Le service Claude s'est arrêté avec l'erreur spécifique au service suivante : Fonction incorrecte." (The Claude service stopped with the following service-specific error: Incorrect function.)

Key log entries from cowork_vm_node.log:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
[startVM] VM not supported (win32/x64), skipping
[Callbacks] Swift VM addon not available for callbacks

What I've tried (all failed):

• Reinstalled Claude Desktop
• Restarted PC multiple times
• Enabled Hyper-V, HypervisorPlatform, VirtualMachinePlatform
• Confirmed VT-x enabled in BIOS
• Deleted vm_bundles and claude-code-vm directories
• Manually started CoworkVMService (starts then crashes immediately)

Confirmed working:

• hcsdiag list shows WSL VM running
• Get-VMHost returns valid config
• vmcompute and vmms services running
• Hyper-V infrastructure is fully functional

The issue appears to be that Claude Desktop flags yukonSilver as "unsupported" on this configuration despite all virtualization prerequisites being met.

Same issue. Very frustrating!

Same Issue

System: Windows 11 Home, AMD Ryzen 7 7435HS, 24GB RAM, MSIX install v1.1.4498

Error from cowork-service.log:
"Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified."

Also getting EXDEV errors:
"EXDEV: cross-device link not permitted, rename Temp\rootfs.vhdx -> Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx"

Tried: clean reinstall, enabling WSL2, enabling Developer Mode,
deleting CoworkVMService from registry, enabling VirtualMachinePlatform,
removing duplicate installations. Nothing resolved it.

Same Issue. Tried the above fixes, but nothing. I really want to try cowork, and am thinking of formatting and reinstalling Windows

Found a fix for my situation :) :)
Am running Win 11 Pro.

<img width="933" height="973" alt="Image" src="https://github.com/user-attachments/assets/235a1ad2-6042-4683-8346-86c7bd08e01b" />

just started happening for me this morning, already have HyperV management tools/platform installed.

It just started happening for me this morning. I think it is because of new updates of windows security update.

Same for me wasted a whole lot of time with reinstallations and clearing appdata files for the same issue to crop up repeatedly.

UPDATE:
After a full week of complete Windows client rebuilds (one Win10, one Win11) and attempting on a brand new out-of-the box computer -- nothing works.

-virtualization and hypervisor are unquestionably working (BIOS, in O/S)
-I have exhausted the list of troubleshooting steps (clear caches, etc.)
-Claude logs remain oddly vague (which is sincerely surprising)

-bottom line:

1. client seems unable to reach/detect/work with the virtual machine(s)
2. I will wait it out (for Claude devs to figure it out) because it is clearly not related to my clients or my Claude accounts, and competitor tools (also using VMs) seem to work fine with my virtualization

not upset, a bit disappointed, does not degrade for my confidence in Claude

Additional occurrence — Win 11 Pro 25H2, Build 26200.7840, Hyper-V, Max plan

Confirming this issue on a different Windows 11 build than the original report.

Environment

| Field | Value |
|---|---|
| Claude Desktop | v1.1.4498 (24f768) |
| OS | Windows 11 Pro |
| Windows version | 25H2 |
| OS build | 26200.7840 |
| Hyper-V | Enabled (full, including sub-features) |
| Virtual Machine Platform | Enabled |
| Install method | Downloaded from claude.ai/download |
| Subscription | Max plan |
| Chat mode | Works perfectly — only Cowork is affected |

Error sequence

First error (initial attempts):

sdk-daemon not connected

After clearing cache, restarting Claude Desktop, and deleting vm_bundles:

VM service not running. The service failed to start.

Troubleshooting already attempted (all failed)

• Cleared cache via Help → Troubleshooting → Clear cache and restart
• Fully quit Claude Desktop from system tray and restarted
• Rebooted the machine
• Deleted %APPDATA%\Claude\vm_bundles and allowed full VM bundle re-download
• Full uninstall and reinstall from claude.ai/download

None of these resolved the issue. Cowork remains completely unusable.

Happy to provide debug logs if helpful.

Same boat as those above. Cowork is not Coworking.

Workaround that worked for me (Windows 11 PRO 25H2):

1. Fully close Claude Desktop (including from the system tray)
2. Navigate to %APPDATA%\Claude\
3. Delete both the vm_bundles and claude-code-vm directories
4. Restart your computer
5. After reboot, open Claude Desktop and try Cowork again

Cowork started working for me without errors after following these steps. Hope it helps others while waiting for an official fix!

@mmorzywolek I'm glad something has worked for someone. That didn't help with my cases, even briefly,

Ame here. removing vm_bundles and claude-code-vm + reboot didn't fix anything. Neither did any of the other suggestions.
Kinda bummed with Claude/Anthropic at this point.

@juniormayhe's answer helped me for solving the issue, Claude Service wasn't running on services.msc , I manually started the service with right click -> start and cowork works fine without any errors now.

@juniormayhe's answer also helped me for solving the issue. Claude Service wasn't running on services.msc , I manually started the service with right click -> start, the first day it didn't work. But the second day, both cowork and Claude code work fine without any errors now.

3\. claude-code-vm

this worked for me.

Workaround that worked for me (Windows 11 PRO 25H2): 1. Fully close Claude Desktop (including from the system tray) 2. Navigate to %APPDATA%\Claude\ 3. Delete both the vm_bundles and claude-code-vm directories 4. Restart your computer 5. After reboot, open Claude Desktop and try Cowork again Cowork started working for me without errors after following these steps. Hope it helps others while waiting for an official fix!

i tried this but unfortunately did not work for me

Replicated both the steps but no fix.

I followed the steps and it didn't work for me either (different Cowork error this time than VM machine).

So, I told Claude Code what I did (deleted files), that it didn't work, and asked whether uninstalling and reinstalling the desktop app would help.

He said it would, asked me to save a config file path (to retain my connectors and set-up info) and gave me some files to delete. I asked him to delete them himself. He did. CTR ALT DLT and ended all Claude tasks via task manager (on PC), restarted, reinstalled from https://claude.com/download?open_in_browser=1.

It worked! Cowork is operational and my settings retained (didn't have to feed him the config file path). Back in action! Not sure if any of this is replicable or I just got lucky. Hope it helps someone!

System: Windows 11 Pro 25H2, AMD Ryzen 3 3200G, 16GB RAM, Claude Desktop v1.1.4498
Symptom: CoworkVMService runs successfully but Claude Desktop never subscribes to it. Event log shows repeated "No subscribers, checking sessions for idle timeout" with running=false, configured=true. No VM is ever created (Get-VM returns empty). No HNS network is created by Claude Desktop.
Confirmed working: Hyper-V functional (manually created test VM successfully), VM bundle fully downloaded (rootfs.vhdx 9.4GB present), NAT rule manually created via New-NetNat — made no difference.

Hi! Just throwing it out here, compiled a variety of community issues and fixes / prevention techniques in to 1 "toolkit", can be found here https://github.com/JesperLive/ClaudeFix - I hope it might be useful

For anyone having issues with Cowork, check if Claude service is stopped. You can restart it from the Services panel in Windows.

If restarting the service and relaunching the executable doesn’t solve the issue, you can switch from Cowork Mode to Code Mode, depending on your workflow. For example, in Code Mode, Claude can generate and run scripts that replicate much of what Cowork does... at least as a temporary workaround.

I really hope the Anthropic engineering team implements a definitive fix soon, so these VMs become more resilient and don’t require manual intervention.

Another thing that I don't know if its related is the tokens limit. This happens in both Claude Code and Claude Desktop:
API Error: Claude's response exceeded the 64000 output token maximum. To configure this behavior, set the CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable.

When I tried to work around this output tokens issue, I attempted several approaches: prompt instructions, hard‑coded variables at the system and user level, and even changes in the Claude JSON config. None of them worked. The VM appears to have a strict output‑token limit, and once that limit is hit, the whole process collapses.

I guess a practical workaround is to structure the workflow so the model operates in small, well‑defined chunks. It worked in one of my workflows. By having a structured Skill to perform the work, breaking into targeted steps helped me prevent the crash and avoids forcing the entire process to restart from the beginning in Cowork. This approach is especially useful when performing large‑scale edits or running long, multi‑step tasks.
It’s not a perfect solution, but imo until the underlying issue is fixed, having a curated skill and chunking the work is one of the few reliable ways to keep long operations from failing in Cowork.

For anyone having issues with Cowork, check if Claude service is stopped. You can restart it from the Services panel in Windows. If restarting the service and relaunching the executable doesn’t solve the issue, you can switch from Cowork Mode to Code Mode, depending on your workflow. For example, in Code Mode, Claude can generate and run scripts that replicate much of what Cowork does... at least as a temporary workaround. I really hope the Anthropic engineering team implements a definitive fix soon, so these VMs become more resilient and don’t require manual intervention. Another thing that I don't know if its related is the tokens limit. This happens in both Claude Code and Claude Desktop: API Error: Claude's response exceeded the 64000 output token maximum. To configure this behavior, set the CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable. When I tried to work around this output tokens issue, I attempted several approaches: prompt instructions, hard‑coded variables at the system and user level, and even changes in the Claude JSON config. None of them worked. The VM appears to have a strict output‑token limit, and once that limit is hit, the whole process collapses. I guess a practical workaround is to structure the workflow so the model operates in small, well‑defined chunks. It worked in one of my workflows. By having a structured Skill to perform the work, breaking into targeted steps helped me prevent the crash and avoids forcing the entire process to restart from the beginning in Cowork. This approach is especially useful when performing large‑scale edits or running long, multi‑step tasks. It’s not a perfect solution, but imo until the underlying issue is fixed, having a curated skill and chunking the work is one of the few reliable ways to keep long operations from failing in Cowork.

thx! this worked for me!

Windows 11 Home, v1.1.6041, error is signature verification initialization failed: failed to get service executable path

I tested all the suggestions. Sometimes the issue seems to disappear after the first reinstall, but it returns after the first task on Windows 11

I did this and worked for me!!!
https://www.reddit.com/r/ClaudeAI/comments/1rfk4y8/solved_claude_cowork_failed_to_start_workspace/

I was installing Claude on drive D:. After cleaning the installation and changing to drive C:, it worked!

Environment:

OS: Windows 11 Pro
Claude Desktop: v1.1.6679.0
Subscription: Pro plan

Root Cause Identified:
After extensive debugging, confirmed that cowork-svc.exe is EFS-encrypted in the WindowsApps package:
cipher.exe /c "C:\Program Files\WindowsApps\Claude_1.1.6679.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
→ E cowork-svc.exe (Compatibility Level: Application Protected)
This causes the service to fail with:
signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.
The CoworkVMService points to the correct binary path via sc.exe qc, but cannot read it due to EFS encryption. Hyper-V is enabled and all dependent services (vmms, HvHost) are running normally.
Request: Please ship the package without EFS encryption applied to cowork-svc.exe.

Same issue on Windows 11 I can't work anymore.

The issue persists to this day (I'm under Windows 11 Familly), notwithstanding the uninstallation and reinstallation of the software carried out two weeks ago, as well as a renewed attempt made today.

Cowork can operate intermittently but too often the following error recurs :

Failed to start Claude's workspace.
VM service not running. The service failed to start..

As a matter of recommendation, it is advisable to promptly request a refund - a course of action I myself undertook two weeks ago, which proved successful.

Furthermore, it is entirely legitimate to question the conformity of the product being marketed, which manifestly presents a recurring defect incompatible with the standards reasonably expected of commercially distributed software !

Spoke too soon:

YES, I have tried everything so far recommended in this thread.

After starting a task, stopped working again. However, the error now seems to be consistent:

_EBADF: bad file descriptor, rename
'C:\Users\[username]\AppData\Local\Temp\wvm-gNivNj\rootfs.vhdx' ->
'C:\Users\[username]\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'_

Same issue on Windows 11 I can't work anymore. It seems started after I stopped running instance of Claude from Task Manager in windows 11.

bump

Divorced Claude for 3 months, decided to try it out and unfortunately not working on Windows 11 Pro VM Failed to load (I emailed the log the scary popup said to btw)

Update: Faster workaround (no reboot needed)

My previous workaround (deleting vm_bundles and claude-code-vm folders + reboot) doesn't seem to work for everyone, and rebooting every time is inconvenient anyway.

I've since switched to a simple batch script that I run whenever Cowork fails to start — it fixes the issue every time for me, instantly, without needing a reboot.

How to use:

1. Save the script below as restart_cowork.bat on your Desktop (or anywhere convenient)
2. Right-click → Run as administrator (required for net stop/net start)
3. After it finishes, open Claude Desktop and launch Cowork — it should work

@echo off
title Restart CoworkVMService
echo ================================
echo  Restarting CoworkVMService
echo ================================
echo.
echo [1/5] Stopping CoworkVMService...
net stop CoworkVMService
echo.
echo [2/5] Clearing Claude temp folder...
rmdir /S /Q "%TEMP%\claude" 2>nul
echo.
echo [3/5] Closing Claude.exe process...
taskkill /F /IM Claude.exe 2>nul
echo.
echo [4/5] Closing cowork-svc.exe process...
taskkill /F /IM cowork-svc.exe 2>nul
echo.
echo [5/5] Starting CoworkVMService...
net start CoworkVMService
echo.
echo ================================
echo  Done! You can now open Claude Desktop.
echo ================================
pause

What it does:
It stops the Cowork VM service, clears the Claude temp cache, kills any lingering Claude/Cowork processes, and restarts the service cleanly. The whole thing takes a few seconds.

Note: This is for Windows only. Make sure to run it as administrator, otherwise the service commands will fail. Tested on Windows 11 Pro 25H2.

Hopefully this saves some people time until the team ships a proper fix.

@mmorzywolek 's script/batch did not resolve on my 3 computers

Same issue here. happens every time I fully close and re-open Claude desktop.

Hi! Just throwing it out here, compiled a variety of community issues and fixes / prevention techniques in to 1 "toolkit", can be found here https://github.com/JesperLive/ClaudeFix - I hope it might be useful

Might be worth noting I have been updating this with the latest patches/findings etc.

I have had this issue since the release of Cowork. I am running Windows 10 Pro.

Have tried all the fixes in this thread and am getting the same: failed to set session disk path: session disk not found error.

Claude Cowork was working perfectly yesterday. Today I'm getting the same problem this poster has described.
UPDATE: the script from mmorzywolek above worked beautifully for me.

1. restart_cowork.bat

Amazing. This worked for me. Thank you!

Workaround that worked for me (Windows 11, Claude Desktop v1.1.8629)

After trying all the usual steps (reinstall, Hyper-V check, manual service start), what finally unblocked it was deleting the .auto_reinstall_attempted flag file:

Remove-Item "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\.auto_reinstall_attempted" -Force
Stop-Service CoworkVMService -Force

Then kill all Claude/cowork processes, reopen Claude Desktop, and go straight to Cowork.

Root cause: The .auto_reinstall_attempted flag prevents the app from retrying the full configure RPC flow. Instead it falls back to isGuestConnected which silently fails when there's no running VM, causing the "VM service not running" error even when the service itself is healthy. Deleting the flag forces a clean configure on next launch.

Took me a while on Windows. I'd suggest that since it use WSL, trying to setup WSL may help you troubleshoot the problem as the error messages may be more commonly found on the internet.

My solution was that Intel VT was not enabled in the BIOS.

Solved — root cause was Claude Desktop installed on a secondary drive (D:) while Windows also maintains a reference copy on C:.

Environment: Windows 11 Pro 24H2 (Build 26200), Claude Desktop v1.1.9493.0, Lenovo ThinkPad (Intel, 16 cores, 40GB RAM), Hyper-V fully enabled.

Key error from claude_service.log:

Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

Root cause: My default app install volume was set to D: (via Settings → Storage → "Where new content is saved"). Windows MSIX packages always keep a reference copy in C:\Program Files\WindowsApps\ even when the app is installed on another volume. The CoworkVMService was registered with the C: path, but the cowork-svc.exe signature verification couldn't resolve its own executable path with two copies present → service crash (exit code 1, "Fonction incorrecte").

Fix:

1. Uninstall Claude Desktop
2. Change default app volume to C: (Settings → System → Storage → Advanced storage settings → Where new content is saved)
3. Reinstall Claude Desktop (now installs only on C:)
4. Cowork started successfully on first try

Suggestion to Anthropic: cowork-svc.exe should handle MSIX multi-volume installations gracefully, or at minimum surface the actual error ("signature verification failed") instead of the generic "VM service not running" message.

[BUG] Cowork: vmcompute (Hyper-V Host Compute Service) fails to start — Access Denied, no actionable error

Environment

• OS: Windows 11 Pro (Build 22631.6199)
• Claude Desktop version: 1.569.0.0
• Subscription: Pro
• Hyper-V: Enabled (Microsoft-Hyper-V-All, State: Enabled)
• Hypervisor: Running (HypervisorPresent: True)
• VBS: Running (VirtualizationBasedSecurityStatus: 2)
• Credential Guard: Not active (SecurityServicesRunning: 0)
• Memory Integrity / Smart App Control: Disabled
• WSL2: Installed and functional
• Antivirus: Windows Defender only (no third-party AV)
• Physical machine (not a VM)

What's wrong

Cowork fails to start with "VM service not running. The service failed to start." every time. The root cause is that the Windows service vmcompute (Hyper-V Host Compute Service) cannot be started — it starts and immediately exits with "General Access Denied" (Event ID in System log).

From cowork_vm_node.log:
VM downloads all required files successfully (rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx), but fails at the "Configuring Windows VM service" step after ~5 seconds. One attempt got further and failed with Request timed out: startVM at the create_vm_config step.

Troubleshooting attempted (all failed):

• Restarted Claude Desktop and computer multiple times
• Reinstalled workspace via Help → Troubleshooting → Reinstall Workspace
• Verified all vmcompute dependencies are running: rpcss, wcifs, hvsocketcontrol, condrv ✅
• Reset vmcompute service security descriptor via sc.exe sdset
• Disabled and re-enabled Microsoft-Hyper-V-All via DISM
• Ran sfc /scannow — found and repaired corrupt files (Bluetooth drivers, unrelated to Hyper-V)
• Ran DISM /Online /Cleanup-Image /RestoreHealth — completed successfully
• Shut down WSL2 before attempting to start vmcompute
• Verified bcdedit: hypervisorlaunchtype = Auto
• Checked Hyper-V Compute Operational log — only shows start/stop events (1000/1002), no error events
• vmms service starts successfully after restart; vmcompute does not

Expected behavior
Cowork workspace should start successfully.

Additional notes
This appears related to the ongoing vmcompute / Cowork regression reported in issues #27801, #29428, #25206 and others. The Hyper-V stack appears healthy at the OS level but vmcompute consistently exits immediately with Access Denied. No actionable error is surfaced in any log.

✅ Working solution — App storage on secondary drive causes this

I had this exact error and finally found the fix. Sharing because I haven't seen this documented anywhere.

Two root causes in my case:

1. Signature verification failed — fixed by updating Windows (KB5086672, build 26200.8117) + activating Windows license.

2. EXDEV at ~80% — caused by Windows "Where new content is saved" setting pointing to a drive other than C:\. This creates symlinks inside the MSIX package folder pointing to another drive.

How to verify if you have the second issue:

Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" | Format-Table Name, Attributes, Target

If you see symlinks (ReparsePoint) pointing to D:\WpSystem\, F:\WpSystem\, etc. → that's the cause.

Fix:

1. Settings > System > Storage > Advanced storage settings > Where new content is saved → Change "New apps will save to" to C:\
2. Backup your config first:

New-Item -Path "$env:USERPROFILE\Desktop\Claude_Backup" -ItemType Directory -Force
Copy-Item "$env:APPDATA\Claude\claude_desktop_config.json" "$env:USERPROFILE\Desktop\Claude_Backup\" -ErrorAction SilentlyContinue

1. Clean uninstall:

Get-AppxPackage -Name "Claude" | Remove-AppxPackage
Remove-Item "$env:APPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\ProgramData\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue

1. Reboot and reinstall Claude Desktop as Administrator
2. Restore config if needed

Confirmed working by multiple users in #27897 and #32481 (closed as resolved).

📌 Full diagnostic tool (English + Spanish): https://github.com/LozadAPP/claude-cowork-windows-fix

Same issue here for weeks. I ended up documenting every Cowork error I hit and the exact fixes — compiled it at coworkfix.com if anyone wants the copy-paste commands. The sdk-daemon and VM service errors specifically have a 3-step fix that worked for me. Hope it helps."

Found a fix for my situation :) :) Am running Win 11 Pro. <img alt="Image" width="933" height="973" src="https://private-user-images.githubusercontent.com/264783340/556975776-235a1ad2-6042-4683-8346-86c7bd08e01b.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzYxNzYwOTgsIm5iZiI6MTc3NjE3NTc5OCwicGF0aCI6Ii8yNjQ3ODMzNDAvNTU2OTc1Nzc2LTIzNWExYWQyLTYwNDItNDY4My04MzQ2LTg2YzdiZDA4ZTAxYi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDE0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQxNFQxNDA5NThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT04MzA0Y2Y2YjMxMjVlYmQ1YjRmZDQxOWU2MmRkMzc3YzMxYzUxZjA5MWRhOTZjZGVkYzQyYzFlNWYyYTRlYzg5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.HUEtw9EiAXEH2voXkHDRIlSdV69m48c40da4coKrSgo">

This worked for me! - note may be called Windows Hypervisor Platform instead of hyper v

same as @hackerjaeger has

I had the exact same Cowork issues:

• “Failed to start Claude's workspace. Can’t reach the Claude API”
• “VM service not running”
• “HCS operation failed: 0x800707de”
• “Cannot create system 'cowork-vm' since Hyper‑V is not installed”
• “API Error: ECONNRESET”
• random file corruption, truncated files, incomplete writes
• Cowork sometimes starting, sometimes crashing

None of the usual fixes worked (reinstall, DNS changes, NAT rebuild, Hyper‑V toggles, firewall, admin mode, WSL optional features, VM Platform, interface metrics, manual NAT, etc.).

Root cause:
Cowork does NOT run on Hyper‑V. It runs entirely on WSL2.
If WSL2 is missing, outdated, or partially installed, the VM may start in a degraded state.
This causes:

• unstable VM lifecycle
• broken I/O
• truncated files
• ECONNRESET
• “VM service not running”
• HCS errors
• workspace that “works” but behaves unreliably

The error messages are misleading because they point to Hyper‑V, but Cowork does not use Hyper‑V at all.

The real fix (the only one that solved everything):

1. Install WSL from the Microsoft Store (important — NOT via Windows Features or DISM):

https://www.microsoft.com/store/productId/9P9TQF7MRM4R

1. Reboot Windows completely.

1. Open Claude → Cowork now starts instantly and works reliably.

Verification:
Run this in PowerShell:
wsl --version
You should see a valid WSL version (e.g., 2.x.x.x) and a recent kernel.
If this is missing, Cowork cannot run correctly.

Optional (only if API is still unreachable):
Check interface metrics:
Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Format-Table
Set your active Wi‑Fi to metric 10:
Set-NetIPInterface -InterfaceIndex X -InterfaceMetric 10

Why this works:
The Store version of WSL installs the correct kernel, VM service, HNS/NAT stack, and Windows integration.
Once WSL2 is fully installed, Cowork becomes stable: no crashes, no truncated files, no ECONNRESET, and the workspace starts every time.

Hope this helps others avoid hours of debugging.

去 services.msc 启动 Claude 服务，检查它是否能用

Thanks,it works

Solución encontrada: archivo Program en raíz de C:\

Síntoma: [SC] StartService con error 193 al intentar iniciar CoworkVMService.
El ejecutable cowork-svc.exe existe y la ruta en el registro es correcta,
pero el servicio no arranca.

Causa raíz: Un archivo llamado Program en la raíz de C:\ confunde
al parser de rutas de Windows. Al intentar ejecutar
C:\Program Files\WindowsApps\...\cowork-svc.exe, Windows interpreta
C:\Program como el ejecutable y Files\WindowsApps\... como argumentos,
generando el error 193 ("not a valid Win32 application").

Solución: Eliminar (o renombrar) el archivo Program de la raíz de C:\
y reiniciar Claude Desktop.

Entorno:

• Windows 10
• Claude Desktop v1.8555.0.0
• Usuario con perfil en D:\ (no en C:\)

go to services.msc and start Claude service for checking if it works

This worked for me! After much frustration on Windows 11 with the VM service is down banner in Cowork Projects. I had tried installing Hyper-V, downloading Ubuntu/linux VM, stopping/starting vmcompute, reinstalling Claude workspaces, restarting computer. Nothing worked until I checked if the Claude service was running, and it was not. Did a manual start of the service and I'm no longer receiving the VM Service error banner. Thank you!

Fix that worked for me (Windows)

After trying restarts and reinstalling the workspace multiple times with no success, the following steps resolved the issue:

Diagnosis:

Get-Service CoworkVMService | Format-List Name, Status, StartType
Get-Service vmms | Format-List Name, Status, StartType

vmms was running, but CoworkVMService was Stopped despite its StartType being Automatic.

Fix:
Simply starting the service manually from an elevated PowerShell resolved it:

Start-Service CoworkVMService

After that, opening Claude Desktop and navigating to the Cowork tab worked immediately (gave it ~30–60 seconds for the VM to boot).

Root cause: CoworkVMService gets stuck in a Stopped state even though it's configured to start automatically. A manual Start-Service is enough to recover without needing to reinstall the workspace or reboot.

Hope this helps someone avoid the hours of frustration!

I had the exact same Cowork issues: “Failed to start Claude's workspace. Can’t reach the Claude API” “VM service not running” “HCS operation failed: 0x800707de” “Cannot create system 'cowork-vm' since Hyper‑V is not installed” “API Error: ECONNRESET” random file corruption, truncated files, incomplete writes Cowork sometimes starting, sometimes crashing None of the usual fixes worked (reinstall, DNS changes, NAT rebuild, Hyper‑V toggles, firewall, admin mode, WSL optional features, VM Platform, interface metrics, manual NAT, etc.). Root cause: Cowork does NOT run on Hyper‑V. It runs entirely on WSL2. If WSL2 is missing, outdated, or partially installed, the VM may start in a degraded state. This causes: unstable VM lifecycle broken I/O truncated files ECONNRESET “VM service not running” HCS errors workspace that “works” but behaves unreliably The error messages are misleading because they point to Hyper‑V, but Cowork does not use Hyper‑V at all. The real fix (the only one that solved everything): 1. Install WSL from the Microsoft Store (important — NOT via Windows Features or DISM): https://www.microsoft.com/store/productId/9P9TQF7MRM4R 2. Reboot Windows completely. 3. Open Claude → Cowork now starts instantly and works reliably. Verification: Run this in PowerShell: wsl --version You should see a valid WSL version (e.g., 2.x.x.x) and a recent kernel. If this is missing, Cowork cannot run correctly. Optional (only if API is still unreachable): Check interface metrics: Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Format-Table Set your active Wi‑Fi to metric 10: Set-NetIPInterface -InterfaceIndex X -InterfaceMetric 10 Why this works: The Store version of WSL installs the correct kernel, VM service, HNS/NAT stack, and Windows integration. Once WSL2 is fully installed, Cowork becomes stable: no crashes, no truncated files, no ECONNRESET, and the workspace starts every time. Hope this helps others avoid hours of debugging.

I had the exact same Cowork issues: “Failed to start Claude's workspace. Can’t reach the Claude API” “VM service not running” “HCS operation failed: 0x800707de” “Cannot create system 'cowork-vm' since Hyper‑V is not installed” “API Error: ECONNRESET” random file corruption, truncated files, incomplete writes Cowork sometimes starting, sometimes crashing None of the usual fixes worked (reinstall, DNS changes, NAT rebuild, Hyper‑V toggles, firewall, admin mode, WSL optional features, VM Platform, interface metrics, manual NAT, etc.). Root cause: Cowork does NOT run on Hyper‑V. It runs entirely on WSL2. If WSL2 is missing, outdated, or partially installed, the VM may start in a degraded state. This causes: unstable VM lifecycle broken I/O truncated files ECONNRESET “VM service not running” HCS errors workspace that “works” but behaves unreliably The error messages are misleading because they point to Hyper‑V, but Cowork does not use Hyper‑V at all. The real fix (the only one that solved everything): 1. Install WSL from the Microsoft Store (important — NOT via Windows Features or DISM): https://www.microsoft.com/store/productId/9P9TQF7MRM4R 2. Reboot Windows completely. 3. Open Claude → Cowork now starts instantly and works reliably. Verification: Run this in PowerShell: wsl --version You should see a valid WSL version (e.g., 2.x.x.x) and a recent kernel. If this is missing, Cowork cannot run correctly. Optional (only if API is still unreachable): Check interface metrics: Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Format-Table Set your active Wi‑Fi to metric 10: Set-NetIPInterface -InterfaceIndex X -InterfaceMetric 10 Why this works: The Store version of WSL installs the correct kernel, VM service, HNS/NAT stack, and Windows integration. Once WSL2 is fully installed, Cowork becomes stable: no crashes, no truncated files, no ECONNRESET, and the workspace starts every time. Hope this helps others avoid hours of debugging.

Title: Cowork still won't start after the WSL2 fix? Re-register the app.

The WSL2-from-Store fix (here on this thread) was necessary for me, but Cowork still failed with "VM service not running," and "reinstall the workspace" just looped forever.

The real second cause: Claude Desktop is a packaged (MSIX) app, and its VM service (CoworkVMService / cowork-svc.exe) was crashing on launch because the app's package registration got corrupted. The "reinstall workspace" button only re-downloads the Linux image — it never repairs this, so it loops.

Confirm it's your problem — in PowerShell:

sc query CoworkVMService
STATE: STOPPED + WIN32_EXIT_CODE: 1067 = this is you.

Fix (keeps your data, no admin):

Fully quit Claude (tray → Quit).
PowerShell:

Get-AppxPackage Claude | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml" }
Reopen Claude. (GUI alt: Settings → Apps → Claude → Advanced options → Repair.)
After this the service showed RUNNING and the VM booted in ~15s.

Also try a new chat: if an old project thread is overloaded (mine was months long), it can act up and load slow. Opening a new chat in the project and asking it to check the date/time fixed it for me — and it's a quick way to confirm things are working: if it runs date and returns the correct time, your VM is fine. The "wrong date" itself isn't a clock bug — it just means the VM hasn't actually booted (or the old chat is echoing a stale date from its context).

TL;DR: Fix WSL2 first. If it still won't start, re-register the app with the command above instead of re-clicking "reinstall workspace." And if an old chat is acting up, start a fresh one and have it check the date/time.

Full disclosure: I worked through all of this with the help of Claude Code in VS Code — it pulled the service exit codes and logs that pinpointed the corrupt registration. Just my experience — hope this helps!

我启用vpn之后就没有出现这个问题，但是我关闭了之后就出现了。这个是不是跟网络有关系？
translate：I didn’t encounter this issue after enabling the VPN, but it popped up as soon as I turned it off. Could this be related to the network?

MEGA MEGA bug - without any semantic data. No way to solve this. Stone age bug.
Also hide your entire workspace.

<img width="1355" height="455" alt="Image" src="https://github.com/user-attachments/assets/0f3ccc9d-f14a-4a00-9329-dbb8d652d7b2" />

Fix that worked for me (Windows) After trying restarts and reinstalling the workspace multiple times with no success, the following steps resolved the issue: Diagnosis: Get-Service CoworkVMService | Format-List Name, Status, StartType Get-Service vmms | Format-List Name, Status, StartType vmms was running, but CoworkVMService was Stopped despite its StartType being Automatic. Fix: Simply starting the service manually from an elevated PowerShell resolved it: Start-Service CoworkVMService After that, opening Claude Desktop and navigating to the Cowork tab worked immediately (gave it ~30–60 seconds for the VM to boot). Root cause: CoworkVMService gets stuck in a Stopped state even though it's configured to start automatically. A manual Start-Service is enough to recover without needing to reinstall the workspace or reboot. Hope this helps someone avoid the hours of frustration!

this solution fixed it for me, thank you so much!

Aqui está dando o seguinte erro: Claude's workspace failed to start with HRESULT 0x80370102 (hypervisor not running).

Hardware virtualization (Intel VT-x or AMD-V) is disabled in this device's firmware. Enable it in BIOS/UEFI settings and restart. On devices with a firmware password or vendor management (Dell Command, HP BCU, Lenovo, vPro), this may need to be changed via that tool.