[BUG] CoworkVMService fails to configure SCM recovery actions (Access denied) — crashes require manual Task Manager kill + Repair, app doesn't self-heal

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?

Claude Desktop's background CoworkVMService (Windows service "CoworkVMService",
display name "Claude", runs as LocalSystem) fails to register its own crash-recovery
policy with the Service Control Manager on every single start — not intermittently,
every time. The service log shows this exact warning on every launch:

Warning: failed to configure recovery actions (a crashed service will stay down
until reboot): open service: Access is denied.

Because of this, when the service (or its child conhost.exe console host) hangs or
crashes, Windows has no auto-restart policy to fall back on — the app just goes
dead. Settings > Apps > Claude > Repair then refuses to run with "We couldn't
repair this app because it's currently running," because orphaned claude.exe and
conhost.exe child processes are still alive even though the main window is gone.
The only workaround is manually ending every claude.exe/conhost.exe process in
Task Manager, then running Repair.

This has happened twice within 24 hours on the same machine.

What Should Happen?

CoworkVMService should be able to configure its own Windows service recovery actions, and a crash should trigger auto-restart instead of leaving the app dead and requiring a manual Task Manager purge before Repair will run.

Error Messages/Logs

Steps to Reproduce

1. Use Claude Desktop normally (in my case, with active tool/terminal use via

Claude Code sessions running through the Cowork VM).

1. At some point the CoworkVMService or a conhost.exe child hangs — in my case

captured via Windows Event Viewer:

• Application Hang event (ID 1002) for conhost.exe at 2026-08-22 00:33:44
• CoworkVMService's own log shows "Service stop requested" at the identical

timestamp, 2026-08-22 00:33:44.849273

1. Service restarts on its own twice in quick succession (00:50:13, then again

00:56:22) — each start logs the same "Access is denied" recovery-config warning.

1. App becomes unresponsive / effectively crashed from the user's perspective.
2. Go to Settings > Apps > Installed apps > Claude > Repair.
3. Get "We couldn't repair this app because it's currently running. Close the app

and try again" — even though the visible app window is already gone.

1. Confirmed via Get-Process that 17 claude.exe processes and 10 conhost.exe

processes were still alive, all orphaned from the crash.

1. Manually ending all of them in Task Manager is required before Repair will run.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.34493.1.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_