[BUG] Windows desktop app: unbounded memory growth with embedded sessions running parallel subagents — app hang / webview OOM at ~20 GB

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?

Running an embedded (local) Claude Code session in the Windows desktop app that fans out
parallel research subagents makes the app's memory grow unboundedly until the app freezes
(MoAppHang) or the main webview is OOM-killed. To the user the app simply dies silently —
no error dialog.
Reproduced on three separate days (2026-07-21, 07-25, 07-26). On the last occurrence a
FRESH install died within ~30 minutes while a session whose transcript was only 0.4 MB ran
a 3-agent fan-out — so this is runtime growth (session/IPC data), not transcript size.
Key data points:

• 2026-07-21 12:10:58 main.log: "Main webview render process gone: { reason: 'oom',

exitCode: -536870904 }" — process tree at that moment: tree_rss_sum 19,745 MB,
electron_main ALONE 8,833 MB, one renderer 7,396 MB; growth ~85 MB/min during fan-out.

• Daily tree_rss_sum maxima 12.9–20.1 GB (2026-07-16 … 07-21); 1.9 GB on a day the heavy

session stayed closed (control).

• 2026-07-16: Windows Resource Exhaustion Detector flagged claude.exe (RADAR_PRE_LEAK_64),

then version 1.21459.3.0 — so the issue spans many app versions.

• 2026-07-25 19:11 event log: MoAppHang ("claude.exe stopped interacting with Windows").
• The MAIN process ballooning to >8 GB points at session/IPC data buffered in the Electron

main process (where embedded sessions run), not just renderer DOM weight.
Impact: 7 reinstalls and 2 forced reboots within 36 hours; paid usage repeatedly lost
because running research died with the frozen app. Workaround: running heavy sessions in
the standalone CLI instead of the app.

What Should Happen?

A memory cap / backpressure for embedded sessions. One session streaming a lot of subagent
output should never take the whole desktop app down. Warm/hidden sessions should shed their
buffered data. If a session's renderer dies, the app should surface an error instead of
silently freezing.

Error Messages/Logs

2026-07-21 12:10:58 main.log: Main webview render process gone: { reason: 'oom', exitCode: -536870904 }
2026-07-21 12:10 main.log: [process-memory] tree_rss_sum=19745MB electron_main=8833MB renderer=7396MB
2026-07-16 20:07 WER: RADAR_PRE_LEAK_64 for claude.exe (v1.21459.3.0)
2026-07-25 19:11 WER: MoAppHang — claude.exe stopped interacting with Windows and was closed
(also chronic, probably unrelated: GPU process gone, exitCode 34, almost daily since early June)

Steps to Reproduce

1. Install the Claude desktop app for Windows (MSIX, 1.24012.9), 32 GB RAM machine.
2. Open a local (embedded) Claude Code session in a project folder.
3. Run a research task that fans out several subagents in parallel (Agent tool /

workflows), high reasoning effort, Opus/Fable class model.

1. Watch the app's own [process-memory] lines in main.log: tree RSS grows ~85 MB/min,

electron_main climbs past 8 GB.

1. After ~30–240 min the app freezes or the main webview is OOM-killed; no error dialog.

A fresh install with an empty 0.4 MB session reproduces it — only the fan-out matters.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Desktop app 1.24012.9 (MSIX) with embedded Claude Code (CCD) 2.1.219; standalone CLI 2.1.220

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Windows 11 Pro build 10.0.26200, 32 GB RAM.
• This is about the DESKTOP APP's embedded sessions, not the standalone CLI (the CLI is fine).
• Full forensic timeline (main.log excerpts, WER + AppXDeployment event log exports)

available on request.