Claude Desktop (Windows) recurring AppHang (Event ID 1002 MoAppHang) during background subagent dispatch — 7+ occurrences, no crash dump captured despite LocalDumps configured

Summary

Claude Desktop on Windows repeatedly becomes unresponsive and is force-closed by Windows (MoAppHang, Event ID 1002 in the Application event log — an IPC/message-pump responsiveness stall, not a memory-access crash) during sessions that dispatch multiple background subagents via the Agent/Task tool. This has recurred at least 7 times across several weeks on the same machine, most recently twice in one session on 2026-08-02.

This is a Windows desktop-app stability bug, not a data-loss issue — every incident has been verified via git status/git log to have caused zero lost work. Filing because the app itself becomes unusable mid-session and has to be manually restarted, and because the failure mode has proven very hard to diagnose from the outside.

Environment

• Claude Desktop (Windows), app path: C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64… (confirmed via winget upgrade that this is the latest available version at time of investigation — not a stale-build issue)
• Windows 11 Home 10.0.26200
• 32GB RAM, plenty of headroom at time of each incident (system memory ~30% used or less; CPU ~6% when checked cold)

Reproduction pattern (best characterization so far)

Not fully deterministic, but strongly correlated with:

1. Dispatching 3 (within the app's own recommended concurrency range — not an extreme count) background subagents via the Agent/Task tool that each do live network I/O (WebFetch/curl/PDF fetch), even with zero local builds/installs running.
2. Most recently (2026-08-02), also correlated with multiple Browser-pane tabs (opened via preview_start/navigate) left open across turns while background agents are in flight — each idle tab holds its own Chromium renderer process.

Confirmed NOT the cause (ruled out across multiple incidents):

• Not OOM — system memory was well under capacity at time of every incident checked live.
• Not a stale/outdated build — same app version confirmed current via winget upgrade.
• Not local build/test resource contention alone — has recurred with pure WebFetch/PDF-research agents and zero pnpm/next build/test processes running.
• Windows Event Viewer confirms zero Id-1000 events (true access-violation crashes) across 45+ days of history — every incident classifies as Id-1002 MoAppHang specifically (main-thread/IPC responsiveness stall).

Diagnostic dead ends already tried

• Configured HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\claude.exe (DumpType=2, full dump) specifically to catch the next occurrence. The LocalDumps hook has not fired for a single MoAppHang incident since being configured — the dump folder stays empty every time, across multiple confirmed incidents. This suggests Windows' MoAppHang ghost-window detector may not trigger LocalDumps the way a true crash does, which is itself worth knowing on your end if you have telemetry for this failure mode.
• Report.wer metadata (when present) confirms only the MoAppHang classification — no thread/module fault data, since that only lives in a dump that gets evicted before it can be pulled (WER's ReportArchive is SYSTEM-ACL-protected and prunes payloads quickly).
• Most recent 2 incidents (2026-08-02) didn't even produce an Id-1002 Event Viewer entry, despite matching every other symptom (background agents reported status: stopped / "no completion record found... may have been running when the previous Claude Code process exited", full app restart with fresh PIDs) — so this failure mode doesn't reliably leave a forensic trail even with logging enabled.

What would help

• Any first-party telemetry/crash-reporting Anthropic has server-side for Windows MoAppHang events on Claude Desktop, correlated with concurrent background-subagent dispatch counts and/or open preview/browser-pane tab counts.
• Confirmation of whether LocalDumps is expected to catch this failure mode at all, or whether a different capture mechanism (e.g., Windows' Cascade/WerFault full-hang dump path) is needed.
• Any known concurrency limits internally recommended for background subagent dispatch + Browser-pane usage on Windows specifically.

Happy to provide more detail, try a suggested diagnostic, or test a build with additional hang-instrumentation if useful.