[BUG] Windows auto-update deploys into running claude.exe + CoworkVMService (0x80073CF9/0x80073D02), app left unlaunchable (NeedsRemediation); recovery churn incl. dev-only PreserveApplicationData (0x80073CFA) — twice in one day

[DonSmirelo]

Summary

Windows auto-update deployments run while the app (claude.exe) and the packaged service CoworkVMService (cowork-svc.exe) are still running, and fail: 0x80073CF9 with inner 0x80070020 (ERROR_SHARING_VIOLATION) on cowork-svc.exe, or 0x80073D02 ("the following apps must be closed"). To the user this looks like Claude suddenly crashed mid-session, after which the app never launches again (no window, no error). What follows in the log is recovery churn: register attempts that "succeed" at the AppX layer without producing a launchable app, repair attempts that race the very processes they're repairing, and — in both incidents — an identical removal attempt with PreserveApplicationData, which is dev-mode-only and guaranteed to fail with 0x80073CFA on a store-signed package.

This hit the same machine twice within one day (2026-08-04, ~01:14 and ~22:52 local). Both times the app was down for 10+ minutes and needed assisted recovery.

Environment

• Windows 10 Pro 10.0.19045 x64, Russian locale (log excerpts translated; codes/paths/options verbatim)
• Claude Desktop MSIX, package family Claude_pzs8sxrjxfjjc
• Update path: 1.24012.11.0 → 1.25927.0.0, payload https://downloads.claude.ai/releases/win32/x64/1.25927.0/Claude-003700efafbc2ccb4b1177a5e637b14da381799e.msix

All excerpts are from Microsoft-Windows-AppXDeploymentServer/Operational, times local. The log records operations, options and outcomes but not the initiating process, so per-attempt attribution (updater retry logic vs. Windows repair vs. our assisted recovery) is inference; your updater telemetry can correlate.

Incident 1 — 2026-08-04 01:14–01:26: repair/re-add of the running version

01:14:10 #603/#638/#401/#404  RegisterByPackageFullName (RepairAppRegistration) of 1.24012.11.0
                              → 0x80073D02 — blocked by the running app it is repairing
01:15:16 #603/#717/#404 (x2)  Remove 1.24012.11.0, first with PreserveApplicationData,RemoveForAllUsers,
                              then PreserveApplicationData alone → 0x80073CFA both times
                              ("flag allowed only for packages deployed in development mode")
01:15:16 #603  Add of 1.24012.11.0 (Claude-2908984492.msix), options:
               ForceApplicationShutdownOption,ForceUpdateFromAnyVersion
01:15:18 #462  Error 0x80070020: failed to create file
               \\?\C:\Program Files\WindowsApps\Claude_1.24012.11.0_...\app\resources\cowork-svc.exe
01:15:18 #605  Last successful state: PreStagePackagesInUseClosed. Failed before reaching: Staged.
01:15:18 #404  → 0x80073CF9 (inner 0x80070020)
01:19:49       identical Add failure, payload Claude-279551963.msix
01:25:23 #404  Add retry → 0x80070005 (failed to open package location)
01:26:03 #603  Add of 1.24012.11.0 (same Force options) — after lingering processes/service
               were stopped out-of-band
01:26:19 #646/#400  running app terminated for servicing; Add completed successfully (16 s)

Sharp edge here: the failing Adds at 01:15/01:19 did request ForceApplicationShutdownOption, yet still died on a sharing violation — same-version re-staging writes into the live package folder (#605: between PreStagePackagesInUseClosed and Staged) before the shutdown machinery terminates the service that holds cowork-svc.exe.

Incident 2 — 2026-08-04 22:08–23:12: deferred update commits into lingering processes, then churn

22:08:28–42 #603/#638/#400  Add 1.25927.0.0 (DeferRegistrationWhenPackagesAreInUse) → staged OK,
                            registration deferred, app still running   [normal designed flow]
22:18:37–38                 same deferred Add again (cached, 734 ms)
22:52:59 #638/#401/#404     deferred Register fires → 0x80073D02 — blocked by running 1.24012.11.0
22:58:48–59:19 #603/#646/#9648/#400  RegisterByPackageFamilyName (ForceApplicationShutdownOption):
                            app terminated, CoworkVMService terminated → Register SUCCESS (31 s)
                            — but no durably working app followed; churn continues:
23:06:21–22 #603/#638/#404  RegisterByPackageFullName (RepairAppRegistration) → 0x80073D02 —
                            blocked by the now-running 1.25927.0.0 itself
23:08:20 #400               Register SUCCESS (219 ms)
23:09:11 #603/#9648/#400    RepairAppRegistration + TerminateSingleService(CoworkVMService) →
                            Register SUCCESS (203 ms) — still no working app
23:10:44 #603/#717/#404(x2) Remove 1.25927.0.0 with PreserveApplicationData(,RemoveForAllUsers) →
                            0x80073CFA — same dev-mode-only dead end as incident 1
23:10:44–51 #603/#9648/#400 Add of OLD 1.24012.11.0 (Claude-817307799.msix, Force options) →
                            SUCCESS — temporary downgrade to the previous version
23:11:30–39 #603/#638/#400  Add 1.25927.0.0 fetched fresh from downloads.claude.ai (Defer...InUse)
                            → staged OK, deferred (blocker: 1.24012.11.0 now running again)
23:12:13–44 #603/#646/#9648/#400  RegisterByPackageFamilyName (ForceApplicationShutdownOption):
                            app + CoworkVMService terminated → Register 1.25927.0.0 SUCCESS (31 s),
                            1.24012.11.0 moved to \WindowsApps\Deleted

The 23:12:44 result held: Get-AppxPackage now reports 1.25927.0.0, Status: Ok, CoworkVMService runs from the new package folder, app healthy. During the broken window Get-AppxPackage showed the package as Modified, NeedsRemediation (observed live during recovery, not preserved in a transcript; identical signature to #83893).

Observations

1. The deferred-registration flow commits into lingering processes. The designed path (Add + DeferRegistrationWhenPackagesAreInUse) staged fine at 22:08, but the deferred Register at 22:52:59 ran while claude.exe/cowork-svc.exe still lived → 0x80073D02. Window closed ≠ processes exited.
2. Same-version repair Add races its own service at staging time, before force-shutdown applies → 0x80073CF9/0x80070020 on cowork-svc.exe (incident 1). Force flags don't help there.
3. RepairAppRegistration is blocked by the app it repairs (01:14:10, 23:06:21) → 0x80073D02.
4. AppX-layer "success" ≠ working app. Three registrations reported #400 completed successfully (22:59:19, 23:08:20, 23:09:11) with no launchable app afterwards — churn continued for another ~13 minutes. Nothing verifies end-to-end health before declaring the update done.
5. PreserveApplicationData removal is a scripted-looking dead end that fired in both incidents (01:15:16 and 23:10:44, both times as a pair: with RemoveForAllUsers, then without). The flag is dev-mode-only, so it fails with 0x80073CFA on the store-signed package every time. Whatever issues it (updater rollback logic or recovery tooling — the log doesn't name the caller), "remove but keep user data" is not available as a rollback path for this package.
6. No automatic recovery to a working state. The package sat in Modified, NeedsRemediation until an out-of-band sequence (temporary downgrade to 1.24012.11.0, fresh payload re-download, defer-Add + force-shutdown Register) landed the update. Why the 23:12:44 attempt held while the 22:59:19 one (same options, same duration) did not is not decidable from this log — flagging for whoever owns the updater's state machine.

Suggested fix

1. Before the deferred Register commits: enumerate active AUMIDs, gracefully close the GUI, stop CoworkVMService, and wait for cowork-svc.exe/claude.exe to actually exit (no open handles into the package folder) — don't rely on window-close as a proxy.
2. Treat 0x80070020 / 0x80073D02 as retryable: re-stop processes, retry registration; don't abandon the package in NeedsRemediation.
3. After Register reports success, verify end-to-end (app activates, service starts from the new folder, package Status == Ok) before considering the update finished — that's the gap behind observation 4.
4. Drop PreserveApplicationData from any removal path for the store-signed package (0x80073CFA is unconditional there); user data survives normal in-place update anyway.
5. If the new version can't reach a verified-working state, roll back to the previous version automatically — the 23:10:51 downgrade shows the mechanics work.
6. Start CoworkVMService / relaunch the app only after the AppX operation has committed.

User impact

The failed update presents as an out-of-the-blue crash; afterwards the app simply never opens — no window, no error, shortcut present. Messages typed into the dead window are lost. User data survives on disk, but recovery requires AppX/service surgery far beyond a typical user. Twice in one day on this machine.

Related

Same lock/race cluster: #73694, #81756, #80502, #82494, #81267, #83893, #78873. This report adds a detailed two-incident same-day timeline from AppXDeploymentServer/Operational, the repeated dev-mode-only PreserveApplicationData rollback dead end (0x80073CFA), and the "AppX success without a working app" churn pattern.

[DonSmirelo]

Update — root cause on this machine identified: every AppX/update failure above was preceded by the same Electron GPU-process crash. The package corruption is a cascade, not the origin.

main.log (survived the recovery reinstalls) shows the identical GPU crash immediately before all three incidents:

2026-08-04 01:12:35  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }  → AppX churn from 01:14:10 (incident 1)
2026-08-04 23:06:06  GPU process gone: { …same, exitCode: 101457950 }                           → repair churn from 23:06:21 (incident 2)
2026-08-05 00:06:00  GPU process gone: { …same, exitCode: 101457950 }                           → repair churn from 00:08:50 (incident 3, new)

Same exitCode 101457950 (0x060C201E) every time — deterministic. Crashpad minidump from the 00:06:00 crash (fields extracted before the recovery reinstall cleaned the report): exception 0x80000003 (breakpoint/assertion, not an access violation), crash module claude.exe, module offset 0x6DD36F9, Electron 42.7.0. Not OOM (~12.5 GB system RAM free; GPU process RSS ~142 MB). Dual-GPU machine: NVIDIA RTX 4070 (driver 32.0.16.1047) + Intel UHD 770 (32.0.101.6129).

Trigger: reopening/continuing one specific local session whose agent uses the in-app Browser Preview on nexusmods.com. The session recreates its preview context → GPU process dies ~5 s later (00:05:55 Created browser preview → 00:06:00 GPU process gone). Reproduced twice on different days with that session; other sessions run 30+ min without issues. Per the session transcript, at crash time the preview was sitting on the Cloudflare challenge interstitial in front of nexusmods.com (the agent's last message: waiting for the check to pass), so the challenge page (Turnstile/canvas fingerprinting) — not necessarily Nexus content itself — is the likely crashing content.

Corrected sequence for this machine:

1. GPU crash takes down the window; background claude.exe utility processes + CoworkVMService survive.
2. ~2–3 min later RegisterByPackageFullName (RepairAppRegistration) fires → 0x80073D02 (blocked by the survivors) → Modified, NeedsRemediation → the churn documented above — including the dev-mode-only PreserveApplicationData removal (0x80073CFA) for the third time at 00:18:29, same double pattern.
3. The 04.08 evening incident interleaves both bugs: the deferred 1.25927 update force-registered at 22:59:19 (AppX "success"), the app relaunched, restored the poisoned session, GPU-crashed at 23:06:06 → repair churn. That is why AppX-layer register "success" never produced a working app (observation 4 in the original report).

So suggested-fix items 1 and 3–6 stand, and the operative additions are: isolate Browser Preview / GPU-process crashes so they can't take down the main window, and after child-process-gone, don't start AppX repair until every package process (incl. CoworkVMService) has actually exited.

Mitigation applied here: "isHardwareAccelerationDisabled": true (maps to app.disableHardwareAcceleration()). Machine restored to 1.24012.11.0, Status: Ok; 1.25927.0.0 is staged with DeferRegistrationWhenPackagesAreInUse and should complete on a later restart. Will report whether the crash reproduces with HW acceleration off. (The built-in auto-disable after 3 GPU crashes per session presumably never engages because each crash ends the session.)

Likely related: #81123 (browser preview GPU crash → Modified/NeedsRemediation), #83016 (WebFetch content crash corrupting install), #83028 (Intel iGPU browser-pane crash).

[yadonpapa]

Another reproduction on Windows 11 Pro (26200) — with a recovery sequence that worked first try

I hit what appears to be the same bug. Adding my timeline and the recovery
sequence that worked, in case it helps.

Environment

• Windows 11 Pro 10.0.26200 x64, Japanese locale
• Claude Desktop MSIX, package family Claude_pzs8sxrjxfjjc
• Versions involved: 1.25927.0.0 (initially broken) → 1.26832.0.0
• Windows Defender only (no third-party EDR). Reproduced on two different
  networks (corporate guest Wi-Fi and phone tethering), so network
  interception is ruled out on my side.

Symptoms

• App suddenly stopped launching around Aug 4–5. Windows showed the generic
  "repair this app from advanced options" dialog; Settings → Repair failed
  ("Couldn't repair this app").
• Get-AppxPackage showed Status: Modified, NeedsRemediation for
  1.25927.0.0.
• Clean reinstall attempts: the installer log showed
  MSIX package installed successfully / exit code 0, then on first
  launch the app window (at the human-verification step) silently
  disappeared — no error dialog, no Event ID 1000 crash record — and the
  freshly installed 1.26832.0.0 package was immediately back in
  Modified, NeedsRemediation. Matches the "AppX success without a working
  app" churn pattern in the OP.
• Re-running the installer against the broken package then failed with
  0x80073CF9. The installer also logged
  WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied. (even elevated), and
  0x80073CFA (requires developer mode) on the data-preserving removal —
  same dev-mode dead end as the OP.
• During the broken state, cowork-svc.exe (CoworkVMService) was still
  RUNNING from inside the broken package folder, holding files.

What did NOT work

• Settings → Repair
• Add-AppxPackage -Register <AppxManifest.xml> -DisableDevelopmentMode
  (both with the service running and after stopping it) — command succeeds,
  Status stays Modified, NeedsRemediation

Recovery sequence that worked (first try), elevated PowerShell

1. sc.exe stop CoworkVMService and confirm no processes remain under
   C:\Program Files\WindowsApps\Claude*
2. Get-AppxPackage -AllUsers -Name Claude | Remove-AppxPackage -AllUsers
3. Verify both Get-AppxPackage -AllUsers -Name Claude and the
   WindowsApps\Claude* folder are gone
4. Run the downloaded installer as administrator immediately
5. Complete the human-verification/login promptly on first launch
6. Get-AppxPackage -Name Claude → Status: Ok, app healthy since

Happy to provide ClaudeSetup.log excerpts or
AppXDeploymentServer/Operational events if useful.

[KieranPhang]

Confirming this on another machine, with two additions: the terminal failure mode was the MSIX activation error ("There's a problem with Claude. Reinstall the application from its original install location or contact your administrator."), and the trigger was the outgoing version hanging on quit (MoAppHang) while the updater retried registration against it.

Environment: Windows 10 Pro 10.0.19045 x64, en-US, Windows Defender only. Package family Claude_pzs8sxrjxfjjc, SignatureKind Developer. Update path 1.25927.0.0 -> 1.26832.0.0.

Timeline, 2026-08-06 (Microsoft-Windows-AppXDeploymentServer/Operational + WER):

• 21:34:41 - Event 658: 1.26832.0.0 marked for deferred registration because 1.25927.0.0 is running
• 22:26:46 - Events 404/658: deployment of 1.26832.0.0 fails 0x80073D02 ("apps need to be closed"), deferred again
• 23:38:48-23:39:37 - Events 401/404 repeating: Register operation for 1.25927.0.0 fails 0x80073D02 multiple times within one minute
• 23:42:19 - WER MoAppHang: claude.exe 1.25927.0.0, hang type Quiesce (unresponsive during close), hang signature 4185
• Next launch: "There's a problem with Claude. Reinstall the application..." Full reinstall required.

Prior incidents, same machine: 2026-07-09 (0x80073D02, 1.20186.0.0 over running 1.19367.0.0), 2026-07-14 (0x8007001F, 1.21459.0.0), 2026-07-30 (0x80070020 creating app\resources\cowork-svc.exe in the 1.24012.9.0 package, plus 0x80073CFA PreserveApplicationData rejected outside dev mode, matching the cowork-svc.exe locking above).

Crashpad/reports was empty after each incident, so no minidumps; the AppX event log is the only surviving evidence. Second unlaunchable-after-update in two weeks on this machine, both resolved only by full reinstall.

[yadonpapa]

Follow-up: event log confirms the identical sequence to Incident 1

Following up on my earlier comment — I've since pulled AppXDeploymentServer/Operational from the affected machine. The initial break on my side is 2026-08-05 18:04–18:09 JST, and the event-ID / error-code sequence matches Incident 1 in the OP exactly (log excerpts translated from Japanese; codes/paths/options verbatim):

18:04:03–09  #603 → ... → #400  Add of 1.25927.0.0 completed successfully —
                                but no durably working app followed (same
                                "AppX success without a working app" as
                                observation 4)
18:06:24  #603/#717/#404 (x2)   Remove 1.25927.0.0 with
                                PreserveApplicationData,RemoveForAllUsers then
                                PreserveApplicationData alone → 0x80073CFA
                                both times (dev-mode-only) — same
                                scripted-looking pair as both incidents in
                                the OP
18:06:24  #603  Add of 1.25927.0.0 (Claude-2472190688.msix), options:
                ForceApplicationShutdownOption,ForceUpdateFromAnyVersion
18:06:24  #462  Error 0x80070020: failed to create file
                \\?\C:\Program Files\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
18:06:24  #605  0x80070020 in Staged state handler;
          #613  "Failed to reach state Staged"
18:06:24  #404  → 0x80073CF9 (inner 0x80070020)
18:08:48        identical failure sequence repeated (2nd attempt)

Point-by-point match with Incident 1: the dev-mode-only PreserveApplicationData removal pair (0x80073CFA, with RemoveForAllUsers then without), the same-version force Add racing its own service, the sharing violation (0x80070020) on exactly cowork-svc.exe during staging, and the final 0x80073CF9. This is on Windows 11 Pro 10.0.26200, vs. Windows 10 Pro 19045 in the OP, so the race is not specific to a Windows version.

I have the exported .evtx and text extracts saved and can attach them if useful.

[FFGCPA]

Same failure mode here, with two things this thread is missing: the 658 deferred-registration event that names the mechanism, and a recovery that actually holds without out-of-band intervention.

Environment: Windows 11 Pro 26200, Claude Desktop MSIX (Claude_..._x64__pzs8sxrjxfjjc), near-daily failures 2026-07-27 through 2026-08-07.

The event that names the mechanism

Microsoft-Windows-AppXDeploymentServer/Operational:

8/7 12:23:52 AM  ID 658   Marking package {Claude_1.26832.0.0_x64__pzs8sxrjxfjjc} for deferred
                          registration because {Claude_1.25927.0.0_x64__pzs8sxrjxfjjc} is still running.
8/6 11:00:01 AM  ID 419   error 0x80073D02: Unable to install because the following apps need
                          to be closed Claude_1.24012.9.0_x64__pzs8sxrjxfjjc.
8/6 11:00:01 AM  ID 666   For repair of package Claude_1.24012.9.0: Register operation finished
                          with result 0x80073D02 (step 2 of 2).
8/6 11:00:01 AM  ID 613   Performance summary ... Failed to reach state ResolvedDeferredRegistrations

Failure counts by day: 8/5 → 16, 8/6 → 8, 8/7 → 2.

CoworkVMService is not the blocker

This thread and adjacent ones point at cowork-svc.exe. In my logs the installer terminates it cleanly on every attempt:

ID 9650  0x0: Succesfully terminated service Claude_1.25927.0.0_x64__pzs8sxrjxfjjc in package CoworkVMService.
ID 9648  0x0: TerminateSingleService for update successful ... terminateService: true.

The process named in 419/658 is claude.exe itself. Stopping the service is not the load-bearing step — -ForceApplicationShutdown is. Worth separating, since "stop the service first" advice is circulating and doesn't address the actual lock holder.

User-visible impact is two symptoms, one event

The 12:23 AM timestamp lands mid-run on an unattended overnight job. The update terminated the running app, so the job died silently, and the package was left wedged by morning. These read as two unrelated bugs ("it crashed overnight" and "it won't open") but they are one deployment event. Anyone triaging the overnight-crash reports separately is chasing a ghost.

Recovery that holds (no manual intervention)

Scheduled task, AtLogOn, RunLevel Highest. Detached from the Claude process tree, so it isn't itself killed by the shutdown it triggers. Guarded so it no-ops on healthy days:

$p = (Get-AppxPackage *laude* -AllUsers | Where-Object Status -ne 'Ok').PackageFullName
$busy = Get-Process claude* -ErrorAction SilentlyContinue
if ($p -and -not $busy) {
    Add-AppxPackage -Register "C:\Program Files\WindowsApps\$p\AppxManifest.xml" -DisableDevelopmentMode
}

Pulls the wedged package name dynamically, so it survives whatever version breaks next. ~10 seconds, no reboot, no re-download, no downgrade. Contrast with the recovery in the original report (temp downgrade + fresh re-download + force Register).

Prevention, until this is fixed upstream

Disabling Microsoft Store auto-update removes the ambush window entirely:

New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\WindowsStore' `
  -Name AutoDownload -Value 2 -PropertyType DWord -Force

Corroborating detail: the same 0x80073D02 hit an unrelated Store package on this machine the same morning (ID 20 Installation Failure ... 0x80073D02: 9WZDNCRD29V9-MICROSOFT.MICROSOFTOFFICEHUB). The collision is Store-auto-update-driven, not unique to Claude — but Claude's release cadence plus a long-running desktop session makes it a near-daily hit rather than an occasional one.

The ask

Reiterating the suggestion already in this thread, with the 658 evidence behind it: wait for actual process exit before committing the deferred registration, and verify Status -eq 'Ok' end-to-end after Register rather than trusting #400 completed successfully — I have three #400 ... finished successfully entries against packages that produced no launchable app.

Related: #63397 documents the identical 658 + 0x80073D02 sequence and was closed as invalid / out-of-scope. If Claude Desktop MSIX deployment isn't tracked in this repo, it would help to say where it is — the reports are going to keep arriving here otherwise.

[Toddxiong]

I also encountered the same problem. Now it is completely impossible to start claude code desktop

[DonSmirelo]

Stability update from the original machine — 4 days since the mitigation, zero recurrences, two clean auto-updates. The cascade thesis holds.

Since setting "isHardwareAccelerationDisabled": true on 2026-08-05 (right after incident 3):

• Zero GPU-process crashes across all main*.log since 2026-08-05 00:06 (before that: three in 24 h, all exitCode 101457950).
• Zero AppX deployment errors in AppXDeploymentServer/Operational — no 0x80073D02, no NeedsRemediation, no repair churn.
• Two auto-updates completed cleanly via the normal deferred flow, on the very machine where that flow ended in a bricked package three times:
  • 1.25927.0.0 — deferred Add → Register 2026-08-05 01:33 (ForceApplicationShutdownOption + TerminateSingleService for CoworkVMService → #400 success); ran fine for 3 days.
  • 1.26832.0.0 — deferred Add 2026-08-07 23:18 (app running) → Register 2026-08-08 00:22 → Status: Ok, running now.

With the GPU crash suppressed, the defer-and-register update flow works repeatedly here. That cleanly separates the two defects in this thread:

1. the Browser Preview GPU crash (deterministic 0x80000003 at claude.exe+0x6DD36F9; trigger content in our case: the Cloudflare interstitial on nexusmods.com) — mitigated by disabling HW acceleration;
2. the servicing/repair path racing surviving package processes after such a crash (0x80073D02 → Modified, NeedsRemediation, no automatic rollback) — not reproducible here while (1) is suppressed.

Workaround that is holding up, for anyone stuck in this loop: quit Claude, set "isHardwareAccelerationDisabled": true in %APPDATA%\Claude\config.json, recover the package (re-running the signed installer worked here), and don't resume the session that had the crashing preview until the flag is set. Four days of daily use without a recurrence.

(Thanks @yadonpapa, @KieranPhang, @FFGCPA for the confirmations — the event sequences you posted match ours.)

[DonSmirelo]

Correction + incident 4 (2026-08-12): the crash reproduces WITH hardware acceleration disabled. The workaround in my Aug 8 comment does NOT prevent it. Full minidump preserved this time.

At 2026-08-12 01:02 local, a different session (Bannerlord mod search again) opened nexusmods.com in the embedded Browser Preview. The app died 6 seconds later — on the current build 1.26832.0.0, with isHardwareAccelerationDisabled: true active since Aug 5 (the crashed instance started 2026-08-11 16:52, well after the flag was set):

01:02:18  process-memory: tree_rss=1415MB, electron_gpu=127MB, sys_free=13017/32531MB   (no memory pressure)
01:02:32  [Preview] Created session preview context + browser preview (browser-preview-1786485752988-2)
01:02:38  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

Fourth crash, same exitCode 101457950 every time. Crashpad minidump was preserved this time (35.7 MB): exception 0x80000003 (STATUS_BREAKPOINT), module Claude.exe 1.26832.0.0, offset 0x6DD36F9, thread 38540 — the identical module offset as the 1.25927.0.0 minidump from Aug 5, i.e. the same assertion survives across two builds. I can provide the .dmp privately to Anthropic engineers on request (not attaching it publicly — minidumps can contain process memory).

So, correcting my Aug 8 comment: the four quiet days were absence of the trigger, not the mitigation working. Disabling hardware acceleration does not prevent this crash — the (software) GPU process dies the same way. The only avoidance that holds is not opening the trigger content in the embedded Browser Preview at all (external browser / plain HTTP fetch instead).

New diagnostic lead: the same app run logged 50 occurrences of:

[CDPTools] CDP compressed screenshot failed
Error: target closed while handling command

(last burst at 00:55:12, minutes before the crash) — screenshot commands racing target teardown/navigation. Plausible chain: the preview target gets destroyed/recreated (nexusmods serves a Cloudflare interstitial that reloads) while CDP screenshot commands are in flight → GPU process crash → main process hits the assertion at +0x6DD36F9. Suggested checks in addition to the earlier list: validate target/session before each screenshot command, cancel pending CDP commands on targetDestroyed/detachedFromTarget, make teardown idempotent, and isolate preview/GPU failures so they don't take down the main window.

Aftermath was the familiar cascade, fourth time, byte-for-byte: surviving background processes + CoworkVMService → RepairAppRegistration at 01:03:08 → 0x80073D02 → Modified, NeedsRemediation; manifest re-registration alone did not clear it; removal with PreserveApplicationData failed with 0x80073CFA (same double pattern as incidents 1–3); the signed installer restored the package at 01:08:31. Current state: 1.26832.0.0 Status: Ok, service running, user data intact.