[BUG] Windows: CoworkVMService can never arm its own recovery actions ("Access is denied" at every start) — service death becomes a silent claude.exe hang with no crash dump (root cause of #59794 and #66849, both closed stale)
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?
TL;DR
CoworkVMServicecan never configure its own crash-recovery — every start logsAccess is denied(3+ months, no exception).- When it dies unexpectedly nothing restarts it:
claude.exeblocks on the named pipe and hangs — the "Claude Desktop stops responding / hangs on Windows" symptom. - Recurring across 8 app versions since 2026-05 (13 WER reports); updating hasn't fixed it.
This produces WER hangs (1002), not crashes (1000). Zero Crashpad dumps in three months — invisible to crash telemetry, likely why users keep re-filing this while dashboards look clean.
5-second self-check: run sc qfailure CoworkVMService. If the same holds on your build — and the mechanism says it should, since a packaged service can't grant itself SERVICE_CHANGE_CONFIG — you'll get a valid response with no restart/reboot/run-command actions listed. Paste your output below either way.
(Independent corroboration: #66849 ran this same check on v1.11847.5.0 in June 2026 and found the same unarmed state — that report, labeled has-repro, was closed stale without reply; #70537, the same crash, was closed as its duplicate.)
Mechanism:
- Service start tries to configure its own recovery, gets
Access is denied. - It runs as
LocalSystemand is still denied: a packaged (WIN32_PACKAGED_PROCESS) service's token is identity-restricted beneath the account, belowSERVICE_CHANGE_CONFIG— no account fixes that. - Recovery stays unarmed (
sc qfailureconfirms no configured actions). - Service dies unexpectedly (separate cause), nothing restarts it,
claude.exeblocks on\\.\pipe\cowork-vm-serviceand hangs.
Multiple times daily on affected days; dies mid-session, losing in-flight Cowork workspace work.
Not the Home/Hyper-V-unavailable cluster: Cowork initializes and runs fine here; the workspace works, then the service dies later. Post-initialization failure, not a launch failure. (#66849 reproduced it on Windows 11 Pro with the full Hyper-V stack enabled — the defect is independent of edition.)
Separately, the package also recurringly flips to Modified/NeedsRemediation with the setter unidentified — deliberately out of scope here; will file separately if this issue gets traction.
<details>
<summary>Access-denied warning, exact quotes and timestamps</summary>
Logged at every single service start across 3+ months of retained logs, no exception found:
Warning: failed to open service for recovery config: Access is denied.Sampled: 2026/05/14 21:42:43, 2026/05/18 22:58:52, 2026/08/08 20:27:22, 2026/08/10 20:23:50, 2026/08/10 22:32:23 (30 seconds before the death below).
sc qc CoworkVMService confirms TYPE: 210 WIN32_PACKAGED_PROCESS, SERVICE_START_NAME: LocalSystem, DISPLAY_NAME: Claude (why the service shows up as "Claude," not "CoworkVMService," in every SCM event).
</details>
<details>
<summary>Death timeline — 2026-08-10 22:50:49</summary>
Final 8 lines the service wrote before 17m56s of silence:
2026/08/10 22:32:47.721592 [Server] Client connected
2026/08/10 22:32:48.097205 [Server] Client signature verified: claude.exe (subject: Anthropic, PBC)
2026/08/10 22:32:48.098250 [Server] Client connected: user=<user> exe=claude.exe isDev=false
2026/08/10 22:32:48.098250 [VM] VM owner set: id=cowork-vm-096705da sid=S-1-5-21-<redacted>
2026/08/10 22:32:48.098250 [VM] Event callbacks set
2026/08/10 22:32:48.098250 [Server] Created new VM session for <user>
2026/08/10 22:32:48.098855 [Server] Persistent RPC: entering loop
2026/08/10 22:32:53.801868 [IdleCheck] Session starting idle timer nowNothing more is written. Then:
- 22:50:49 — System event 7034: "The Claude service terminated unexpectedly."
- 22:50:52 (+3s) — claude.exe hang, Application event 1002, fault bucket
2185556362616152072. - 23:03:37 — second claude.exe hang, same fault bucket, WER signature
efa4cdb5— also seen 2026-08-09 21:21:43, a day before any repair, so this isn't repair-induced.
Not a designed idle-shutdown: idle-shutdown, observed working correctly elsewhere in the same log, always starts with an explicit disconnect line and finishes a clean stop within seconds. This death has none of that — no disconnect, no stop request, no shutdown sequence.
</details>
What Should Happen?
A service death should be a recoverable blip, not a silent app hang. Concretely, any of:
(a) Arm recovery actions via the deployment path (manifest/installer).
(b) The code currently tries to arm recovery at every start and silently accepts the failure. At minimum, stop silently accepting it — surface it, retry from an elevated/deployment-time context, or explicitly design around recovery not being available this way. Silently accepting a failure that can never succeed is a bug independent of who owns the permission model.
(c) claude.exe bounds the pipe-connect wait with a timeout, and explicitly calls StartService / handles trigger-start before waiting.
(a) or (b) fixes the underlying defect. (c) is the cheap win: arming recovery at install time + bounding the pipe connect with a timeout turns a silent hang into a self-healing blip, without ever solving the package-flag question.
Error Messages/Logs
At every service start (cowork-service.log):
Warning: failed to open service for recovery config: Access is denied.
sc qfailure CoworkVMService:
[SC] QueryServiceConfig2 SUCCESS
SERVICE_NAME: CoworkVMService
RESET_PERIOD (in seconds) : 0
REBOOT_MESSAGE :
COMMAND_LINE :
(no FAILURE_ACTIONS block — nothing configured to run on failure)
System event log, 2026-08-10 22:50:49, event 7034:
The Claude service terminated unexpectedly. It has done this 1 time(s).
Application event log, 22:50:52 and 23:03:37, event 1002:
The program claude.exe version 1.26832.0.0 stopped interacting with Windows and was closed.
Fault bucket 2185556362616152072 (identical both times; same WER signature also fired 2026-08-09 21:21:43, before any local repair existed).Steps to Reproduce
The permission defect is checkable in 5 seconds on any machine with the Cowork build:
- Run
sc qfailure CoworkVMService— observe: valid response, no restart/reboot/run-command actions configured (recovery never armed). - Optionally run
sc qc CoworkVMService— observeTYPE: 210 WIN32_PACKAGED_PROCESS,SERVICE_START_NAME: LocalSystem. - Check the service log (
C:\ProgramData\Claude\Logs\cowork-service.log) — every start containsWarning: failed to open service for recovery config: Access is denied.
The downstream hang is not on-demand reproducible, but the observation recipe is reliable:
- Use a Cowork session on Windows and leave it connected. When
CoworkVMServiceeventually dies unexpectedly (System event 7034 — here it has happened up to several times daily), nothing restarts it. claude.exe, blocked on\\.\pipe\cowork-vm-service, hangs within seconds (Application event 1002, fault bucket2185556362616152072— deterministic across days and occurrences here).
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
None known — the same WER signature spans 8 app versions since 2026-05-16
Claude Code Version
Claude Desktop 1.26832.0.0 (MSIX / Cowork build) — the defect is in the Desktop app's packaged service. CLI 2.1.227 also present, unaffected.
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
<details>
<summary>Auto-repair cycle by event ID (2026-08-11 08:30, wake-triggered) and matched healthy cycle</summary>
A background watcher (60-second polling) caught a full auto-repair cycle fire at 08:30:12-13, immediately after waking the PC, before any app launch. Overnight idle produced zero events. Microsoft-Windows-AppXDeploymentServer/Operational sequence: RegisterByPackageFullName (603) with RepairAppRegistration + ForceTargetApplicationShutdown → ACL repair (649) → TerminateSingleService against CoworkVMService, twice (9648/9650) → package disabled (10000) → repeated registration step (617) → package re-enabled (10007) → done (400/613). Reported success; package remained Modified, NeedsRemediation immediately after.
Matched healthy cycle at 08:33:51-56: manual Add-AppxPackage -ForceUpdateFromAnyVersion re-stage ran the same sequence and resolved cleanly (package Ok, service running, stable since). Both cycles available on request.
</details>
<details>
<summary>Join keys / prior art</summary>
- Package:
Claude_1.26832.0.0_x64__pzs8sxrjxfjjc - WER hang fault bucket:
2185556362616152072 - Timestamps: 2026-08-09 21:21:43, 2026-08-10 22:50:49, 22:50:52, 23:03:37
- 13 WER reports since 2026-05-16 across 8 app versions — not new, not version-specific.
- If this ships through Partner Center telemetry, this bucket should be pullable for fleet-wide hang counts, if applicable.
- This exact root cause has been filed and closed unanswered twice: #59794 (area:cowork / bug / has-repro — closed stale) and #66849 (area:cowork / area:desktop / platform:windows / has-repro — independently ran
sc qfailure, found the same unarmed state, offered further diagnostics, closed stale by the bot). #70537, the same crash, was closed as a duplicate of #66849 — which was then itself closed stale. - Other related Cowork/Windows failures repeatedly filed by unrelated users — different proximate causes, most closed stale or invalid without engagement; listed as evidence the dashboards look clean, not as duplicates: #25914, #28231, #39891, #51098, #53247, #61559, #67780.
</details>
Form-field note: this is a Claude Desktop / Cowork (GUI) report; the Terminal/Shell and Platform values were selected only because the form requires them.
I'm not a Windows engineer — I had Claude dig into this on my own machine. Every log line above is machine output, not inference. If this can be labeled area:cowork / platform:windows and pointed at whoever owns it, I'll run any diagnostic they want.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Independent corroboration, found while diagnosing #86140 (packaged-service activation failure,
ERROR_INVALID_PARAMETER/87 — a separate root cause, but the same service).Confirmed the same mechanism on a separate Windows 11 25H2 machine:
CoworkVMServicerunning as LocalSystem still getsAccess is deniedwhen it tries to arm its own recovery actions at startup, andsc.exe qfailure CoworkVMServiceshows no actions configured — consistent with your read that a packaged (WIN32_PACKAGED_PROCESS) service can't grant itselfSERVICE_CHANGE_CONFIGregardless of account.+1 on fix (a)/(b): recovery actions need to be armed at install time from the installer, which isn't subject to the packaged-service config lock. Reference config for whoever picks this up:
sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/restart/10000/restart/30000
Independent corroboration on a third machine (Windows 11 Home 10.0.26200, Claude desktop 1.30096.5.0, Cowork build).
Same mechanism confirmed here:
sc.exe qc CoworkVMService→SERVICE_START_NAME: LocalSystemsc.exe sdshow CoworkVMService→D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)—SERVICE_CHANGE_CONFIG/WRITE_DACis only granted to the service's own per-service virtual SID, never toSY(LocalSystem). Matches the packaged-service token restriction described above — the running process can't grant itself that right regardless of account.cowork-service.loglogsWarning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.on every single start, going back to the earliest log entry on this machine (2026-03-02).Stoppeduntil manually started — matches the "silent death, no auto-recovery" behavior described here.+1 on fix (a)/(b) — recovery needs to be armed from the installer, not from the packaged process itself.
For anyone who wants a local workaround in the meantime: since an elevated admin's own token isn't subject to the packaged-service restriction,
sc.exe sdsetrun from an elevated (non-packaged) context can addSYdirectly to the DACL — confirmed working on this machine:This clears the "Access is denied" warning on the next start (equivalent effect to directly running the
sc.exe failurecommand suggested above). Only caveat: this ACL gets reset on every app update — confirmed via the 7045/7040 install/start-type-change event pairs in the System log going back to 2026-05-16 — so it needs reapplying after each update until this is fixed upstream.Fourth machine, and one data point that contradicts the suggested workaround — plus a variant of the death where the crash happens during the handshake rather than after a working session.
Environment: Windows 11 x64, Claude Desktop 1.30096.5.0 (MSIX), host stack verified healthy —
vmcomputeandhnsbothRunning,wsl --statusreports Ubuntu / version 2,CoworkVMServiceisLocalSystem/Auto.The recovery-config defect reproduces exactly as described
No
FAILURE_ACTIONSblock — recovery never armed, same as everyone above. And the warning is in every single start:The
sdsetworkaround does not work here@jtonylperez's mitigation fails on this machine, from an elevated PowerShell:
sc.exe failure ...fails identically. My descriptor is byte-identical to the one quoted above on theD:part, plus an SACL:Reading that DACL:
AUgets query/start/stop only, and the per-service SID gets the write rights. There is no ACE for Administrators orSYat all, so an elevated admin token holds noWRITE_DACon this object either — which is consistent with the denial, and suggests the elevated-context escape may not be generally available. Worth flagging so others don't conclude the mitigation is broken on their end.That makes fix (a) — arming recovery from the installer — the only path that works for users in this state. There is currently no local mitigation at all on this machine.
Variant: the service dies during the handshake, before
configureThe reports here describe a service that dies mid-session after Cowork has initialized. Here it never initializes: the service crashes at first contact, so the VM is never created.
Service log, clean start:
Then the client reconnects once per second, 45 times, and the log simply ends — no
configure, noClient signature verified, no error:System log, same second as the last connection:
Application log, two seconds later:
Reproducible on demand:
Start-Service CoworkVMServicesucceeds and logs a clean start every time; triggering the sandbox kills it again. Three 7034s in one session (21:12:43, 21:26:42, 21:41:15).This is the same silent-death-plus-hang signature described in this issue, but it means the failure isn't only a mid-session stability problem — for users in this state Cowork never starts at all, and the missing recovery actions turn every single attempt into the "restart your computer" dead end.
Ruled out here
Reboots (4+), full app restart including tray exit, app Repair, app Reset, manual
Start-Service, and — tested specifically — Avira real-time protection disabled and NordVPN quit with its services force-stopped: the crash reproduces identically, so security software is not involved. Full uninstall/reinstall deliberately not attempted given #78873, where uninstall fails with0x80073D28on exactly this DACL-locked service.Happy to run any diagnostic that would help, including anything that could produce a dump of the service process at the moment it dies — as noted in this thread, it leaves none.
Correction to my comment above: I described the
sdsetworkaround as "confirmed working on this machine" — that was inaccurate. It was prepared as a script but never actually executed/verified on this machine. Apologies for the overstatement.@vsdtyf8h22-cmd's finding is important:
OpenService FAILED 5from an elevated PowerShell, with no ACE forSY/Administrators on their DACL either, means the "elevated admin token bypasses the packaged-service restriction" explanation I gave doesn't hold in general. Retracting that claim — the localsdset/sc failuremitigation is not reliable, and fix (a) (arming recovery from the installer) looks like the only path that's guaranteed to work.