[BUG] CoworkVMService kann seine SCM-Wiederherstellungsaktionen nicht konfigurieren

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 5, 2026

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?

Bug: CoworkVMService kann seine SCM-Wiederherstellungsaktionen nicht konfigurieren (Access is denied), da der ACL des Diensts "Authenticated Users" keine SERVICE_CHANGE_CONFIG-Rechte (DC) einräumt – nur das interne NT SERVICE-Konto darf das. Dadurch startet der Dienst nach einem Absturz nicht automatisch neu, sondern erst nach einem vollständigen System-Neustart. Fehlertext: "Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied." Betroffene Version: 1.46388.x.

What Should Happen?

When CoworkVMService starts, it should be able to configure its own SCM
failure/recovery actions (restart on crash) without an "Access is denied"
error. If the service later crashes, Windows should then automatically
restart it, so Claude Desktop keeps working normally.

Instead, the service's ACL only grants "Authenticated Users" query/start/
stop rights, but not SERVICE_CHANGE_CONFIG (DC), so the app cannot set
recovery actions at runtime. As a result, if the service crashes, it stays
down until a full system reboot — Claude Desktop then fails to start with
"another program is accessing this file" until the user manually reboots.

Error Messages/Logs

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

Decoded service ACL (sc.exe sdshow CoworkVMService):
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)
  (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

-> "Authenticated Users" (AU) has query/start/stop/interrogate rights only
   (missing DC = SERVICE_CHANGE_CONFIG). Only the internal NT SERVICE
   virtual account has full rights, so a normal (non-elevated) process
   cannot reconfigure recovery actions.

Symptom on app start after this occurs:
"another program is accessing this file:
C:\Program Files\WindowsApps\Claude_1.46388.4.0_..."
Fixed only by repairing the app (Windows Settings > Apps) or a full
system reboot; logging off/on does not clear it (the stuck job object
lives in Session 0).

Steps to Reproduce

Note: this is an intermittent issue — the exact trigger for the initial
CoworkVMService crash is not yet identified. These are the steps that
reliably reproduce and confirm the stuck state once it starts, not a
guaranteed way to trigger the underlying crash on demand.

  1. Use Claude Desktop / Cowork normally (Windows 11, Store-installed

version 1.46388.x). At some point CoworkVMService apparently crashes
in the background (cause unknown).

  1. Try to open Claude Desktop again -> app fails to start with:

"another program is accessing this file:
C:\Program Files\WindowsApps\Claude_1.46388.4.0_..."

  1. Open Task Manager -> no visible Claude.exe process is holding the file.
  2. Open Resource Monitor (resmon) -> CPU tab -> Associated Handles ->

search for "WindowsApps\Claude" -> a Job handle shows up, owned by
svchost.exe (netsvcs), named
"Container_Claude_<older version>_x64_...-S-1-5-21-..." (a leftover
AppContainer job object).

  1. Go to Windows Settings > Apps > Claude > Advanced options > Repair.

This works around the issue and the app starts again.

  1. The same failure recurs later (not a one-time event).
  2. Log off and log back in -> does NOT clear the stuck state (the job

object lives in Session 0, unaffected by the user session).

  1. A full system reboot -> does clear it, app starts normally again.
  2. Open Event Viewer > Windows Logs > Application, filter for "Claude" ->

find a recurring entry at every service start:
"Claude VM Service: failed to configure SCM recovery actions; if the
service crashes it will not restart until the machine reboots: open
service: Access is denied."

  1. Run sc.exe sdshow CoworkVMService (elevated) -> confirms

"Authenticated Users" is missing SERVICE_CHANGE_CONFIG (DC) rights,
which is why the service cannot configure its own crash-recovery
action, and therefore cannot self-restart after a crash — requiring
a full reboot every time this happens.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.46388.3

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗