[BUG] [BUG] CoworkVMService cannot manage its own SCM recovery actions, gets auto-restarted during package servicing, and leaves Claude Desktop in NeedsRemediation (root cause from your own service log, plus a working recovery)
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?
Windows 11 Pro, build 10.0.26200, x64
Installer bootstrapper f65e386db0db64c8f8b39950e25adb11f5f5e3f3
Package version 1.40609.0.0, family Claude\_pzs8sxrjxfjjc
MSIX SHA256 e71b97d5eed6f943f9f2e0b05311286d11dfab78848353acbf7aec789167e144, 263517126 bytes,
identical across all four download attempts, so the payload is not the problem
What happens
The desktop app crashed repeatedly during normal use. Reinstalling made it worse, and the
installer then refused to install at all. Four runs of Claude-Setup-x64.exe in twelve minutes.
Run 1 (15:47) and run 2 (15:55) reported success, and the app still crashed:
WARNING: CoworkVMService already exists (potential conflict)
Conflicting service: true
Is elevated: true
Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
Removing: Claude\_1.40609.0.0\_x64\_\_pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude\_1.40609.0.0\_x64\_\_pzs8sxrjxfjjc
(0x80073CFA, requires developer mode); relying on in-place update
Installing via AddPackage (current-user)...
MSIX package installed successfully
=== Claude Setup completed successfully ===Run 3 (15:57), service now gone, install fails outright:
Conflicting service: false
Checking for existing Claude MSIX packages...
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
ERROR dialog (with log path): Administrator access is required to install Claude with full
### What Should Happen?
Expected
Either the installer removes the conflicting service and the old package cleanly, or it aborts
with a clear message. Falling back to an in-place update over a package whose removal was just
rejected leaves the installation wedged, and the user has no supported way back.
Three separate defects
`CoworkVMService` cannot be removed even from a fully elevated process. The log shows
`Is elevated: true` and `Elevation type: Full`, and `OpenService` still returns Access denied.
The service DACL appears to deny Administrators, so the installer's own cleanup path can never
succeed as written.
The "relying on in-place update" fallback produces a corrupted package. After `AddPackage`
reports success, `Get-AppxPackage \*Claude\*` shows `Modified, NeedsRemediation`. Windows' own
Repair and Reset both fail on that state. Calling `AddPackage` on a package whose removal was
just rejected should use force flags or abort.
The final error message is wrong and sends users down a dead end. "Administrator access is
required" appears after a run that was already elevated. The real failure is
`ERROR\_INSTALL\_REGISTRATION\_FAILURE` from leftover package state, which no amount of
re-elevating fixes. It cost several cycles of re-running the installer as admin before anyone
### Error Messages/Logs
```shell
Root cause, as logged by your own service
After a successful clean reinstall the package went back to `Modified, NeedsRemediation` within
about 35 minutes of normal use. The Windows Application log explains the mechanism, and the
entries come from `CoworkVMService` itself:
5:19:52 PM CoworkVMService Information Claude VM Service stopped.
5:19:52 PM CoworkVMService Warning Claude VM Service: failed to disarm SCM recovery actions
for this stop; if the stop overruns, the service may be
auto-restarted during package servicing:
open service: Access is denied.
4:44:06 PM CoworkVMService Warning 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.
4:44:06 PM CoworkVMService Information Claude VM Service starting.
Read together with the installer log, the chain is:
`CoworkVMService` cannot open its own service handle through the SCM, so it can neither arm
its recovery actions on start nor disarm them on stop. Both fail with Access denied, and the
service says so itself.
Its recovery configuration therefore stays in whatever state it was last successfully written,
outside the service's control.
When the service stops during package servicing and the stop overruns, the SCM applies those
stale recovery actions and restarts it, exactly the situation the second warning predicts.
The restarted service re-acquires its locks on the Helium hives while AppX is mid-registration.
Registration completes partially, and the package is left `Modified, NeedsRemediation`.
That also explains why the installer's own cleanup fails with the same Access denied: it is the
same missing SCM permission, seen from the other side.
The service account appears to lack the rights to manage its own service entry. Issue #81747
reports `S-1-5-83-0` having correct `SeServiceLogonRight` while the same Access denied persists,
which points at the service DACL rather than at logon rights.Steps to Reproduce
Working recovery
Posting this because none of the related issues below carry a sequence that worked. This one did,
in an elevated PowerShell:
# 1. Teardown
Get-Process claude,cowork-svc,parsecd,chrome-native-host -ErrorAction SilentlyContinue | Stop-Process -Force
Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
sc.exe delete CoworkVMService
Get-AppxPackage -AllUsers \*Claude\* | ForEach-Object { Remove-AppxPackage -Package $\_.PackageFullName -AllUsers -ErrorAction Continue }
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -like "\*Claude\*" | ForEach-Object { Remove-AppxProvisionedPackage -Online -PackageName $\_.PackageName }
Remove-Item "$env:LOCALAPPDATA\\AnthropicClaude","$env:LOCALAPPDATA\\Packages\\Claude\_pzs8sxrjxfjjc","$env:APPDATA\\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Get-AppxPackage -AllUsers \*Claude\* # must come back empty
# 2. Reinstall
$msix = "$env:TEMP\\Claude-fresh.msix"
Invoke-WebRequest "https://claude.ai/api/desktop/win32/x64/msix/latest/redirect" -OutFile $msix -UseBasicParsing
Add-AppxPackage -Path $msix -ForceApplicationShutdown
Get-AppxPackage \*Claude\* | Select-Object PackageFullName, Status # must read OkResult: Claude\_1.40609.0.0\_x64\_\_pzs8sxrjxfjjc with status Ok, and CoworkVMService recreated
and running once the app launched. A reboot between the two blocks is advisable to release the
locks on the Helium hives. In this case it was not needed, because the service had already been
deleted during an earlier attempt.
One trap worth documenting: C:\\Windows\\system32 as the working directory looks like an elevated
prompt and is not, and without elevation the same root cause surfaces as three different
messages. Get-AppxPackage -AllUsers says "Access is denied", Get-AppxProvisionedPackage -Online
says "requires elevation", and schtasks /ru SYSTEM says "Access is denied" again.
Suggested fix
Give CoworkVMService the rights to manage its own service entry, or set its recovery actions
from the installer instead of from the service. As long as both arming and disarming fail with
Access denied, the service cannot prevent its own restart during package servicing, and the
defect will keep coming back on its own.
Stop and disable CoworkVMService, then require a reboot before touching the package, since the
service holds kernel locks that no user-mode call can release.
Abort with a distinct error when removal fails, instead of continuing into AddPackage.
Detect NeedsRemediation at launch and offer the teardown, instead of crashing.
Report the registration failure in the error dialog. The current elevation message is actively
misleading.
Related issues
Same signature, all closed as duplicate or stale, none with a published fix version: #48437,
#49104, #49540, #49655, #49917, #59471, #66635, #68792, #81747, #81992, #84333. Tracking issue
appears to be #80444.
The full ClaudeSetup.log is available and can be attached on request.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.40609.0.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Confirming your DACL hypothesis with the actual security descriptor, and adding a much cheaper
recovery for the case where the package is still healthy but the service has simply died.
Same environment: Windows 11 Pro 10.0.26200, package
Claude_1.40609.0.0_x64__pzs8sxrjxfjjc.The DACL, decoded — it is the service DACL, and Administrators genuinely are not on it
Two ACEs, and that is the entire list:
AU(Authenticated Users):CC LC SW RP WP DT LO CR RC— query config, query status, enumeratedependents, start, stop, pause/continue, interrogate, read control. No
DC(
SERVICE_CHANGE_CONFIG).NT SERVICE\AppXSvc, and it alone holdsDC,SD,WD,WO.BA(Administrators) and no ACE forSY(LocalSystem).So this is not a logon-rights problem, and elevation cannot help — which matches your
Is elevated: true+ Access denied exactly. Confirmed from an elevated prompt:The service runs as LocalSystem with
SERVICE_SID_TYPE: UNRESTRICTED, so its token does carryNT SERVICE\CoworkVMService(S-1-5-80-690231842-763816591-443537665-320658410-1005583601) —also absent from the DACL. Hence the service cannot open its own handle, in either direction, and
your two warnings are structurally unfixable rather than intermittent.
And there is no policy to fall back on — the recovery configuration is not merely stale, it is empty:
A one-second recovery for the common case
Your teardown sequence is the right answer for a package already in
Modified, NeedsRemediation.But most occurrences here never get that far — the package stays
Okand only the service isdead. For that case the
AUACE above already grantsRP(SERVICE_START), so this worksunelevated, with no package churn:
Verified on a machine where the service had been stopped for ~90 minutes
(
WIN32_EXIT_CODE 1067,ERROR_PROCESS_ABORTED): state wentSTOPPED→RUNNINGin about asecond, and the app reconnected to
\.\pipe\cowork-vm-serviceon next launch. Worth tryingbefore the full teardown, since it avoids re-downloading the 263 MB MSIX.
Suggested fix that needs no new privileges
Since
AUalready hasSERVICE_START, the app can start the service itself. Checking theservice state at launch — and on a named-pipe connect failure — and calling
StartServicewouldmake this entire class of failures invisible, with no manifest change and no elevation. The
manifest-declared restart policy is the more correct fix, but the app-side start is a one-liner
and would help today.
Relatedly, the
failed to configure SCM recovery actionswarning fires on every service startand can never succeed. Downgrading or removing it would stop sending people after a permissions
problem that is not theirs.
Why Settings → Repair is an unreliable escape hatch
You noted Repair and Reset both fail on
NeedsRemediation. Separately, Repair also fails onhealthy packages, because it races the service it just reinstalled. It issues
RepairPackageOperation+Add+RegisterByPackageFullNamewithRepairAppRegistrationOptionbut without
ForceApplicationShutdownOption; its ownAddstep reinstalls the auto-startservice (SCM
7040+7045), SCM starts it in the same second, and theRegisterstep thenfails:
Observed failing at 2026-08-19 17:01:42, 08-20 20:50:29, 08-20 20:50:48, 09-01 16:09:21 and
09-01 20:11:30 — the second click usually succeeds, which is why it reads as flaky rather than
broken. Passing
ForceApplicationShutdownOptionthere would fix it.Frequency, for severity
Service Control Manager7034 ("The Claude service terminated unexpectedly") in the retainedSystem log on one machine: 2026-07-04, 07-11, 08-01, 08-12, 08-19, 08-20, and five times on
09-01 alone. Because the app window keeps working while the service is down, users generally do
not notice until something needs it.
Happy to supply full logs.
Confirming this is still very much alive on
Claude_1.46388.2.0_x64__pzs8sxrjxfjjc→1.46388.3.0— two occurrences on the same machine today, same exact signature (open service: Access is deniedon both configure and disarm), both requiring a full OS reboot (didn't know about the unelevatedStart-Serviceworkaround at the time — trying that next time).Windows 11 Pro 10.0.26200.
Incident 1 (morning) — coincided with an install-time failure
Reinstall via
Claude Setup.exesucceeded once, then a second install attempt shortly after failed withHRESULT 0x80073CF6(ERROR_PACKAGES_IN_USE) onAddPackage, withCoworkVMServicewarnings in the setup log along the way. Same underlying missing-DACL-entry class of problem showing up at install time, not just runtime — matches the install-side reports (e.g. #78873, #85698) as much as the runtime ones here.Incident 2 (evening, ~22:14–22:33 local) — runtime RPC drop + restart-loop during self-update
From
C:\ProgramData\Claude\Logs\cowork-service.log:That start/stop pair (identical warning both directions) then repeated at
22:14:55,22:30:39, and finally22:33:17, with the package version in the signed-binary path silently flipping from1.46388.2.0to1.46388.3.0partway through — i.e. this batch of restarts was the self-update pushing a newcowork-svc.exe, exactly the mechanism #89814 describes. Event Viewer (Application, providerCoworkVMService) shows the same warning firing on essentially every start throughout the day, not just around the two visible incidents — it's constant background noise, the app window just doesn't surface it until the RPC pipe actually drops.Full reboot at 22:32 (clean, user-initiated — confirmed via
1074/6006in the System log, not a crash) was what actually cleared it; the service came back healthy on1.46388.3.0afterward.+1 on the suggested fix (app calls
StartServiceitself on named-pipe connect failure, using theAUACE's existingSERVICE_STARTright) and on downgrading/removing the "failed to configure recovery actions" warning since, per your DACL dump, it structurally can never succeed as currently shipped.Confirming this is still reproducing, on Claude_1.52386.0.0_x64__pzs8sxrjxfjjc (app auto-updated 2.1.258 → 2.1.260 on 09-08, then → 2.1.266 on 09-11). Windows 11 Pro 10.0.26200, AzureAD-joined device, local admin account.
Same signature on both directions, and the exact same SDDL @MantenRoku posted:
ServiceSidTypeis 1 (Unrestricted) perHKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService, andsc sdshow scmanageris stock/default on this machine — so it's not a local policy issue either. Matches the "structurally unfixable as shipped" conclusion above.Recurrence pattern from Event Viewer (Application, source CoworkVMService) — identical warning on every single start/stop, across three separate days:
User-visible impact matches what's described in this thread: the app appears to "shut down by itself" and needs a manual relaunch after updates. No matching Application Error/WER crash event for claude.exe itself, and the Crashpad reports folder was empty — consistent with this being the missing auto-recovery safety net rather than an actual crash. No data/session loss observed across any of these incidents.
+1 on the unelevated
Start-Service CoworkVMServiceworkaround and on downgrading/removing the "failed to configure recovery actions" warning, since per the DACL dump it cannot succeed as currently shipped.