Maintenance status (2026-07-29): Actively maintained again. The 6.0.x line landed after a full audit of all three scripts, and 6.0.1 through 6.0.4 came from real user bug reports over two days. Report breakage and it gets looked at. If nothing lands within 7 days of a report, the Troubleshooting section below has manual recovery steps that do not depend on this toolkit.

Fix "VirtioFS mount failed", "HCS operation failed", and "Failed to start Claude's workspace" errors in Claude Desktop Cowork mode on Windows, without rebooting.

If you're seeing any of these errors in Claude Desktop's Cowork mode, this toolkit will fix and prevent them:

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Workspace failed to start

Setting up workspace... (stuck forever)

HCS operation failed: failed to create compute system

VM is already running

HCS operation failed: The operation failed because of a virtual disk system limitation (0x800707DE)

Failed to start Claude's workspace

VM service not running. The service failed to start.

VM boot failed: VM is already running

Request timed out: isGuestConnected

Four tools: one prevents the crash, one fixes it, one monitors health, and one stops Claude cleanly.

1. Download all files into one folder (e.g. C:\ClaudeFix\)
2. Run Prevent-ClaudeIssues.bat once (configures Windows, creates watchdog, boot-fix task, and shortcuts)
3. Use the Desktop shortcut or search "Fix Claude Desktop" in Start when Cowork breaks
4. Right-click the Start Menu entry and select Pin to taskbar for one-click access

After running the prevention script, Claude will be automatically repaired at every logon and a background health monitor will detect and auto-fix VirtioFS crashes within seconds.

About Home editions. Earlier versions of this table said Home was unsupported, on the reasoning that Cowork needs Hyper-V and Home does not have it. That was wrong on both halves.

What Cowork needs is Virtual Machine Platform, which is a separate Windows feature from the full Hyper-V role and is available on Home. Anthropic's own deployment page names that feature and no other. Reports from Home users bear it out: the machine in #80444 runs Windows 11 Home, and so does the one in #61372.

Two things are genuinely narrower on Home. New-NetNat and the NetNat WMI components are missing or unreliable there, so the WinNAT check in step 16 may not be able to report properly, and the manual NAT recovery documented by Jonas Kamsker will not run. The Hyper-V PowerShell module is also absent, though nothing in this toolkit depends on it any more, because the Cowork VM is an HCS compute system that Get-VM never returns on any edition.

Everything else in this toolkit works on Home.

Claude Desktop runs a lightweight Hyper-V VM to power Cowork mode. The VM uses VirtioFS (Plan9 protocol) to share the filesystem between host and guest. This mount frequently breaks:

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Closing and reopening Claude doesn't help; the CoworkVMService stays in a broken state. The typical "fix" before these scripts was rebooting the entire PC.

The VirtioFS connection degrades when:

• Windows enters sleep or hibernate (the VM doesn't survive the transition)
• The VM sits idle for extended periods
• Power management reduces PCI-E or USB link states mid-operation
• CoworkVMService crashes and doesn't auto-recover
• Stale VM cache files from a previous session conflict with the new boot
• Hyper-V Dynamic Memory reclaims shared memory regions from the VM
• WinNAT rules disappear (VPN reconnect, network reset), killing VM connectivity
• Antivirus filter drivers interfere with VirtioFS disk operations
• Host clock drift causes TLS and API failures inside the VM

A separate class of failure occurs before the VM even boots. The Host Compute Service (HCS, vmcompute.exe) manages Hyper-V compute systems. When it fails, Claude shows:

Failed to start Claude's workspace

The underlying HCS error (failed to create compute system: HcsWaitForOperationResult failed) can be caused by:

• Handle leaks in vmcompute.exe after many VM start/stop cycles
• The vmcompute service crashing or entering a stuck state
• Boot race conditions where services start before the kernel is ready
• Antivirus filter drivers interfering with compute system creation

A third class of failure occurs after the VM boots but the guest operating system never establishes its connection back to the host. Claude Desktop polls cowork-svc.exe via a named pipe (\\.\pipe\cowork-vm-service) every ~1 second with isGuestConnected RPC calls. If the guest never reports as connected, the UI shows "Request timed out: isGuestConnected". This can be caused by: the VM booting but vsock/networking failing to initialise, cowork-svc.exe being CPU-starved by its own Authenticode signature verification loop (each poll re-hashes the 204 MB claude.exe binary, consuming ~960ms per call), or HCS state corruption preventing guest-host communication. The service log at %APPDATA%\Claude\logs\cowork-service.log records each RPC call. See issue #31848 for the Authenticode CPU burn.

Note that on current builds this file has not been written since March. The toolkit checks its age before parsing it, so a stale copy is ignored rather than mined for answers about the last 60 seconds.

State checked against the tracker on 2026-07-29. Several of these were described here as "still open, no Anthropic response" long after they had been closed, so the state column is now something to re-verify rather than assume.

A closed issue does not mean the failure cannot recur. Most of these closed without a linked PR or any published fix detail, and the underlying architecture is unchanged, which is why the toolkit still handles them.

Open

• #27801: "Failed to start Claude's workspace", VM service not running, persists after reboot
• #29045: Claude Desktop spawns a Hyper-V VM on every launch, even for chat-only use
• #80444: fatal GPU-process crash via the in-app Browser tab, and the MSIX package left needing Repair afterwards. Step 27 writes a launcher that works around the crash half of this

Closed

• #25206: VM starts then crashes within 5 minutes, service unrecoverable
• #26554: VirtioFS mount fails with "bad address"
• #27576: mount failure after roughly an hour of use
• #28890: mount goes stale after idle
• #29587: Cowork fails after brief use
• #29848: recurring VM crashes
• #31314: cowork-svc.exe sustaining 195 MB/s of I/O from the signature polling loop
• #31520: community recovery script for VirtioFS failures, which this toolkit covers and extends
• #31703: HCS and VM service failures on v1.1.5368
• #31848: cowork-svc.exe CPU burn from Authenticode re-verification on every isGuestConnected poll
• #32172: HCS 0x800707DE construct failure after a VirtioFS mount error

One-click fix when Claude Desktop / Cowork is broken. No reboot needed.

When run manually (without -Quiet or -Mode), the script shows an interactive menu:

1. Quick Fix: Restart services + basic repair (Steps 1-5, skip cache purge)
2. Deep Fix: Full nuclear reset (all steps including cache purge)
3. Smart Fix: Try quick first, escalate to deep if needed (default)
4. Diagnostic: Health check only, no changes

After selecting a mode, a second menu lets you toggle options (Keep cache, Skip relaunch, WhatIf). A summary is shown before the final Y/N confirmation.

The menu is skipped when:

• -Mode is passed as a parameter (uses that mode directly)
• -Quiet is set (defaults to Smart mode, for automated callers)
• The host is non-interactive (defaults to Smart mode)

Step 8 first attempts to relaunch Claude with elevated privileges via the LaunchClaudeAdmin scheduled task created by Prevent (Method 0). This gives Claude a full admin token without a UAC prompt. If the task doesn't exist or fails, it falls through to three standard methods: Method A launches MSIX installs via shell:AppsFolder protocol (no duplicate taskbar icons), Method B launches traditional .exe installs directly, and Method C uses Start Menu shortcuts as a last resort. All methods respect -WhatIf and each has a $launched guard to prevent double-launch.

Step 5 terminates orphan HCS compute systems that survive service shutdown. When CoworkVMService stops, the underlying VM may remain registered in HCS, causing "VM is already running" errors on restart. The script uses hcsdiag list to find cowork compute systems and hcsdiag kill to terminate them (admin only), then checks for hung vmwp.exe worker processes and kills those. This step is non-fatal, failures don't block the rest of the fix.

There is no Hyper-V cmdlet fallback, and earlier versions of this section were wrong to describe one. Stop-VM operates at the Hyper-V management layer, and the Cowork VM is an HCS compute system that never appears to Get-VM at all, so that path could never have done anything. hcsdiag is the only tool that sees this VM.

If hcsdiag is missing or does not answer, the step now says so rather than reporting a clean result. Both outcomes previously returned "no orphan compute systems found", which meant a run whose first step reported hcsdiag unavailable would still claim a successful hcsdiag check five steps later.

Step 3 checks recent Windows Event Log entries and Claude logs for HCS error patterns (HCS operation failed, failed to create compute system, HcsWaitForOperationResult). If detected and running as admin, it stops and restarts the vmcompute service. If vmcompute fails to restart within 15 seconds, it escalates: first restarting vmms (Virtual Machine Management), then in Deep mode only, restarting HvHost (which affects all Hyper-V VMs). This step is wrapped in a try/catch so failures don't block the rest of the fix process. Without admin, HCS errors are logged but require manual elevation.

Step 9 monitors the VM boot log for definitive completion markers ("Startup complete", "[Keepalive]"), showing real-time progress through the boot stages. The log is chosen by write time at startup rather than from a fixed preference list, so a build that names its logs differently still gets read and a stale file gets reported rather than believed. It also watches cowork-service.log for isGuestConnected state where that file is fresh enough to mean anything.

The wait is not a fixed countdown. It starts at 240 seconds, 300 after a cache purge, and pushes the deadline out again every time the VM cache grows, with a hard ceiling of one hour. A fresh bundle download is slow rather than stuck, and the difference between the two is whether bytes are still arriving. No growth for one progress window is what stuck actually looks like.

There is no Hyper-V heartbeat fallback. Earlier versions of this section listed one; there is no heartbeat to read, because Get-VM does not return this VM at all.

If the prerequisite check flagged something and the service also failed to start, the wait is skipped rather than spent repeating an error. If the service is running, the wait proceeds regardless of what the check thought.

After completion, the PowerShell window is brought to the foreground and the taskbar icon flashes until you dismiss it.

Step 6, Smart Cache Purge: Instead of blindly deleting everything, the script now backs up sessiondata.vhdx and smol-bin.vhdx before purging (with VHDX header integrity validation), then restores them after the service restart. If smol-bin.vhdx can't be backed up, it attempts recovery from the MSIX package. The step also cleans Claude temp files (%TEMP%\anthropic-*, %TEMP%\claude-*) and legacy AnthropicClaude\sessions and vm-state directories. Quick mode skips this step entirely.

Smart mode escalation: If the service doesn't start after the quick fix (Steps 1-5), Smart mode automatically escalates to a full deep purge with VHDX preservation: Phase 0 cleans stale HCS state, Phase 1 backs up session VHDXs, Phase 2 nukes the VM cache, the service is restarted, and Phase 3 restores the backed-up VHDXs. This ensures session data survives even when escalation is needed.

• claude_desktop_config.json: your MCP servers and settings are safe
• config.json: app configuration is safe
• Conversations: stored server-side, not in the local VM cache
• Session transcripts under local-agent-mode-sessions: left alone unless you pass -PurgeSessions

Versions before 6.0.0 deleted session transcripts older than 7 days on every run, in every mode, while this section said conversations were never touched. That deletion is now opt-in and named.

About that 13 GB. sessiondata.vhdx and smol-bin.vhdx are backed up and restored across a purge, so your workspace state survives. rootfs.vhdx, which is about 9 GB of it, is not: rebuilding the VM image is the whole point of a deep purge, and restoring it would put back whatever was wrong with it. That 9 GB is what gets re-downloaded.

Each run writes a timestamped log to %APPDATA%\Claude\fix-logs\. The health monitor logs to %APPDATA%\Claude\watch-logs\. Recent CoworkVMService errors from the Windows Event Log are shown in the summary.

Support bundles. -Mode Diagnostic changes nothing and, at the end, writes a zip you can attach to a bug report:

.\Fix-ClaudeDesktop.ps1 -Mode Diagnostic

It collects Claude's log folder, the Service Control Manager entries for CoworkVMService, vmcompute and hns over the last seven days, and the state of the Windows features by exact name.

The event log is the part people miss. When a service refuses to start there is very little in Claude's own logs, because nothing ran to write them, and Windows is the only thing that recorded what happened.

The log folder is enumerated rather than pulled from a list of expected filenames, because those names differ between builds. Files are ranked so that Cowork, VM and renderer logs get most of the space, and the whole bundle is built to a 4 MB budget and then zipped, so it fits an attachment limit. Missing files are reported rather than skipped quietly: no VM log at all is itself the answer.

Run once. Configures Windows to keep the Cowork VM alive as long as possible.

Battery settings are not changed, so laptop users keep normal battery behaviour.

Dynamic Memory pinning (step 10): Hyper-V's Dynamic Memory feature allows Windows to balloon memory in and out of VMs based on demand. When memory is reclaimed from the Cowork VM, VirtioFS shared memory regions can become invalid, this is the direct cause of the EFAULT ("bad address") error. Disabling Dynamic Memory pins the VM's allocation so it can't be reclaimed. This requires the VM to be stopped; if it's running when you run Prevent, a flag file is written and the health monitor applies the change the next time the VM restarts.

VM worker process priority (step 11): vmwp.exe is the Hyper-V Virtual Machine Worker Process that hosts each VM on the host side. At Normal priority, it can be starved under heavy CPU or I/O load, causing the VirtioFS connection to stall or time out. Setting it to AboveNormal gives it scheduling preference. This is not persistent across reboots, so the health monitor re-applies it on every poll cycle.

HCS service recovery (step 12): The vmcompute service (Host Compute Service) manages all Hyper-V compute system operations. If it crashes, every VM creation call fails with HCS operation failed. The script configures Windows Service Control Manager to auto-restart vmcompute with escalating delays: 30 seconds after the first failure, 60 seconds after the second, 120 seconds after the third. The failure counter resets after 300 seconds of healthy operation. This is a permanent OS-level setting that survives reboots.

CoworkVMService recovery (step 13): Independent of the vmcompute recovery in Step 12, the CoworkVMService itself can crash. The script configures Windows Service Control Manager to auto-restart it with escalating delays: 10 seconds, 30 seconds, 60 seconds. This ensures the Cowork VM restarts automatically without user intervention, even if vmcompute is healthy.

HCS state cleanup (step 14): Over time, stale cowork-vm entries can accumulate in the Host Compute Service after unclean shutdowns. These orphan entries can b