Fixing 'VM Service Not Running' in Claude Desktop Cowork on Windows

Claude Desktop’s Cowork mode on Windows surfaces a single error for multiple unrelated failures:

Failed to start Claude's workspace
VM service not running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists,
you can reinstall the workspace or share your debug logs to help us improve.

There are at least six different root causes behind this message. Each requires different diagnostic steps and a different fix. This post is the decision tree I wish existed when I hit it.

I re-checked all of it against Claude Desktop 1.25927.0.0 in August 2026. One command I published has a much wider blast radius now than it did then, because a sibling product started installing an executable that matches the same wildcard. If you’re working from an older copy of this guide, read the revision log first.

Start here: check the two services

From an elevated PowerShell:

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

If vmms (Hyper-V Virtual Machine Management) is not running, the problem is Hyper-V, not Cowork. Enable it in Windows Features and reboot before continuing.

Check Virtual Machine Platform in Windows Features while you’re there. It’s a separate optional feature from Hyper-V, and it’s the one the app names in its own error text: “Claude’s workspace requires Virtual Machine Platform, but the virtualization service isn’t responding.” (Read from the shipped string table in resources\ion-dist\i18n\en-US.json, Claude Desktop 1.25927.0.0.)

If vmms is running but CoworkVMService is stopped, continue to the diagnostics below.

The diagnostic log

The real information lives in:

%AppData%\Claude\logs\cowork_vm_node.log

Read the last 30 lines:

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 30

What you see in this log determines which failure mode you’re in.

Decision tree

Not in the tree? Ask me with the last lines of your log: three fields, no signup.

The next three sections cover the last four rows. Those are separate error strings rather than more causes of the one in the title, and they’re here because the log emits them from the same place and people land on this page searching for them.

Auto-reinstall

Current builds try the reinstall themselves before you get a chance to. On a startup failure the app logs [VM:start] Auto-reinstalling workspace after startup failure, writes a marker file called .auto_reinstall_attempted into the bundle directory, and relaunches. The marker is what stops it from looping, so it only makes one attempt per bundle.

Two things follow from that. If you see this line, give it one relaunch before you start deleting anything. And if a stale .auto_reinstall_attempted is sitting in vm_bundles\claudevm.bundle, the app has already spent its automatic retry, which is worth knowing before you conclude the app isn’t trying.

I read this out of the shipped app.asar for Claude Desktop 1.25927.0.0. I haven’t watched it fire, so treat the relaunch behavior as read-from-code rather than something I’ve reproduced.

Event Viewer diagnostics

If the cowork log doesn’t explain the failure, check the Windows event logs:

# System log: service crashes
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddHours(-2)} |
  Where-Object {$_.Message -like "*Claude*" -or $_.Message -like "*Cowork*"} |
  Format-List TimeCreated, Message

# DCOM permission errors
Get-WinEvent -FilterHashtable @{LogName='System'; Id=10016; StartTime=(Get-Date).AddHours(-2)} |
  Format-List TimeCreated, Message

Get-WinEvent -FilterHashtable writes “No events were found that match the specified selection criteria” when nothing matches. That’s the empty result, not a broken command.

Connection timeout after 60 seconds

The dialog for this one reads VM connection timeout after 60 seconds, and the cowork log carries the useful version a line earlier:

[VM:start] Connection timeout, last completed step: load_swift_api
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

This is not the service failing to start. The host-side work finished; the guest operating system inside the VM never called back. You can watch it happen, because the host says so while it waits:

[VM:start] Still waiting for guest connection... 20367ms elapsed, 29 polls
[VM:start] Still waiting for guest connection... 41137ms elapsed, 58 polls
[VM:start] Still waiting for guest connection... 51777ms elapsed, 73 polls
[error] [VM:start] Connection timeout, last completed step: load_swift_api

Roughly 60 seconds of polling, then it gives up [measured, this machine, 2026-02-23].

The last completed step name is the diagnostic, so read it rather than the timeout. The log tags each stage of startup with [VM:steps] <name> started and <name> completed (Nms). The names that appear on this machine are download_and_sdk_prepare, load_swift_api, sdk_install, create_network, create_vm_config, vm_boot and add_plan9_shares. Pull the sequence for the failing attempt:

Select-String "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Pattern "\[VM:steps\]" |
  Select-Object -Last 20

A run that stops with create_network as the last completed step points at the network layer. One that reaches vm_boot and then times out is a guest that started and didn’t finish booting, which is the nuke and redownload path, because a corrupt rootfs.vhdx produces exactly that.

In the instance above, several launches had stacked up: the log interleaves [startVM] VM startup already in progress, waiting... with the polls. If you see that, close Claude Desktop completely, wait the full 60 seconds, and try one clean launch before changing anything.

I’ve hit this once and it cleared on a clean relaunch, so I can’t tell you it’s always the guest. What I can tell you is which line to read first.

HCS operation failed

HCS is the Host Compute Service, the Windows component Hyper-V uses to create and run a VM. When it refuses, its error comes through verbatim and looks alarming: a wall of JSON with an HRESULT in it. Two variants show up in my log, and they mean different things.

failed to create compute system. Hyper-V wouldn’t build the VM at all.

[VM:start] VM boot failed: HCS operation failed: failed to create compute system:
HcsWaitForOperationResult failed with HRESULT 0x800707de: {"Error":-2147022882,
"ErrorMessage":"","Attribution":[{"OperationFailure":{"Detail":"Construct"}}]}

Detail: "Construct" is the phase, and the empty ErrorMessage is the tell: HCS declined without giving a reason. This is the most common variant here, 30 occurrences [measured, this machine, 2026-03-08 onward]. Treat it as a Hyper-V-side failure and start at the two services, because a vmms that isn’t running produces it.

failed to start VM. Hyper-V built the VM and then couldn’t attach a disk. This one names the file, and the fix follows directly:

'cowork-vm': Attachment 'C:\Users\...\vm_bundles\claudevm.bundle\sessiondata.vhdx (Lun 2)'
could not be found due to error: 'The system cannot find the file specified.' (0x80070002)

0x80070002 is Windows saying the file isn’t there. So a failed to start VM with 0x80070002 means a disk the VM expects is missing from the bundle, and the payload tells you which one. Mine was sessiondata.vhdx, which is what the manual reset deletes and the reinstall button preserves. If you deleted the bundle by hand and started the app before the redownload finished, this is the error you get.

Read past the JSON to the Attachment line. Everything before it is machine detail. The file path and the parenthesised error code at the end are the whole message.

Other startup errors

Two more that come out of the same [VM:start] path and aren’t the message in the title.

Both are transient rather than corrupt-state failures on this machine: 14 EBUSY and 10 VM is already running occurrences, none of which needed a redownload [measured, this machine]. Neither appears in the search queries this page gets shown for; they’re here because they were the next most common thing in my own log and they’re cheap to rule out.

What’s in the bundle directory

Several of the sections above name files without saying what they are, and the filenames turn up in searches on their own. This is the whole directory on a working install [measured, this machine, 2026-08-08, Claude Desktop 1.26832.0.0]:

rootfs.img.zst and sessiondata.img, named in the older reinstall log line above, are the compressed-cache era filenames. They don’t exist on a current install.

Get-ChildItem "$env:APPDATA\Claude\vm_bundles\claudevm.bundle" -Force |
  Select-Object Name, @{n='MB';e={[math]::Round($_.Length/1MB,1)}}

Check the network layer

Even when the service starts, the VM may have no internet access. Current builds call this out directly instead of leaving you to guess: “Your computer isn’t providing a network connection to Claude’s workspace.” If you see that string, this is your section.

Get-NetNat

If this returns nothing, the WinNAT rule wasn’t created. Add it manually:

New-NetNat -Name "cowork-vm-nat" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"

Check Get-NetNat before you re-add anything. I originally wrote that the rule doesn’t survive a reboot, and that’s no longer what I measure: re-checking on 2026-08-05, roughly 14 hours after a restart, cowork-vm-nat was still present on 172.16.0.0/24 with Active: True, and I hadn’t re-run the command. The name isn’t mine either. The literal string cowork-vm-nat sits inside cowork-svc.exe, so the service creates and names that rule itself.

What I can’t tell you from one machine is which of the two is happening, whether the rule persisted or whether the auto-start service recreated it at boot. Either way, re-adding a rule that’s already there isn’t the fix, so read the output first.

For subnet collisions with VPNs or other virtual networks on the 172.16.0.0/24 range, see Elliot Segler’s post on fixing Cowork’s network conflict.

Bundle download

If the log shows rootfs.vhdx missing or the vm_bundles directory doesn’t exist, the bundle hasn’t been downloaded yet. Reopen Claude Desktop and watch the log:

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 15

You should see:

rootfs.vhdx not found, downloading...
rootfs.vhdx.zst checksum validated
vmlinuz not found, downloading...
initrd not found, downloading...
All files ready in C:\Users\...\vm_bundles\claudevm.bundle

If the download completes but the service still shows as Stopped, jump to Race condition fix.

Check free disk space before you assume the download is broken. rootfs.vhdx is 8 GB on this machine, and current builds have a dedicated message for running out of room: “Not enough disk space to set up the workspace. Free up space and try again.” There’s also a VMDiskJanitor component that cleans up stopped sessions, so space reclaimed between attempts isn’t necessarily space you freed. Neither existed in the build I originally wrote this against.

Nuke and redownload

If you haven’t already clicked “reinstall workspace” on a current build, try that first. In March I told you not to bother. Both halves of that are below. If you got sent here by one of the Reinstall files deleted rows in the decision tree, you’ve already run it, so skip to the manual reset.

Back then the button didn’t replace the VM bundle. The cowork log said so:

[deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)

It preserved sessiondata.img and rootfs.img.zst, the two files most likely to be corrupted. That behavior is documented in #24070, where a macOS user found the same thing.

On 1.25927.0.0 the message reads differently:

[deleteVMBundle] Reinstall files deleted (sessiondata.img and compressed cache preserved)

Reading the delete path in the shipped app.asar, it now unlinks every file in the bundle manifest plus each file’s .origin marker. On Windows that manifest is rootfs.vhdx, vmlinuz, and initrd, each with a pinned checksum, so the 8 GB root filesystem is inside what gets deleted rather than preserved. What survives is your session data and the compressed download cache. The confirmation dialog says the same thing in the UI: “This will delete and re-download your workspace. Your existing session data will be preserved.”

I read that delete path rather than clicking the button, because clicking it costs an 8 GB redownload on a working install. And the compressed cache surviving means a bad cache is still the failure this section exists for, so the manual reset stays.

So: click the button, and only if that leaves you stuck do the manual version below.

The manual version is not the button. It deletes the whole bundle directory, and your session data lives in there: sessiondata.vhdx is 3.5 GB inside vm_bundles\claudevm.bundle on this machine. The button preserves that file. Remove-Item -Recurse does not. If anything in your Cowork sessions matters, copy sessiondata.vhdx somewhere else before you run this.

# 1. File > Exit in Claude Desktop, then wait 60 seconds for the VM to stop.

# 2. Kill any packaged Claude Desktop processes still running. The path filter is
#    load-bearing: see the warning below.
Get-Process -Name "claude" -ErrorAction SilentlyContinue |
  Where-Object { $_.Path -like "*\WindowsApps\Claude_*" } |
  Stop-Process -Force

# 3. Now stop the service, with Claude Desktop gone so it can't restart it.
Stop-Service CoworkVMService
Get-Service CoworkVMService | Select-Object Status   # confirm Stopped before continuing

# 4. Delete the entire vm_bundles directory
Remove-Item -Recurse -Force "$env:APPDATA\Claude\vm_bundles"
Test-Path "$env:APPDATA\Claude\vm_bundles"           # expect False

Kill Claude Desktop before stopping the service, not after. A running Claude Desktop starts CoworkVMService on sight, which is the first step of the race condition above, so stopping the service while the app is alive can just hand it straight back.

If that last Test-Path returns True, the delete partially failed, usually because a file was still locked by a running VM. Don’t reopen Claude Desktop yet: a half-deleted bundle is a state none of the log lines above describe. Work out what still has a handle on it and clear that first.

The path filter is what makes this safe, not the process name. The version of this post I published in March piped Get-Process -Name "*claude*" straight into Stop-Process -Force. Claude Code installs a Windows executable at %APPDATA%\Claude\claude-code\<version>\claude.exe, so that command now reaches sessions that have nothing to do with Cowork’s VM. On this machine it returned 41 processes: 19 packaged Claude Desktop, 22 Claude Code CLI [measured, this machine, 2026-08-05].

Narrowing the pattern to -Name "claude" does not fix that, and I want to be exact about why, because it looks like it should. Both processes are named claude, so -Name "claude" and -Name "*claude*" return the identical set. The only line standing between you and 22 dead CLI sessions is the Where-Object path filter.

One caveat on that filter. $_.Path is blank for a process you can’t open, and $null -like "*\WindowsApps\Claude_*" is False, so anything unreadable gets skipped rather than killed. That fails safe here, but it means the command can quietly do nothing.

The old *cowork* line is gone for a different reason. cowork-svc.exe is the Windows service, and force-killing it is the exact dirty shutdown described in Don’t kill Claude processes in Task Manager below. Stop-Service is the clean way, and it worked unelevated on this machine: sc.exe sdshow CoworkVMService grants stop rights to Authenticated Users.

Reopen Claude Desktop. It will download a fresh bundle. Monitor with:

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 15

Once you see All files ready, start the service manually:

Start-Service CoworkVMService
Get-Service CoworkVMService | Select-Object Status

Race condition fix

The most common failure mode after a dirty shutdown. Here’s what happens:

1. Claude Desktop launches and immediately tries to start CoworkVMService
2. The VM bundle isn’t fully downloaded or extracted yet
3. The service crashes because it can’t find the required files
4. The service enters a “terminated unexpectedly” state and won’t auto-retry

That last step is a service configuration, not a guess. sc.exe qfailure CoworkVMService returns no failure actions and a reset period of 0, so Windows has nothing registered to restart it [measured, this machine, 2026-08-05]. The app’s auto-reinstall is a separate mechanism and doesn’t change this.

This is compounded by a shutdown timing issue. Claude Desktop sends a VM stop command with a 30-second timeout. If the VM doesn’t stop in time (Failed: Error: Request timed out: stopVM in the logs), resources aren’t cleanly released. On next launch, the service crashes because Hyper-V resources from the previous session are still held.

The fix is Nuke and redownload: on a current build start with the reinstall button, fall back to deleting vm_bundles and letting Claude Desktop redownload, then Start-Service CoworkVMService by hand.

Don’t kill Claude processes in Task Manager

This is the single most important thing I learned during this session.

The service crash on restart was reproducible when Claude processes were force-killed via Task Manager after exiting Claude Desktop. The correct shutdown sequence:

1. File > Exit in Claude Desktop
2. Wait at least 60 seconds. The VM shutdown is slow.
3. cowork-svc.exe will remain running in Task Manager. This is normal. It’s the background Windows service, set to AUTO_START.
4. Only then reopen Claude Desktop

If you force-kill cowork-svc.exe or other Claude processes during shutdown, Hyper-V resources (the VM, network adapters, NAT rules) are left in a dirty state, and the service will crash on next start.

Workaround: scheduled task

If the race condition is persistent, create a delayed auto-start:

Set-Content "$env:USERPROFILE\start-cowork.ps1" 'Start-Sleep 30; Start-Service CoworkVMService'

Register-ScheduledTask -TaskName "StartCoworkVM" `
  -Action (New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-WindowStyle Hidden -File $env:USERPROFILE\start-cowork.ps1") `
  -Trigger (New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME) `
  -Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries) `
  -RunLevel Highest `
  -Description "Delayed CoworkVMService start after Claude Desktop"

This gives the bundle 30 seconds to finish downloading before the service starts.

Service configuration reference

To verify the service is configured correctly:

sc.exe qc CoworkVMService
sc.exe query CoworkVMService

Expected values:

Related GitHub issues

Status re-checked 2026-08-05 via gh issue view. Closed issues with no upstream fix are still useful references: the symptoms recur. Two of these closed as stale since I first published the table, which changes their state but not their diagnostic value.

Other Cowork rabbit holes

If you’re poking at Cowork beyond the VM service, the rest of the Cowork series covers more terrain:

• Reverse-engineering Cowork’s session format: what the JSON actually looks like on disk
• Fix: Claude Desktop freezes on startup (scheduled task bug)
• Fix: file_upload returns ‘Not Allowed’ on every origin
• Where Claude Desktop actually stores your Cowork conversations

If you’ve got something you want reviewed or built, here’s what that looks like.

Environment

Where I originally hit this, March 2026:

• OS: Windows 11 Pro
• Claude Desktop: v1.1.7714.0
• Subscription: Claude Max (individual)
• Hyper-V: Enabled, vmms service running
• CoworkVMService: AUTO_START, LocalSystem

Where I re-checked it, 2026-08-05:

• OS: Windows 11 Pro 25H2, build 26200
• Claude Desktop: 1.25927.0.0
• CoworkVMService: Running, AUTO_START, LocalSystem, binary under WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
• vmms: Running, AUTO_START

Where the sections added 2026-08-08 come from:

• Claude Desktop: 1.26832.0.0
• Source for the new error sections: this machine’s cowork_vm_node.log, 10 MB covering February to August 2026, plus the shipped string table and cowork-svc.exe

Revision log