[BUG] Cowork unrecoverable after CoworkVMService crash — no failure recovery configured, app never restarts service

[BUG] Cowork unrecoverable after CoworkVMService crash — no failure recovery configured, app never restarts service

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

⚠️ Disclaimer

All investigation, log analysis, and root cause diagnosis below was performed by Claude Opus 4.6 via Windows-MCP (PowerShell system access) and web search. The user has no way to independently verify the accuracy of the technical analysis. This report is provided as-is to help identify and resolve the issue.

What's Wrong?

After CoworkVMService terminates unexpectedly, Cowork becomes permanently broken until the user manually runs Start-Service CoworkVMService from an elevated PowerShell. The service has no failure recovery actions configured, and the app never attempts to restart it.

The user-facing error is the generic: "VM service not running. The service failed to start."

Root Cause (Verified via Windows Event Logs)

Three compounding issues:

1. No service recovery configuration. The CoworkVMService registry entry has empty FailureActions. When the service crashes (Event 7034), Windows takes no recovery action. The service stays stopped permanently.

1. Claude Desktop doesn't restart the service. The VM module loads successfully ([VM] Module loaded successfully) but never attempts [VM:start] Beginning startup because the service check fails. It loops on [VMCLIRunner] Ensuring VM is started indefinitely without ever calling StartService.

1. The error message is misleading. "The service failed to start" implies the app tried and failed. It never tried.

Verified Event Log Timeline

Feb 14, 21:38:05  CoworkVMService     Flood of events — VM NIC deleted, service shutting down
Feb 14, 21:38:27  SCM/7034            "The Claude service terminated unexpectedly. It has done this 1 time(s)."
Feb 14, 21:38+    (all subsequent)    Every Cowork attempt fails silently — no recovery

The service crashed during normal operation and never recovered.

Service Install Pattern (also from Event Logs)

Every app version update follows this pattern:

SCM/7045  Service installed — StartType: auto start
SCM/7040  Start type immediately changed from auto start to disabled

This occurs for every version (2685 → 2998 → 3149 → 3189). The app manages the service lifecycle dynamically — enabling and starting it on demand when Cowork is activated. But it only does this once; it never re-starts after a crash.

Registry Confirmation

HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService
  FailureActions : (empty)
  Start          : 2 (Automatic)
  ImagePath      : "...\Claude_1.1.3189.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

Log Evidence

Broken state — module loads, startup never fires

00:09:30 [info] [VM] Loading vmClient (TypeScript) module...
00:09:30 [info] [VM] Module loaded successfully
00:09:30 [info] [VMCLIRunner] Ensuring VM is started    ← loops forever
00:09:41 [info] [VMCLIRunner] Ensuring VM is started
00:09:47 [info] [VMCLIRunner] Ensuring VM is started

After manual Start-Service CoworkVMService — immediate success

00:12:29 [info] [VM:start] Beginning startup, bundlePath=...
00:12:30 [info] [VM:start] Windows VM service configured
00:12:38 [info] [VM] Network status: CONNECTED
00:12:38 [info] [VM] API reachability: REACHABLE
00:12:39 [info] [VM:start] Startup complete, total time: 10248ms

No other changes were made. Starting the service was the only fix.

Suggested Fixes

Minimum: Configure service recovery actions at install time:

sc.exe failure CoworkVMService reset=60 actions=restart/5000/restart/10000/restart/30000

Better: Have Claude Desktop call StartService when it detects the service is stopped, before giving up.

Best: Both — belt and suspenders.

Environment

• OS: Windows 11 Pro, Build 26200
• Claude Desktop: 1.1.3189 (MSIX)
• CPU: 13th Gen Intel Core i5-13600K
• RAM: 64 GB
• VM bundle hash: 0ae58222a1f34cf74c74ce47cc717a82a4eb0f25
• CCD version: 2.1.41