[BUG] Claude Desktop (Windows) crashes during self-update while sessions are active, then fails to relaunch

Independent confirmation on two separate machines. Attaching the cowork-service.log you offered, since I have it from the same failure.

Environment

• Windows 11 Pro, 10.0.26200, x64
• Package Claude_1.44121.2.0_x64__pzs8sxrjxfjjc, SignatureKind Developer
• Service CoworkVMService, StartType Automatic, binary ...\app\resources\cowork-svc.exe
• Bundled Claude Code 2.1.258

My failure was on the same target version as your second transition — the locked path named in my dialog was Claude_1.44121.2.0_....

The Access is denied is not environment-specific

CoworkVMService logs this on every stop and start, not only during servicing:

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.

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

Consistent with the service account lacking SERVICE_CHANGE_CONFIG on its own SCM entry.

Worth flagging: my machines are corporate-managed under a least-privilege policy, and yours appears not to be, yet both log the same failure. So this does not look like a locked-down-machine edge case — the service seems unable to modify its own SCM configuration under normal conditions, and the warning it emits is describing a defect that is always armed. Servicing is simply when it becomes visible.

Service returns 56 seconds after being stopped

From C:\ProgramData\Claude\Logs\cowork-service.log (trimmed copy attached):

17:31:06.261832 Service stop requested
17:31:06.262340 Shutdown signal received...
17:31:06.289915 Service stopped.
17:32:02.355706 Starting CoworkVMService as Windows service
17:32:04.352541 Service ready. Listening on \\.\pipe\cowork-vm-service
17:32:04.354660 Warning: failed to configure recovery actions
    (a crashed service will stay down until reboot): open service: Access is denied.

It re-opens its named pipe and re-binds to the package directory it was just asked to release.

Repeated servicing attempts

Application event log, provider CoworkVMService. Four full stop/start cycles in seven minutes:

2026-09-02 17:26:12  disarm failed, service stopped
2026-09-02 17:27:33  disarm failed, service stopped
2026-09-02 17:27:45  disarm failed, service stopped
2026-09-02 17:27:57  disarm failed, service stopped
2026-09-02 17:32:02  service starting
2026-09-02 17:32:04  configure failed

An earlier cluster on 2026-09-01 at 19:46 and 20:53–20:56 shows the same pattern.

Worth noting: this is not a crash

On my machine there was no fault at all:

• %APPDATA%\Claude\Crashpad\reports is empty.
• No Application event log Event ID 1000 for Claude.exe in the prior 7 days.

The process termination is initiated by Windows for servicing, which matches the TerminateApplications / ForceApplicationShutdownOption events in your log.

Orphaned child processes

While running, the app has ~14 claude.exe processes, all children of one Electron main process. Twelve run from the WindowsApps package directory; two run from %APPDATA%\Claude\claude-code\<version>\claude.exe, the bundled Claude Code CLI backing the Code tab.

Those CLI children are what blocked Windows shutdown for me and forced the reboot. This overlaps with the orphaned-child behavior in #91662, which you already noted as related but distinct — agreed, that one has no servicing component.

This may also bear on your question about whether ForceApplicationShutdownOption should have succeeded. TerminateApplications reports success against the package's own processes, but the CLI children run from %APPDATA%\Claude\claude-code\<version>\, outside the package. They would not be covered by package-scoped termination, and they survive.

A reboot is not actually required

Killing the leftovers is enough to recover:

taskkill /F /IM claude.exe

Then relaunch and let the update install. This avoided the reboot on the second occurrence for me.

Suggested direction

• Treat OpenService returning Access is denied as a hard condition rather than a warning — the code path already logs the exact consequence that then occurs.
• Consider declaring SCM recovery actions in the package manifest at install time instead of configuring them at runtime, removing the need for the privilege on every start.
• Ensure the service releases all handles under the package directory before acknowledging SERVICE_CONTROL_STOP, so a restart cannot hold the swap open.
• Consider terminating the Claude Code CLI child processes explicitly during servicing shutdown, so no descendant survives to block a Windows restart.

cowork-service-trimmed-20260901-onward.log

Same failure here (Windows 11 Enterprise 26100, Claude_pzs8sxrjxfjjc, 1.40609.1 → 1.44121.2 on 2026-09-03, and 1.40609.0 → 1.40609.1 on 09-01), including the RepairAppRegistrationOption / event 649 "Register next time should succeed" loop and SCM 7034 you describe, with the app writing nothing to main.log on any launch attempt until a reboot.

I've posted the full timeline and redacted log extracts on #89680 rather than duplicating them here — that thread has the root-cause analysis for this signature: the launch failure is AppModel-Runtime 215/208 0x80070020 ("error encountered converting the job"), caused by the previous version's container silo still having its registry hives mounted, not by a surviving named process. That also answers your third question: @bugale's NtUnloadKey2 force-unload of the stale \REGISTRY\WC\Silo* Claude mounts recovers it in place without a reboot, and @J3TH4CK's sign-out recipe works if the MSIX StartupTask is disabled first.

One data point relevant to your second question about prompt-vs-force: on my machine the force path is taken by the app itself, not by Windows — main.log logs [stealth-update] Triggering stealth update after idle timeout followed by beforeQuitForUpdate, and in my case that "idle timeout" fired while a Cowork remote-tools session was still holding keep-awake. So the trigger is an app-side idle heuristic that doesn't account for active sessions or in-flight responses, which matches your experience of it firing under six live Claude Code sessions.

Follow-up: recurrence on 1.52386.3.0, plus a second, separable failure mode

Short answer to your question 3 first — yes, there is a way to clear the unrelaunchable state without rebooting: sign out of Windows and sign back in. Verified here 2026-09-12 with the machine never rebooted (uptime held at 878 minutes across the whole incident). Details in section 3 below, including why a reboot has been necessary up to now and what the dialog is actually reporting. @fritzschlechter — this may save you the reboot too.

Recurred on this machine 2026-09-11 into 09-12. Two things worth adding: a much cleaner diagnostic for the original failure, and a second failure mode that wears the same dialog but is not a file lock at all. Fixing the first one did not make the app launch.

Environment

• Windows 11 Pro, 10.0.26200, x64
• Package Claude_1.52386.3.0_x64__pzs8sxrjxfjjc, SignatureKind Developer
• Previous occurrence on this machine was 1.44121.2.0
• Service CoworkVMService, StartType Automatic, binary ...\app\resources\cowork-svc.exe
• Corporate-managed, least-privilege

---

1. A cleaner diagnostic: AppX Event 658

Microsoft-Windows-AppXDeploymentServer/Operational logs this at the moment the update gets stuck:

Event 658, Warning, 2026-09-11 16:42:44
Marking package {Claude_1.52386.3.0_x64__pzs8sxrjxfjjc} for deferred registration
because {Claude_1.52386.0.0_x64__pzs8sxrjxfjjc} is still running.

This is more useful than the service log for triage, because it names both packages explicitly — the new one waiting to register, and the old one whose surviving process is blocking it.

The update had already downloaded and staged successfully. It simply could not register. The dialog points at the new package path, which is misleading — people reasonably assume the new files are locked, when the actual blocker is a process still running out of the old package directory.

The corresponding success event, once it clears:

Event 400, 2026-09-11 23:53:52
Deployment Register operation with target volume C: on Package
Claude_1.52386.3.0_x64__pzs8sxrjxfjjc from: (AppxManifest.xml) finished successfully.

Suggestion: if the app detects its own update has been pending unusually long, surfacing "waiting for a previous version to exit" rather than a Windows sharing-violation dialog would save a lot of misdirected effort.

---

2. Refinements to the workaround

Three corrections to what I posted previously.

sc stop CoworkVMService alone is sufficient. No need to kill app processes first.

Do not bother trying to disable the service first. I tried:

sc config CoworkVMService start= disabled

It silently fails even when elevated — Win32_Service still reported StartMode: Auto afterward. This is presumably the same missing SERVICE_CHANGE_CONFIG right that produces the open service: Access is denied warnings the service already logs. Worth flagging because it means an administrator cannot pre-emptively disarm the service by policy as a mitigation.

Registration completes on AppX's own schedule, not immediately. On this occurrence the service was stopped at ~23:50 and registration completed at 23:53:52 — roughly three minutes later, unattended. Relaunching during that window just reproduces the dialog and makes it look like the fix failed. Worth stating explicitly in any docs or messaging.

---

3. Second failure mode: launch fails on container creation (0x80070020)

This is the part I think is new.

After registration completed successfully — package Status: Ok, only 1.52386.3.0 registered, old version gone, service binary resolving to the new path — the app still would not launch, with the identical dialog.

It is not a file lock. From Microsoft-Windows-AppModel-Runtime/Admin:

Event 215, Error: 0x80070020: Cannot create the Desktop AppX container for package
  Claude_1.52386.3.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.

Event 208, Error: 0x80070020: Cannot create the process for package
  Claude_1.52386.3.0_x64__pzs8sxrjxfjjc because an error was encountered while
  configuring runtime. [LaunchProcess]

Reproduced deliberately by launching via AUMID (shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude) with the log open:

00:09:12  Created Desktop AppX container {6484547C}                  SUCCESS
00:09:12  Added process 34940 to container                           SUCCESS
00:09:13  Cannot create container {64845481} - 0x80070020            FAIL
00:09:13  Cannot create container {64845482} - 0x80070020            FAIL
00:09:13  Destroyed containers, LaunchProcess failed

The sequence is the diagnosis:

• The first container is created and the main process starts fine.
• The subsequent containers fail — those are the renderer / GPU / utility children.
• The app then collapses entirely, leaving no process behind.

The package files are demonstrably not locked: a process was successfully added to a container in that same directory one second before the failure.

0x80070020 is ERROR_SHARING_VIOLATION, but on AssignProcessToJobObject it does not mean "file in use" — it indicates the process is already in a job object that will not accept nesting, which matches the "converting the job" wording. Windows maps the raw code to its generic file-sharing string, which is why the user-visible dialog is identical to the genuine file-lock case.

Process enumeration during the failure confirmed the only package process running was cowork-svc.exe (parent services.exe). No orphaned app processes.

Fix: signing out of Windows and signing back in clears it. A reboot is not required.

Verified 2026-09-12: new interactive logon at 00:15:41, machine not rebooted (uptime held at 878 minutes across the whole incident), app launched normally on the first attempt with a healthy 11-process Electron fan-out.

Since a session recycle is sufficient and the failure did not reappear in the fresh session, this looks like accumulated per-session job/container state rather than anything resident on the machine — plausibly a downstream consequence of servicing repeatedly creating and destroying containers during the stalled update. I'd treat that as a hypothesis rather than established; it's one observation.

---

4. Why this matters for triage

The two failures are separable and were present simultaneously:

• 16:42 — Mode A begins, update staged but deferred
• 23:50 — service stopped
• 23:53:52 — registration completes, package healthy
• 00:06–00:09 — Mode B, four failed launches
• 00:15:41 — sign out / sign in, app works

Repairing registration did not restore launchability, and the dialog is identical for both. Anyone following the existing workaround will fix Mode A, see the same dialog, and reasonably conclude the workaround does not work.

If it's useful, a one-line distinction:

• AppXDeploymentServer Event 658 → genuine lock, stop CoworkVMService, wait.
• AppModel-Runtime Event 215/208 with 0x80070020 → not a lock, sign out and back in.

Happy to attach the full cowork-service.log and the AppModel-Runtime export if either would help.