[BUG] Cowork — VM service not running on Windows 11 (fresh repro + workaround; extends closed #54891 / #61559 cluster)

Open 💬 11 comments Opened Jun 1, 2026 by aiken884

Summary

Fresh reproduction of "Failed to start Claude's workspace — VM service not running. The service failed to start." on Windows 11 (2026-06-01/02). All built-in recovery options (restart Claude, restart computer, reinstall workspace) failed. Workaround: manually enabling Virtual Machine Platform + WSL2 fixed it, but this should not require user intervention since Claude Desktop is the only installer for these features in this product.

Filing as new issue per github-actions[bot] 2026-06-01 prompt on #54891 (closed as not planned, inactive). Same symptom cluster as #61559, #39338, #36801, #38610, #49435, #52006.

Environment

  • OS: Windows 11 Pro, Build 26200.8524, DisplayVersion 25H2, x64
  • Claude Desktop: 1.9659.2.0 (MSIX, Package Claude_1.9659.2.0_x64__pzs8sxrjxfjjc)
  • WSL (post-fix, freshly installed today): 2.7.3.0 / Kernel 6.6.114.1-1 / WSLg 1.0.73 / MSRDC 1.2.6676 / Direct3D 1.611.1-81528511
  • Windows features (post-fix, verified via dism /online /get-features):
  • VirtualMachinePlatform: Enabled
  • HypervisorPlatform: Enabled
  • Microsoft-Windows-Subsystem-Linux: Enabled
  • Microsoft-Hyper-V-All: Disabled (intentionally, not required for Cowork)
  • Microsoft-Hyper-V + sub-features (Hypervisor / Tools / Services / Management): Disabled
  • bcdedit hypervisorlaunchtype: Auto
  • Notable: minimum 3 features set (Virtual Machine Platform + WSL2 + Hypervisor Platform) is sufficient for Cowork; full Hyper-V family is NOT required. This is useful information for performance-conscious users who want to minimize virtualization overhead.
  • CPU: hardware virtualization (Intel VT-x / AMD-V) enabled in BIOS
  • AV / EDR: [Aiken 補主要 security 軟體名稱、Windows Defender 預設或 3rd party]

Reproduce Steps

  1. Register a new scheduled task via mcp__scheduled-tasks__create_scheduled_task (e.g. recurring cron 0 6 * * * with prompt body)
  2. Open Claude Desktop sidebar → Scheduled section → find newly created task
  3. Click "Run now" to pre-approve tool permissions (per first-time permission approval pattern)
  4. Error banner appears immediately:

> 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.

Expected Behavior

VM workspace starts, task prompt executes, tool permission prompts displayed for Aiken to approve.

Actual Behavior

VM service fails to start. Cowork-bound tools (scheduled tasks, workspace tools, file IO via VM mount) all unavailable. Pure chat mode still works.

Already Tried (all failed in this state)

  1. Restart Claude Desktop (close → quit → reopen)
  2. Restart computer (full reboot)
  3. Click "reinstall the workspace" link in error banner

What Eventually Worked (workaround)

Enabling the following Windows features manually:

  • Virtual Machine Platform
  • Windows Subsystem for Linux
  • Windows Hypervisor Platform

Then installing WSL2 from Microsoft Store + reboot.

After this, 4 previously-registered scheduled tasks (behavior-audit-weekly-backfill-w23, behavior-audit-weekly, cascading-daily-trigger, vault-char-corruption-daily-monitor) all fired successfully via Run now without further intervention.

Root Cause Hypothesis

Claude Desktop's CoworkVMService is hard-dependent on Windows virtualization stack (Virtual Machine Platform + Hyper-V Platform components + WSL2 kernel), but the installer does not check or auto-enable these features. Users with performance-constrained machines may explicitly disable these features to save resources; Claude Desktop silently fails to start the workspace without surfacing the underlying dependency.

Impact

  • Severity: High — entire Cowork mode (scheduled tasks, sandboxed tools, workspace VM) unavailable without manual workaround
  • Discoverability: Low — error message only says "reinstall the workspace" without mentioning Windows features dependency
  • First-time user experience: Confusing — user has no signal which Windows feature is missing
  • Performance trade-off: Real — enabling Hyper-V family does have ~5% baseline CPU overhead, larger on 3D workloads; users who opted out for performance reasons get no warning that Cowork won't work

Suggested Fix Direction

  1. Pre-install check: Claude Desktop installer or first-launch wizard verifies VirtualMachinePlatform, Microsoft-Windows-Subsystem-Linux, HypervisorPlatform are enabled; offers to enable them with admin elevation prompt
  2. Better error message: Replace generic "VM service not running" with specific guidance: "Cowork requires Windows feature X / Y / Z. Click to enable (admin required) → [Enable] [Learn more]"
  3. Graceful degradation: If virtualization unavailable, disable Cowork features in UI with clear "Requires Hyper-V / Virtual Machine Platform — click to set up" hint instead of silent fail-to-start

Related Issues (closed, not resolved)

  • #54891 (this issue's predecessor, closed by bot 2026-06-01 22:51 UTC as not planned, inactive)
  • #54847 (tool dispatch stalls — related class of silent failures)
  • #61559 (Claude Desktop Cowork fails to start workspace on Windows)
  • #39338 (Cowork — VM service not running, persists after all recovery)
  • #36801 (Cowork: VM service not running — CoworkVMService exits)
  • #38610 (VM service not running, Error 193)
  • #49435 (Cowork VM service fails on Windows 11 Pro after Claude update)
  • #52006 (error 1058, cannot start CoworkVMService)
  • #25914 (maintainer-endorsed Hyper-V + HNS cleanup steps; older but still referenced)
  • #27801 / #25419 (deep WSL2 / Hyper-V networking fixes)

Logs

Happy to provide:

  • %APPDATA%\Claude\logs\cowork_vm_node.log (relevant lines from VM service start failure window)
  • Windows Event Viewer System log entries (Service Control Manager / Hyper-V / HNS / WinNAT) around the failure time

Let me know if needed.

Reproduction Confidence

This is a confirmed reproduction on my Windows 11 Pro 25H2 setup. Same symptom cluster spans multiple closed-as-not-planned issues across 2024-2026, suggesting an ongoing class of environment-dependency issues that warrants a first-class install/error UX.

View original on GitHub ↗

This issue has 11 comments on GitHub. Read the full discussion on GitHub ↗