Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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.

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