[BUG] Windows: workspace stuck on "VM service not running" — Claude doesn't call StartService on CoworkVMService when its named pipe is missing

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?

Environment:

• Claude desktop 1.7196.0.0 (MSIX/AppX packaged build) on Windows 11 Pro 26200.8457
• Service CoworkVMService (binary cowork-svc.exe), WIN32_PACKAGED_PROCESS, runs as LocalSystem
• IPC: named pipe \\.\pipe\cowork-vm-service

Diagnosis — two compounding bugs

1. The service dies without a graceful shutdown.

Before ~March 16: every service exit was preceded by Service stop requested / Shutdown signal received.
After March 16: 60+ subsequent restarts with zero shutdown markers — the process is being terminated, not signaled. Matches two SCM Event 7034 "terminated unexpectedly" entries.
Likely cause: AppX runtime reclaiming the packaged service.

1. Nothing restarts the service when it dies.

sc qfailure CoworkVMService shows no recovery actions (RESET_PERIOD: 0).
On every startup the service logs Warning: failed to open service for recovery config: Access is denied. — it tries to install its own restart policy and fails because LocalSystem doesn't hold the right access mask on SCM.
The DACL on this MSIX-registered service also denies SERVICE_CHANGE_CONFIG to local Administrators (sc failure returns Access Denied even from elevated PowerShell), so an admin user can't fix recovery actions either.
Claude desktop's own recovery path (vm-client in cowork_vm_node.log) retries the pipe for ~50s, attempts a bundle reinstall (Skipping auto-reinstall (already attempted once)), and then surrenders — it never calls StartService via SCM, even though that's the only thing that would work.

What Should Happen?

Suggested fix (any one of these would resolve it)

• In Claude desktop's recovery path, when the pipe is ENOENT, attempt StartService("CoworkVMService") (and surface a clear "needs admin" message only if that also fails) before falling through to the dialog. This is the smallest and most correct fix.
• In the MSIX package manifest, ship CoworkVMService with a service trigger (SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT on the named pipe) so SCM auto-starts it on demand.
• Install SCM recovery actions at package install time (during MSIX deployment, when the installer has admin), so the service self-heals after unexpected termination. The runtime attempt to set recovery from inside the service is structurally doomed and the warning should be removed.

Error Messages/Logs

[warn] [vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service   (×40+)
[info] [VM:start] Configuring Windows VM service...
[error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.
[info] [VM:start] Skipping auto-reinstall (already attempted once)

Steps to Reproduce

Reproduction (deterministic — for the recovery-path bug)

Bug 2 (Claude doesn't call StartService) can be triggered in seconds on any affected install. Bug 1 (the unclean termination) happens on its own, so steps below simulate it with Stop-Service.

Install Claude desktop (MSIX build, e.g. 1.7196.0.0) on Windows 11.
Open Claude once and use any feature that touches the workspace, so the VM bundle is materialized in %APPDATA%\Claude\vm_bundles\claudevm.bundle\. Confirm:
Get-Service CoworkVMService # Status: Running
Simulate the kill that Windows is doing in the wild:
Stop-Service CoworkVMService -Force
Get-Service CoworkVMService # Status: Stopped
Trigger the workspace start — fully quit Claude (tray icon → Quit), relaunch it, and open whichever feature uses the workspace.
Observe the bug — within ~50 seconds the dialog appears:
Failed to start Claude's workspace — VM service not running. The service failed to start.

Confirm Claude's recovery path never tried SCM — tail %APPDATA%\Claude\logs\cowork_vm_node.log. You'll see:
[warn] [vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service (×40+)
[info] [VM:start] Configuring Windows VM service...
[error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.
[info] [VM:start] Skipping auto-reinstall (already attempted once)
No StartService, no SCM call — just pipe polling, one bundle-reinstall, then the dialog.
Confirm the trivial fix — from a non-admin PowerShell:
Start-Service CoworkVMService
The service starts, the named pipe appears, Claude's workspace becomes usable immediately. (You may need to dismiss/retry the dialog.)
Observing bug 1 (the unclean termination)

Not deterministic — happens roughly every few hours of normal use:

Leave Claude running. Periodically check Get-Service CoworkVMService and Get-WinEvent -LogName Application -ProviderName CoworkVMService -MaxEvents 20.
Eventually the service is Stopped, a fresh Claude VM Service starting... event appears later when Claude (or the user) starts it again, and cowork-service.log shows no Service stop requested / Shutdown signal received lines between them — only graceful exits log those, killed ones don't.
Companion evidence anyone can capture in seconds

sc.exe qc CoworkVMService # TYPE: 210 WIN32_PACKAGED_PROCESS (so AppX lifecycle applies)
sc.exe qfailure CoworkVMService # RESET_PERIOD: 0, no actions — no SCM recovery configured
sc.exe failure CoworkVMService reset= 86400 actions= restart/5000

→ [SC] OpenService FAILED 5: Access is denied (even from elevated PowerShell)

The third command failing from elevated PowerShell proves an admin user cannot install recovery actions themselves — the MSIX-packaged service's DACL denies SERVICE_CHANGE_CONFIG to Administrators. This is why the fix has to ship in the package, not be applied client-side.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude desktop 1.7196.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_