[BUG] Claude workspace VM fails silently after service crash — app never attempts to restart the Windows service

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug: Claude workspace VM fails silently after service crash — app never attempts to restart the Windows service

Platform: Windows 11 (x64), Claude desktop app v1.7196.0.0

What happens
The Claude workspace (Cowork) fails to start with the error:

"VM service not running. The service failed to start."

Restarting Claude or rebooting the computer does not fix it. The workspace remains broken until the underlying Windows service is manually started via sc.exe start CoworkVMService.

Root cause (confirmed via logs and service inspection)
Claude's workspace depends on a Windows service called CoworkVMService (display name: "Claude"), which runs cowork-svc.exe and exposes a named pipe at \\.\pipe\cowork-vm-service.

When the VM starts up, Claude calls an internal configure() step that connects to this named pipe. Claude does not call StartService before attempting to connect. If the service is stopped, Claude retries the pipe connection for ~5 seconds, then throws "VM service not running. The service failed to start." — even though no start was ever attempted. The error message is misleading.

The service is configured with:

START_TYPE: AUTO_START — starts on boot
ERROR_CONTROL: IGNORE — if it fails during boot, Windows silently ignores it
FailureActions: (none) — no recovery configured; if it crashes mid-session, it stays stopped
This means a single crash of cowork-svc.exe leaves the service permanently stopped until either a reboot (if boot startup succeeds) or manual intervention. A reboot doesn't always fix it either, because vmcompute (Hyper-V Host Compute Service) is DEMAND_START — it isn't running during early boot when CoworkVMService tries to start. If cowork-svc.exe depends on Hyper-V being available and it isn't yet, the service crashes on boot, ERROR_CONTROL: IGNORE silences the failure, and the user is left with a broken workspace even after a full reboot.

What Should Happen?

Recommendations

1. Claude should call StartService before attempting to configure the service. If the named pipe doesn't exist, the app should detect the service is stopped and start it programmatically, rather than timing out and reporting a misleading error.
2. Add vmcompute as an explicit service dependency, or register CoworkVMService as delayed auto-start (DelayedAutostart: 1). This ensures the service launches after the Hyper-V stack is available, rather than racing against DEMAND_START dependencies during early boot.
3. Configure failure recovery actions on CoworkVMService (e.g., restart after 5 seconds on first/second failure). Currently FailureActions is empty — a single crash leaves the service permanently stopped with no retry.
4. Improve the error message and recovery UI. The current message ("VM service not running. The service failed to start.") is shown even when no start was attempted. A button to retry, or an automated recovery attempt, would significantly reduce user-facing friction.

Error Messages/Logs

Steps to Reproduce

Reproduction path

1. Let CoworkVMService stop for any reason (crash, or failed boot startup)
2. Open Claude desktop app
3. Attempt to open the workspace
4. Observe: repeated connect ENOENT \\.\pipe\cowork-vm-service errors in cowork_vm_node.log, followed by "VM service not running. The service failed to start."
5. Restarting Claude or rebooting does not recover — sc query CoworkVMService shows STATE: STOPPED

Workaround: sc.exe start CoworkVMService (no elevation required), then retry the workspace.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

v1.7196.0.0

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_