## Environment - Claude Desktop (Windows Store / MSIX): `1.24012.9.0` (confirmed latest via `winget upgrade` — no update available) - Windows 10.0.26200 - Service: `CoworkVMService` (display name "Claude"), backed by `cowork-svc.exe`, managing a Hyper-V VM ## Summary Over a single extended working session, the Cowork VM service tore down and had to cold-boot **5+ times**, each disrupting the active session for anywhere from a few seconds up to several minutes. After an overnight idle gap, recov

[BUG] Cowork VM service repeatedly tears down on idle; recovery is a slow cold-boot; service DACL blocks any external mitigation

Status Open

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 4 comments · opened Jul 28, 2026

Environment

Claude Desktop (Windows Store / MSIX): 1.24012.9.0 (confirmed latest via winget upgrade — no update available)
Windows 10.0.26200
Service: CoworkVMService (display name "Claude"), backed by cowork-svc.exe, managing a Hyper-V VM

Summary

Over a single extended working session, the Cowork VM service tore down and had to cold-boot 5+ times, each disrupting the active session for anywhere from a few seconds up to several minutes. After an overnight idle gap, recovery took long enough to read as a full crash rather than a restart.

What I found in the logs

C:\ProgramData\Claude\Logs\cowork-service.log shows a recurring pattern: the RPC connection to the app drops (Persistent RPC: connection ended: failed to read length: EOF), then — anywhere from seconds to ~7 minutes later — Service stop requested / Service stopped, followed by a restart. Sometimes the service also stopped and restarted twice within the same second, consistent with the app force-reinstalling/repairing the Windows service (Service Control Manager events 7040 "start type changed to disabled" immediately followed by 7045 "A service was installed", 2-3 times back to back).

Every single service start also logs:

Warning: failed to open service for recovery config: Access is denied.

i.e. the service can't even configure its own crash-recovery actions.

Root cause (confirmed, not guessed)

Ran sc sdshow CoworkVMService (read-only) and got:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-...)

Decoded: Authenticated Users get query/start/stop/pause rights only (no SERVICE_CHANGE_CONFIG, no WRITE_DAC). The only entity with full control (including SERVICE_CHANGE_CONFIG) is the service's own internal virtual account (NT SERVICE\CoworkVMService, the S-1-5-80-... SID).

Built-in Administrators are not in the DACL at all. Confirmed directly: sc failure CoworkVMService reset= 86400 actions= restart/5000/restart/5000/restart/10000 and sc config CoworkVMService start= delayed-auto both fail with Access is denied, even from an elevated (Run as Administrator) prompt.

This explains the "Access is denied" line above — no failure-recovery action is configured, and nothing outside the app itself is able to configure one. When the service dies unexpectedly (not via a clean stop), Windows has no auto-restart to fall back on; recovery depends entirely on the app noticing and re-triggering it, which is slow and, per the logs, sometimes involves a full service reinstall.

Impact

Frequent (5+ times in one extended session) multi-second-to-multi-minute interruptions to active Cowork sessions.
After any longer idle period (including overnight), recovery is a full cold-boot of the Hyper-V VM, which reads to the user as the app having crashed outright.
No user-side or admin-side workaround exists for the missing recovery config, since the DACL blocks it. The only usable mitigation found: sc stop CoworkVMService && sc start CoworkVMService (works without elevation, since AU has start/stop rights) — useful for a stuck state, but does nothing for the underlying idle-teardown-then-slow-restart cycle.

Ask

Either:

Grant the service's DACL SERVICE_CHANGE_CONFIG/SERVICE_START to BA (Builtin Administrators) or SY (Local System) so sc failure/sc config can actually be used to configure auto-recovery and a non-idle-killing startup type, or
Have the app itself configure SERVICE_CONFIG_FAILURE_ACTIONS on the service at install/first-run time (it clearly already has the rights to, via its own virtual account — the "Access is denied" warning suggests it's trying and failing, possibly using the wrong access mask/handle), or
At minimum, stop tearing the VM down fully on idle, or make the app's own restart-on-reconnect path faster than a full Hyper-V cold-boot.

Happy to provide the full log file or run further diagnostics if useful.

View original on GitHub ↗

4 Comments

red-pilledd · 1 month ago

Follow-up observation from continued use of the same session over ~24h: the disruption appears to be purely client-side/connection-layer, not a loss of actual backend execution.

Specifically: across 5+ of these idle-teardown/cold-boot cycles, the agent session and its in-progress work were never actually lost — on reconnect, the conversation resumed exactly where it left off, and any file/git-level work already in progress on disk was intact. What the user experiences as "it crashed before finishing" appears to be the local app UI losing its connection to the backend session (via the VM service cycling) rather than the backend task itself being killed or restarted.

If that's an accurate characterization, it suggests the actual fix surface is narrower than "the VM crashed and lost work" — it's specifically: local app reconnection to an already-fine backend session is slow/disruptive when CoworkVMService cycles, even though the session it's reconnecting to hasn't itself failed. Might be a smaller/different fix than a full service-recovery fix (e.g., faster/more resilient client-side reconnect logic vs. fixing the VM service's own recovery config).

red-pilledd · 1 month ago

Second, distinct observation from continued use — this one seems more specific than the general idle-teardown pattern above, and possibly a separate bug sharing the same "recovery is disruptive" symptom.

Reproducible crash tied to a specific external site, isolated to the sandboxed browser pane. Navigating the built-in browser pane to one particular external URL (a low-value "crypto testnet faucet" site — the kind of site that's often ad-network-heavy or carries malvertising, notably targeting an audience that obviously has a crypto wallet in-hand) reliably triggered a crash/disruption 3 out of 3 attempts, on a day when nothing else in a long session had caused any issue. It was not intermittent or timing-dependent like the idle-teardown pattern — it correlated specifically with loading that one page.

I don't have a crash dump or console output to attach (wasn't captured at the time), so this is behavioral evidence rather than a root-cause diagnosis. But given how reproducible and site-specific it was, it's worth considering separately from the idle-teardown issue above: possibly the sandboxed browser pane's renderer is more fragile against heavy/hostile external content (ad networks, redirect chains, anti-bot/fingerprinting scripts, possible malvertising) than a normal desktop browser would be, and a crash there is being surfaced to the user the same way the VM-idle-teardown issue is (as "the app crashed"), even though the trigger and likely fix are probably unrelated to VM service recovery config.

Flagging in case it's useful to know these are probably two different bugs wearing the same "app crashed" symptom, not one bug with two triggers.

level1noob69 · 5 days ago

Confirming this on a second machine, and correcting one detail in the root-cause section that I think matters for fix option 2.

The SID with SERVICE_CHANGE_CONFIG is not the service's own account — it's NT SERVICE\AppXSvc.

The issue reads it as "the service's own internal virtual account (NT SERVICE\CoworkVMService)". Resolving both SIDs separately:

DACL ACE #2 : S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604
              -> NT SERVICE\AppXSvc

sc showsid CoworkVMService
              -> S-1-5-80-690231842-763816591-443537665-320658410-1005583601

Different SIDs. The service's own SID does not appear in the DACL at all.

And the service does not run under that virtual account anyway:

> sc qc CoworkVMService
        SERVICE_START_NAME : LocalSystem

LocalSystem has no ACE either — the only two entries are AU (no DC) and AppXSvc.

Why that changes fix option 2. The issue suggests the app "clearly already has the rights, via its own virtual account — the Access is denied warning suggests it's trying and failing, possibly using the wrong access mask/handle." I don't think it's an access-mask bug. The runtime call is made by the service as LocalSystem, which matches no ACE granting SERVICE_CHANGE_CONFIG, so ChangeServiceConfig2(SERVICE_CONFIG_FAILURE_ACTIONS) can never succeed with this security descriptor regardless of how it's called. Fixing it at runtime would require adding an ACE (option 1); otherwise the failure actions have to be set declaratively at package-deployment time, which is the one context where AppXSvc actually holds the rights.

Second data point — this is still live and it does escalate to an unopenable app.

Package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc, Claude Code 2.1.240, Windows 11 Pro 10.0.26200. On 2026-08-26 the same warning preceded a crash that left the app unable to start:

01:04:44  System/7034      The Claude service terminated unexpectedly
01:05:10  Application/1002 conhost.exe stopped interacting with Windows and was closed
01:05:10  System/7040      start type changed: auto start -> DISABLED
01:05:10  System/7045      A service was installed in the system
01:05:11  7040 / 7045      disabled / installed  (again)
01:05:26  7040 / 7045      disabled / installed  (again)
01:05:41  7040 / 7045      disabled / installed  (again)
01:06:11  System/7034      The Claude service terminated unexpectedly
01:06:15  Application/1    service starts, logs the same recovery warning again

Four 7040→7045 cycles in 31 seconds. Recovery required Settings → Apps → Claude → Repair; the app would not start before that. Post-repair, sc qfailure CoworkVMService still shows RESET_PERIOD : 0 with no actions, and the warning is still logged on every start — so the machine is in exactly the same state, waiting for the next crash.

Worth noting #89266 reports the same warning firing on 31 of the last 60 days, which suggests this isn't rare.

krisfarrant · 3 days ago

Confirming this is still live and getting worse — independent occurrence tonight, different machine, same signature.

Environment: Claude Desktop 1.37937.3.0, Windows 10, CoworkVMService/cowork-svc.exe.

10 crashes in 37 minutes (00:52–01:29), confirmed via Get-WinEvent for SCM event 7034 ("The Claude service terminated unexpectedly"):

00:52:44, 01:04:01, 01:06:38, 01:11:41, 01:17:07,
01:18:55, 01:22:13, 01:25:09, 01:28:01, 01:29:41

Gap between crashes shrank through the session — ~10 min apart early on, down to ~2–3 min by the end.

Same recovery-config failure on every start:

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

Independently confirmed the DACL block from this end too: sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/restart/5000/restart/5000 from an elevated (Run as Administrator) PowerShell fails with OpenService FAILED 5: Access is denied — matches the sc sdshow finding above exactly.

Ruled out on this machine, confirmed not guessed: system RAM (48–51 GB free of 64 GB throughout), pagefile (0 used), an oversized chat (active chats were 364 KB / 4.3 MB at time of crash), Windows Update (no update process running, no WU history in prior 2 hours), the app auto-updating (version stable 2 days), and heavy usage (one crash happened during plain conversation, no tool calls running).

Also confirmed this isn't new — one earlier crash of the same service on this machine on 2026-08-20, but only once that day. Tonight is the first time it's clustered like this.

+1 on option 2 or 3 from the original report — the idle-teardown-then-cold-boot cycle is the part actually causing user-visible "Claude crashed," and it's the one part fixable without touching the DACL.