[Cowork][Windows] CoworkVMService idle-shuts down the VM, then the app spins on the missing named pipe forever and never restarts the 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?

On Windows, CoworkVMService starts the Cowork VM correctly, then shuts it down on an idle timeout roughly 45 seconds later when no client has attached. The service then exits, which removes its named pipe \\.\pipe\cowork-vm-service. From that point the desktop app retries the pipe once per second, indefinitely, and never attempts to start the service again. Cowork stays dead until the user manually runs Start-Service CoworkVMService, and then the same cycle repeats.

Three things make this far harder to diagnose than it should be:

1. The in-app banner is misleading. It says "Claude's workspace service is not running. Restart your computer to restore it. Reinstalling will not fix the problem." Rebooting does not help, because the service idles out again on the next cycle. I power-cycled the machine twice and restarted the app many times before finding the actual cause in the service's own log.

2. SCM misreports the exit. The orderly shutdown is logged as System event 7034, "The Claude service terminated unexpectedly." That points every diagnosis at a crash. cowork-service.log shows it is not a crash: it is a clean, intentional idle shutdown.

3. The service cannot configure its own recovery, and neither can the user. At startup it logs: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access denied. Independently confirmed: sc.exe failure CoworkVMService ... and Set-Service CoworkVMService -StartupType ... both return OpenService ERROR 5: Access denied from an elevated administrator prompt, while Set-Service vmcompute succeeds in that same prompt. The service's DACL blocks configuration changes even for Administrators, so the commonly suggested "add SCM restart actions" workaround is unavailable.

What Should Happen?

When the named pipe is missing, the app should attempt to start CoworkVMService instead of retrying the pipe once per second forever. Alternatively, the VM should not idle-shut-down while Claude Desktop is running.

Secondary:

• Ship the service with SCM recovery actions preconfigured at install time, since its own DACL later prevents both the service and the administrator from adding them.
• Fix the banner text: "restart your computer" does not resolve this state, and telling users it will sends them down a dead end.
• Do not surface an orderly idle shutdown in a way that reads as a crash.

Error Messages/Logs

From the Cowork service log (`ProgramData\Claude\Logs\cowork-service.log`) — the VM starts cleanly and mounts the configured host shares:


17:29:27 [VM] Starting compute system...
17:29:27 [HCS] HcsStartComputeSystem returned: hr=0x0
17:29:27 [VM] Adding Plan9 share via HcsModifyComputeSystem: name=<share> path=<host drive> port=<port>
17:29:27 [VM] VM started successfully
17:29:30 [RPC] sdk-daemon connected from VM <vm-id>
17:29:30 [VM] Network status: CONNECTED
17:29:30 [VM] sdk-daemon is ready!
17:29:31 [VM] Installed <n> CA certificates in guest
17:29:31 [VM] API reachability: REACHABLE


47 seconds later, with no client attached, it tears itself down:


17:30:14 [VM] Stopping VM...
17:30:14 [VM] Graceful shutdown failed, forcing termination: HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032
17:30:14 [RPC] sdk-daemon disconnected
17:30:14 [VM] VM stopped
17:30:15 [Server] Session <redacted> has no active connections, idle timeout starts
17:30:15 [Server] Event subscriber disconnected (remaining: 0)


From the VM node log (`LOCALAPPDATA\Claude\Logs\cowork_vm_node.log`) — once the service exits, the app spins forever with no recovery attempt:


17:30:50 [warn] [vm-client] Event resubscribe failed: Error: ENOENT: connect to \\.\pipe\cowork-vm-service failed: the pipe does not exist
17:30:51 [warn] [vm-client] Event resubscribe failed: Error: ENOENT: ... (identical, once per second, indefinitely)


Windows event log:


Application / CoworkVMService / Id 1
  Claude VM Service: failed to configure SCM recovery actions; if the service crashes
  it will not restart until the machine reboots: open service: Access denied.

System / Service Control Manager / Id 7034
  The Claude service terminated unexpectedly. It has done this 1 time(s).

Steps to Reproduce

1. Windows 11, Claude Desktop MSIX build. Observe CoworkVMService is Stopped and the app shows the banner "Claude's workspace service is not running."
2. In an elevated PowerShell: Start-Service vmcompute; Start-Service CoworkVMService. Both report Running.
3. Open Claude Desktop and let it sit without a Cowork session attaching to the VM for about a minute.
4. Tail \ProgramData\Claude\Logs\cowork-service.log. The VM boots, mounts the Plan9 shares, and reports API reachability: REACHABLE — then, ~45 s later, logs Stopping VM... followed by has no active connections, idle timeout starts.
5. Tail %LOCALAPPDATA%\Claude\Logs\cowork_vm_node.log. It begins logging ENOENT: connect to \\.\pipe\cowork-vm-service failed: the pipe does not exist once per second and never stops.
6. Get-Service CoworkVMService now reports Stopped. The app never attempts to restart it, and the only recovery is running Start-Service by hand — which reproduces the cycle.

Rebooting the machine does not change any of this, contrary to what the banner states.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.258 (bundled CLI in Claude Desktop 1.44121.1.0)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

| Item | Value |
|---|---|
| Claude Desktop | 1.44121.1.0 (x64, MSIX) |
| Previous build | 1.40609.1.0 (installed the day before; unaffected that morning) |
| Bundled CLI / SDK in guest | 2.1.258 |
| Get-AppxPackage Status | Ok |
| Domain-joined | No |
| HypervisorPresent | True |
| VirtualMachinePlatform | Enabled |
| Microsoft-Windows-Subsystem-Linux | Enabled |
| HypervisorPlatform | Enabled |
| Microsoft-Hyper-V-All | Disabled (not required per prior issues) |
| WSL | v2 |
| CoworkVMService | StartType Automatic, DisplayName "Claude" |
| vmcompute / hns | Running |

Ruled out during diagnosis

All of the following were checked and eliminated before filing:

• No permissions block in user settings; no deny entries in the user config.
• No managed-settings policy file present; machine is not domain-joined.
• The per-tool MCP toggles file contains no workspace entry.
• cowork-enabled-cli-ops.json holds only an owner id. Renaming it makes the app regenerate a byte-identical file, so it is not an allowlist of enabled operations.
• All three required Windows virtualization features enabled; hypervisor present; WSL2 functional; HCS services running.
• MSIX package integrity Ok.
• Deleted the VM bundle directory and let the app re-download it. The VM then booted cleanly — and still idled out.
• Clean-state sequence applied: graceful Stop-Service, kill residual processes, restart hns and vmcompute, delete bundle, start the service before launching the app.
• Removed the remote-control bridge state (a Cowork session had been opened from the web, leaving an active remote session) and ended that web session.
• DCOM 10016 is present but its AppID resolves to PerAppRuntimeBroker, which Microsoft documents as benign.
• Two full power cycles; many app restarts.

Note on a separate, concurrent defect

On the same machine and in the same period, every mcp__workspace__bash and mcp__workspace__web_fetch call was refused with Permission to use mcp__workspace__bash has been denied, with no permission prompt, in every session including brand-new ones. That is a different defect, already reported and root-caused in #91636 (alias expansion of the host-loop --disallowedTools Bash into a deny of the workspace tool in CLI 2.1.258).

I mention it only because the two occurred together, and the interaction cost several hours of misdirected debugging: the alias-expansion regression makes the shell unusable even when the VM is verifiably healthy, while this idle-shutdown loop simultaneously makes the VM look like the culprit.