[BUG] CoworkVMService crasht wiederholt ("Access is denied" bei Recovery-Actions-Konfiguration), App muss neu gestartet werden – Regression nach Update auf 1.32352.1.0

Independent confirmation on another Windows 11 machine running the same version (Claude_1.32352.1.0_x64__pzs8sxrjxfjjc) — same warnings, same service, same "Another program is currently using this file" dialog captioned with the package path, same reboot-only recovery.

But the data on this machine does not support the "Regression nach 1.32352.1.0" framing, and I think that matters for whoever picks this up.

C:\ProgramData\Claude\Logs\cowork-service.log here spans 2026-04-21 → 2026-08-18 and covers 48 distinct package versions (~47 updates). The recovery-config Access is denied warning is on the very first line of the log, under the older wording:

2026/04/21 18:54:54.797635 Warning: failed to open service for recovery config: Access is denied.

Occurrences per month, all four months:

| month | count |
|---|---|
| 2026-04 | 5 |
| 2026-05 | 25 |
| 2026-06 | 31 |
| 2026-07 | 33 |
| 2026-08 | 23 |

Split by wording:

• failed to open service for recovery config — 102, from 2026-04-21 up to 2026-08-12 (last: 1.28929.0.0)
• failed to configure recovery actions — 11, from 2026-08-14 onward (first: 1.30096.1.0)

So the arm failure is ~4 months and ~47 updates old; only the log wording changed on 2026-08-14. It is not new in 1.32352.1.0.

The one thing that is new in this log is the disarm line:

Warning: failed to disarm recovery actions for this stop: open service: Access is denied.

4 occurrences, all on 2026-08-18, all during the update episode (10:42:48, 10:52:53, 10:56:13, 10:56:59). Since the wording change landed 2026-08-14 and ~47 earlier updates produced none, I cannot tell from this log alone whether that is a newly broken code path or newly logged one — worth checking on your side, because that message is the one that describes the actual failure mode ("if the stop overruns, the service may be auto-restarted during package servicing").

Service config here, for reference:

TYPE               : 210  WIN32_PACKAGED_PROCESS
START_TYPE         : 2    AUTO_START
SERVICE_START_NAME : LocalSystem
BINARY_PATH_NAME   : "C:\Program Files\WindowsApps\Claude_1.32352.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
DEPENDENCIES       : staterepository

sc qfailure CoworkVMService returns RESET_PERIOD : 0 with no actions configured — consistent with the arm call having failed rather than having been set and later cleared.

Restart frequency on this machine: normal days show 1–4 Service ready events. 2026-08-18 shows 9, clustered 10:41:38 → 11:06:42 across the update, then stable after a reboot. So I see the restart clustering you describe, but here it is bounded to the update window rather than an ongoing 1–3 minute loop.

Honest caveat about how this was produced: I did not catch the failure live. By the time I looked, the user had already rebooted and the machine was healthy — single package version, Status: Ok, only the app's own claude.exe processes holding modules from the package. Everything above is reconstructed after the fact from cowork-service.log, the Windows Application event log (provider CoworkVMService), sc qc / sc qfailure, and Get-AppxPackage. The month-by-month counts and the version list are direct measurements from the log and I'd stand behind those; the causal story — service still up while servicing replaces package files — is inference consistent with them, not something I observed happening.

Two things I ruled out with evidence, in case they save someone time: every node.exe on this machine runs from C:\Program Files\nodejs\node.EXE, not from the package, so unrelated background Node processes cannot lock it; and Microsoft-Windows-AppXDeploymentServer/Operational contains zero Error or Warning events for this package — the last entry is a clean Deployment Register ... finished successfully. The failure never surfaces in Windows' package layer as an error, which is probably why it is hard to find from the deployment side.

Thanks for the independent confirmation and for actually quantifying it — this is more rigorous than what I had.

I think you're right that "regression in 1.32352.1.0" was the wrong framing on my part. Given the failed to open service for recovery config warning is present from your very first log line (2026-04-21) through ~47 subsequent updates, the underlying arm failure is clearly chronic, not something this specific build introduced.

What I'd revise the hypothesis to, based on your data: the arm-config permission issue has been there for months and was mostly silent because there was nothing to disarm. The failed to disarm recovery actions for this stop line — new, first seen 2026-08-14 in wording and first failing on 2026-08-18 — suggests a disarm-on-stop code path that started actually running (or started being hit) around that window. Since the underlying permission problem was never fixed, that call fails too, and the log line itself documents the consequence: the service isn't disarmed before the stop, so it can be auto-restarted by SCM while package servicing is mid-replace — which is consistent with the file-lock dialog.

So: old permission bug, but a newly-exercised disarm-on-stop path is what's making it visible now. If that's right, the fix isn't "don't regress the arm call" but "the disarm-on-stop path needs the same recovery-config permission the arm call never had, and/or it needs to not be invoked against a service whose recovery config was never successfully armed in the first place."

Would be good to get confirmation from someone with access to the cowork-svc.exe change history around 1.30096.1.0–1.32352.1.0 on whether a disarm-during-stop call was added or changed there — that's the one piece neither of our logs can settle.

Quick addendum since two other issues just got linked here that I think belong in the same bucket as the analysis above, even though the surface symptoms differ:

• #76357 (v1.20186.0.0, 100% reproducible, 20+ occurrences): independently names CoworkVMService plus lingering Claude.exe processes that don't exit on shutdown as the file-lock source during MSIX update. This predates 1.32352.1.0 by a lot, which lines up with the "chronic, not a new regression" read above.
• #87607 (v1.32352.0.0): a different mechanism — leaked Hyper-V VM kernel-side handles (vmmemCmZygote) on package files, invisible to Restart Manager/Task Manager, only cleared by reboot. The reporter's own suggested fix is "Fix CoworkVMService ACL/recovery design issues" — which is effectively the same permission problem discussed above, arrived at independently from VM-handle evidence rather than service-log evidence.

Three independent reports, three different Claude Desktop versions, three different evidence trails (service log, process/service inspection, VM handle leak) — all converging on CoworkVMService's lifecycle and recovery-config permissions as the common root, not a single build. Might be worth treating these as one underlying fix rather than three separate regressions.