CoworkVMService DACL blocks its own crash-recovery config; after a crash nothing restarts it and Dispatch hangs silently

Environment: Windows 11 Home 10.0.26200 | Claude Desktop 1.26832.0.0 (MSIX) | Claude Code 2.1.226

Summary

CoworkVMService (display name "Claude", LocalSystem, auto-start) cannot set its own crash-recovery policy because of the DACL it is installed with. When it later crashes, nothing restarts it — and Dispatch does not report the outage. It accepts messages, begins a turn, and hangs indefinitely.

The service cannot configure its own recovery

This appears in the service's log on every startup, including a clean one:

Warning: failed to open service for recovery config: Access is denied.

The DACL looks like the cause. Administrators are absent entirely; Authenticated Users get start/stop but not SERVICE_CHANGE_CONFIG:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-<service-sid-redacted>)

AU has RP (start) and WP (stop) but no DC. Consequently:

PS> sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/restart/10000/restart/30000
[SC] OpenService FAILED 5:
Access is denied.

That fails from an elevated prompt too, which is consistent with Administrators having no ACE at all.

What that leads to

The service terminated twice (System event log, ID 7034, "The Claude service terminated unexpectedly") on 2026-08-06 and 2026-08-08. With no recovery policy configured, Windows had no instruction to restart it, so it simply stayed Stopped — roughly 11 hours in the second case, until started by hand.

The failure is silent, which is the worse half

With the service down, Dispatch gives no indication anything is wrong:

• messages are accepted and marked Read
• a turn starts (thinking indicator appears, send button becomes a stop button)
• it then hangs indefinitely
• the stop button is also unresponsive

The actual error — "Failed to start Claude's workspace / VM service not running. The service failed to start." — only surfaced after navigating into the background conversation behind Dispatch. Before finding it, the obvious (and wrong) conclusion was that mobile pairing or Dispatch setup was incomplete; roughly two days went into checking that. A message in the Dispatch thread itself would have resolved it in seconds.

Workaround

Start-Service CoworkVMService

Works unelevated, since the DACL does grant AU start rights.

Suggested fixes

1. Grant Administrators (or the installing principal) SERVICE_CHANGE_CONFIG so the recovery policy can be set — or configure the recovery actions at install time from the MSIX, so the service does not need to do it itself.
2. Surface "VM service not running" in the Dispatch thread rather than hanging on the turn.
3. Make the stop button cancel a turn that is wedged in this state.

Possibly related

C:\ProgramData\Claude\Logs\cowork-service.log had grown to 338 MB. Renaming it and restarting the service produced a clean start, so log size may be implicated in the crashes — or at least is worth a rotation policy of its own.