[BUG] Cowork: 'VM service not running' — app should start the stopped CoworkVMService itself (unelevated Start-Service fixes it) instead of suggesting restart/reinstall

Summary

When Cowork fails with "Failed to start Claude's workspace — VM service not running. The service failed to start.", in many cases the only problem is that the CoworkVMService Windows service is in the Stopped state. A plain, unelevated Start-Service CoworkVMService from the logged-in user's session fixes it instantly.

The error banner instead tells the user to restart Claude, restart the computer, or reinstall the workspace — all far heavier than what's actually needed. Suggested fix: the app should attempt to start the service itself (via the Service Control Manager) before showing the give-up banner.

Related symptom cluster (different or unconfirmed root causes): #64592, #27801, #82649, #54891, #61559.

Environment

• OS: Windows 11 Pro, 10.0.26200 (x64)
• Claude Desktop: 1.24012.9.0 (MSIX, Claude_1.24012.9.0_x64__pzs8sxrjxfjjc)
• Virtualization features working — Cowork runs fine on this machine whenever the service is running.

Root cause (on this machine, recurring)

1. CoworkVMService (display name "Claude", WIN32_PACKAGED_PROCESS, StartType Automatic) exits at some point after logon (it appears to exit when the Claude app closes) and stays down.
2. Because it's an MSIX-packaged service, no Windows failure-recovery actions are configured — and the app apparently can't set them itself (Access is denied seen in cowork-service.log when it tries). Verified today:

SERVICE_NAME: CoworkVMService
        RESET_PERIOD (in seconds)    : 0
        REBOOT_MESSAGE               :
        COMMAND_LINE                 :

        TYPE               : 210  WIN32_PACKAGED_PROCESS
        START_TYPE         : 2   AUTO_START
        BINARY_PATH_NAME   : "C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
        SERVICE_START_NAME : LocalSystem

1. So when the service dies, nothing ever brings it back, and every subsequent workspace launch fails with the banner. %AppData%\Claude\logs\cowork_vm_node.log shows:

[VM:start] Startup failed: Error: VM service not running. The service failed to start.

Workaround that always works here (no UAC prompt)

Start-Service -Name CoworkVMService

Runs unelevated — the interactive user has start rights on the packaged service. Cowork starts normally immediately afterwards. I've papered over the recurrence locally with a logon scheduled task that starts the service if stopped, but users shouldn't need to discover this.

Suggested fix

1. In the VM startup path, when the service check fails because the service is Stopped, call StartService on CoworkVMService (the interactive user already has permission — no elevation needed), wait for Running, and retry the launch. Only show the error banner if that attempt fails.
2. Longer term: give the packaged service proper failure-recovery (restart on crash), or have the app supervise/restart it, so a dead service isn't permanent until reboot.

Expected behavior

Workspace launch transparently recovers from a stopped-but-startable service.

Actual behavior

Banner: "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." — even though a one-line unelevated service start resolves it.