[BUG] Windows desktop: recurring MoAppHang mid-subagent-spawn (same Watson bucket across 4 versions); hang wedges MSIX package into "Can't open this app" repair loop

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Windows desktop app hangs (Windows MoAppHang, "claude.exe stopped interacting with Windows") repeatedly — same Watson bucket across 4 app versions in 10 days — and a hang now leaves the MSIX package in a state where Windows refuses to launch the app ("Can't open this app") until the user runs Settings → Apps → Claude → Repair. On 2026-08-31 alone: 5 hangs, 3 repair cycles, all in-flight sessions and background Workflows lost each time.

Watson / WER signature (identical across hangs):

• Fault bucket 1505780470138118120, type 5, MoAppHang
• P1 Claude_1.40609.0.0_x64__pzs8sxrjxfjjc, P2 praid:Claude, P3 1.40609.0.0, P4 6a8b9cb0, P5 (Hang Signature) 4185, P6 (Hang Type) 2097152
• Additional hang signatures 4185febb6d8862cff983839b1fd576e1 / babc84837f7c929183ae6c8c5f7e4601; hashed bucket 6e0aa7ee72a096f714e59b5c104d9fe8; Report Id 40d7743b-6dca-472b-bdfa-7b1314c0ac1b (uploaded 2026-08-31 15:28:34 UTC)
• Prior Application Hang 1002 records for claude.exe: 8/21 (v1.32885.1), 8/26 ×2 (v1.37937.0/.1), 8/28 (v1.37937.3) — same failure family, four versions

What the hung process looked like (WER process snapshot, first 8/31 hang):

• The hung PID was the long-lived MSIX main shell: ~69.5 h old, 0.16 s total lifetime CPU (blocked waiting, not spinning), 9 threads, working set paged down to ~12 MB, ~28.5 min cumulative Desktop Activity Moderator suspension (Modern Standby laptop)
• Caught mid-spawn: a child claude.exe (parent = the hung shell) created 5–6 s before the hang shows 0 threads / 0 CPU / 0 I/O in the snapshot
• No dump captured anywhere: no .dmp/.hdmp; Crashpad reports empty; Sentry session "ok, errors 0" — hangs are invisible to app telemetry (WER-only)

Launch-refusal chain after a hang:

1. Hang → force-close leaves zombie claude.exe processes
2. Next launch: AppModel-Runtime Event 6 — "Cannot create the process for package <NULL> because an error was encountered while checking the machine-level package status… Try reinstalling" → user sees "Can't open this app → Repair"
3. Settings-Repair races those zombies: Register step fails 0x80073D02 "Unable to install because the following apps need to be closed" / Event 9641 "Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude" — takes multiple repair attempts
4. The same repair logs Event 8104 "Failed to set the Trust Label… 0x80070057" and Event 8107 "Illegal non-AppStore or non-AppInstaller package integrity validation attempted"

Ruled out with evidence (2026-08-31): GPU (zero TDR/DxgKrnl/WHEA events all day; Intel driver current), memory exhaustion (~3.9 GB free at hang 1; hang 2 was 9 min after a fresh boot with pagefile peak 388 MB), AV interference (no Sophos/SonicWall events touching the package), hardware faults (no WHEA), unclean shutdown (the mid-day reboot was orderly).

Correlation: hangs strike under multi-subagent load — sessions running a multi-agent Workflow (5–10 parallel subagent claude.exe spawns) plus the in-app Browser pane, with 2 concurrent sessions in one app instance. Resuming that workload after a fresh boot reproduced the hang in ~3 minutes.

What Should Happen?

• The main UI process should never block indefinitely while spawning subagent child processes; a failed or slow child spawn should fail that subagent, not freeze the entire app
• A force-closed hang should never leave the MSIX package unlaunchable (the machine-level package status wedge)
• Repair/re-register should use ForceApplicationShutdown semantics so it cannot fail 0x80073D02 against the app's own zombie processes
• Hangs should produce a dump or Sentry event — today they are invisible to the app's own telemetry, only WER sees them

Error Messages/Logs

Event 1002: The program claude.exe version 1.40609.0.0 stopped interacting with Windows and was closed.
WER 1001: Fault bucket 1505780470138118120, type 5, Event Name: MoAppHang, P1: Claude_1.40609.0.0_x64__pzs8sxrjxfjjc, P2: praid:Claude, P3: 1.40609.0.0, P4: 6a8b9cb0, P5: 4185, P6: 2097152
AppModel-Runtime Event 6 (x8 on 8/31): 0x3CFC: Cannot create the process for package <NULL> because an error was encountered while checking the machine-level package status. The application cannot be started. Try reinstalling the application to fix the problem.
AppXDeploymentServer 404: error 0x80073D02: Unable to install because the following apps need to be closed Claude_1.40609.0.0_x64__pzs8sxrjxfjjc.
AppXDeploymentServer 9641: 0x80004004: Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude.
AppXDeploymentServer 8104: Failed to set the Trust Label on package Claude_1.40609.0.0_x64__pzs8sxrjxfjjc with flags 0x0. Error: 0x80070057.
AppXDeploymentServer 8107: Illegal non-AppStore or non-AppInstaller package integrity validation attempted for package Claude_1.40609.0.0_x64__pzs8sxrjxfjjc. Flags: 0x0
Fresh-installer run (8/31 4:23 PM): 0x80073CFA: Windows cannot remove Claude_1.40609.0.0_x64__pzs8sxrjxfjjc because the PreserveApplicationData flag can only be used on a package that was deployed in development mode.
CoworkVMService (logged at the exact second of each hang): Claude VM Service: failed to disarm SCM recovery actions for this stop... open service: Access is denied.

Steps to Reproduce

1. Windows 11 (build 22631), Claude desktop MSIX 1.40609.0.0, Modern Standby laptop, 16 GB RAM
2. Open two Claude Code sessions in the desktop app; in one, run a multi-agent Workflow (5–10 parallel subagents) and use the in-app Browser pane
3. Within minutes the whole app UI freezes (MoAppHang); Windows offers to close it
4. Relaunch → "Can't open this app — you'll need to go to advanced options for Claude and select Repair"
5. Run Repair while any claude.exe is still resident → fails 0x80073D02; kill the processes and repair again → succeeds until the next hang

Reproduced 5 times on 2026-08-31, including twice within 10 minutes of a clean reboot (so accumulated system state is not required).

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

Unknown — same hang bucket observed on 1.32885.1, 1.37937.0/.1/.3 and 1.40609.0.0; the launch-wedge severity escalated on 1.40609.0.0

Claude Code Version

Desktop app 1.40609.0.0 (MSIX windows-store build; Electron 42.10.0, Chrome 148.0.7778.280, Node 24.18.1)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment: Dell Latitude 7430, i5-1245U, 16 GB RAM, Intel Iris Xe (driver 32.0.101.7084, 2026-01-14), Windows 11 Pro 22631, Modern Standby (AOAC); corporate endpoint with Sophos AV + SonicWall, domain-joined.

No version escape exists: reinstalling from claude.com/download on 8/31 4:23 PM delivered the same 1.40609.0.0 (confirmed current latest). The fresh install DID reset the wedged package state — and surfaced its own defect: the installer's removal step failed twice with 0x80073CFA (PreserveApplicationData only valid for dev-mode packages) before falling back to an over-the-top Add.

Related issues (pieces of this chain, mostly without root-cause evidence; several closed unresolved): #91072, #88192, #85199, #85840 (matches the CoworkVMService "Access is denied" SCM events in our logs), #87161, #84333, #83473, #86695. What none of them contain — and this report does — is the hang-side forensics: the constant Watson bucket across 4 versions, the WER process snapshot showing the main shell blocked mid-child-spawn, and the correlation with multi-subagent Workflow load.

Evidence available on request: Report.wer from ReportArchive, the orphaned first-hang WER Temp report + 2 WPR .etl traces (29.8 MB + 2.7 MB), full Application/System/AppXDeploymentServer/AppModel-Runtime event-log extracts, Win32_ReliabilityRecords history.