[BUG] Windows Desktop: app dies during 7-agent parallel workflow with concurrent web fetches, then MSIX registration is wedged and Repair is blocked by leftover Claude processes; identical load completes in CLI

Summary

A dynamic workflow fanned out 7 parallel subagents, each performing sustained concurrent WebSearch/WebFetch calls. The desktop app died twice, taking all sessions with it, and each death left the MSIX package unable to activate: Windows showed the "this app is broken and needs repair" dialog, Settings > Repair failed with 0x80073D02 (apps need to be closed: Claude) because processes from the crashed instance were still running minutes later, and recovery required a full reinstall, both times.

The identical workflow at the same 7-wide concurrency then completed cleanly from a terminal CLI session on the same machine: 13.3 minutes, 290 tool calls, zero errors, peak memory 3.1 GB across 14 processes (largest single process 608 MB, 64 GB machine). The load is benign; only the desktop app fails under it.

Environment

• Claude Desktop 1.30096.5.0 (MSIX, Claude_1.30096.5.0_x64__pzs8sxrjxfjjc), Windows 11 build 26100, x64, 64 GB RAM
• Claude Code CLI 2.1.233 (control run)
• Local Code-tab session in a Git repository; ~13 MCP servers, 114+ deferred tools; Bypass permissions mode

Timeline (2026-08-15, local time; from session transcripts and the AppXDeploymentServer/Operational event log)

1. 19:30:04-12, death 1: all 7 subagent transcripts stop within an 8 s window (0 of 7 complete; every agent mid-burst of concurrent web fetches; MCP servers disconnect). No deployment operation preceded the death, ruling out an in-flight auto-update as the cause.
2. 19:33:39-19:34:22: relaunch fails activation; Windows loops repair registrations (RegisterByPackageFullName with ForceTargetApplicationShutdownOption, RepairAppRegistrationOption; one attempt takes 33.9 s).
3. 19:34:33-57: Settings > Repair re-downloads the MSIX from downloads.claude.ai, then the register fails with 0x80073D02: Claude is still running 4.5 minutes after the app died. We did not capture a process list; orphaned session/subagent engine processes are the obvious candidates (compare #19039, #18405).
4. 19:35:36: recovery tooling attempts Remove with PreserveApplicationData twice; both fail with 0x80073CFA (that flag is only valid for dev-mode packages, so this call can never succeed on a store-signed install). Fallback full reinstall (Stage from %TEMP% + Provision + Register) succeeds.
5. 19:36:44-49, death 2: workflow resumed via resumeFromRunId (0 cache hits, all 7 agents restart at once); all transcripts stop within 5 s, ~30 s after launch. Again no deployment operation preceded it.
6. 19:36:56-19:37:19: the identical recovery cascade repeats, including the same two 0x80073CFA failures. The cascade is systematic, not a one-off.

Windows recorded no crash event (Application Error / Hang / WER) and no crash dump for either death; the deployment cascade above is the only OS-side record.

<details>
<summary>Verbatim event log excerpts</summary>

19:34:57:

AppX Deployment operation failed for package Claude_1.30096.5.0_x64__pzs8sxrjxfjjc with error 0x80073D02. The specific error text for this failure is: error 0x80073D02: Unable to install because the following apps need to be closed Claude_1.30096.5.0_x64__pzs8sxrjxfjjc.

19:35:36 and again 19:37:13 (twice each):

Windows cannot remove Claude_1.30096.5.0_x64__pzs8sxrjxfjjc because the PreserveApplicationData flag can only be used on a package that was deployed in development mode.

AppX Deployment operation failed for package with error 0x80073CFA.

</details>

Expected behavior

• The workflow completes in the desktop app as it does in the CLI; at worst one subagent or session fails, not the whole app.
• If the app dies, its child processes die with it, so activation, Repair, and reinstall are not blocked by leftovers.
• The recovery path does not issue a Remove with PreserveApplicationData against a store-signed package (guaranteed 0x80073CFA).
• A crash does not leave the package needing a reinstall.

Reproduction

Windows desktop local session with a large MCP surface; launch a dynamic Workflow with 7 parallel agents doing sustained WebSearch/WebFetch against content-heavy pages. App dies within minutes; relaunch hits the repair dialog; resume dies faster.

Possibly related

• #81698 (GPU process crash kills entire app, Windows): same blast radius; we cannot confirm the dying component since no crash record was written.
• #81306 (crash wedged the MSIX package) and #82268 (MSIX reinstall prompt): same package-level aftermath; the cascade above may supply the mechanism those threads lack.
• #82227 (large transcript crashes GPU process on render; startup restore repeats it): the restore-repeats-the-crash shape matches our resume dying faster. Seven agents streaming page-sized tool results into the progress UI plausibly produces comparable renderer load (speculation).
• Closed subagent process/memory family: #32304, #32623, #7020, #19039, #18405. The 3.1 GB CLI peak argues against the leak class, but the leftover-process repair blocker echoes the orphan reports.

Available on request: per-agent transcripts from both dead runs (14 files), workflow script and journal, memory-sampling CSV from the CLI control run, exported AppX deployment events for 19:33-19:38.