[BUG] Claude Desktop (Windows/MSIX 1.25927.0): main process OOM-crashes at ~4.4 GB during session restore — ~3 min uptime, every launch

[cambolts98-dev]

Preflight Checklist

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

What's Wrong?

On a profile with ~1,048 sessions, the Electron main process grows from ~315 MB to ~4.4 GB within ~2.5 minutes of every launch and is killed at V8's heap ceiling. The app auto-restarts and repeats indefinitely. Uptime is ~3 minutes, consistently. The climb starts at launch and is independent of user action.

Not system memory exhaustion: 32 GB machine with 13 GB free at time of death. A single process is hitting a hard per-process limit.

Environment: app 1.25927.0, MSIX (Store) install Claude_1.25927.0.0_x64__pzs8sxrjxfjjc, Electron 42.7.0, Node 24.18.0, CCD 2.1.221, Windows x64, 32 GB RAM.

Memory curve

Four launches in 27 min (20:23, 20:41, 20:44, 20:50), each dying ~2.5–3 min in. From [process-memory]:

20:23:54  tree_rss=  466MB  electron_main:35368: 318MB   <- launch
20:24:49  tree_rss= 3444MB  electron_main:35368:2552MB
20:25:52  tree_rss= 4607MB  electron_main:35368:3747MB
20:26:22  tree_rss= 5417MB  electron_main:35368:4385MB   <- death

20:41:38  tree_rss=  452MB  electron_main:7536 : 310MB   <- relaunch
20:42:37  tree_rss= 3922MB  electron_main:7536 :2715MB
20:43:41  tree_rss= 5229MB  electron_main:7536 :4310MB
20:43:56  tree_rss= 5543MB  electron_main:7536 :4402MB   <- death

Independently confirmed by polling Get-Process Claude WorkingSet64 every 15 s:

21:09:38  2,065 MB
21:10:23  3,476 MB
21:10:53  4,309 MB
21:11:08  4,421 MB   <- ceiling
21:11:54     78 MB   <- died, restarted
21:12:09    849 MB   <- climbing again
21:13:54  4,048 MB   <- and again

GPU process is flat at 110–127 MB throughout; renderer stays 363–710 MB. All growth is in the main process.

Session restore is the workload

The log is dominated by [Restore] Skipping local_<uuid> — live session already in memory:

• 1,048 unique session IDs
• 4,137 restore lines → each session processed ~4×

On-disk data is tiny, so this is not a large-payload problem:

IndexedDB                   9 files      12.8 MB
Local Storage              12 files      31.4 MB
WebStorage                  3 files       0.0 MB
claude-code-sessions        1 files       0.0 MB
blob_storage                0 files       0.0 MB

~44 MB on disk producing ~4.4 GB resident.

Duplicate initialization

From launch 2 onward nearly every startup line is emitted in pairs:

20:41:37 [info] [growthbook] loaded 241 features (241 changed)
20:41:37 [info] [growthbook] loaded 241 features (241 changed)
20:44:40 [info] [WarmLifecycle:cowork] Initialized (arm=always)
20:44:40 [info] [WarmLifecycle:cowork] Initialized (arm=always)
20:41:44 [info] [ScheduledTasks] Renderer listener ready
20:41:44 [info] [ScheduledTasks] Renderer listener ready

Consistent with the 4× restore ratio — listeners/controllers appear to register more than once.

Orphaned processes survive the crash

[error] [Chrome Extension MCP] Failed to copy native host binary:
Error: EBUSY: resource busy or locked, copyfile
'...\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
-> '...\AppData\Roaming\Claude\

### Related issues

- #69039 — closest match (MSIX Windows, ~4.2 GB ceiling, startup OOM). Closed with no fix.
  All workarounds there failed, including clean reinstall with a fresh data container,
  --disable-gpu, --disable-background-networking, and --js-flags=--max-old-space-size=2048.
- #65550 — same signature, currently labelled "invalid".
- #61992 / #48276 — same V8 ceiling on macOS.
- #48942 — skills sync leak. **Ruled out for this report.** SkillsPlugin completes with
  `Found 7 enabled skills` / `Delta: 0 to download` / `Sync complete: 0 downloaded` at
  20:23:58, three seconds after launch and *before* the memory climb (20:24–20:26).
  The per-download leak cannot apply when nothing is downloaded.

Note: in #69039 a fresh data container still crashed, and local profile data here totals
only ~44 MB — suggesting the restored session state is fetched server-side at startup, so
clearing local data cannot mitigate it.

Regression timeline (same profile, no config/hardware changes):
- Ran fine daily until ~2026-08-04/05.
- 1.24012.9 (Aug 5): already crashing — peak main-process RSS 4,549–4,601 MB across
  3, 7 and 9 restarts in three rotated logs.
- 1.25927.0 (Aug 6): identical, peak 4,624 MB across 9 restarts.
So the regression landed at or before 1.24012.9. Note #80444 and #80468 also report
Windows MSIX failures in the 1.24012.x line.

### What Should Happen?

Session restore should be bounded — paged, lazy, or capped — so main-process memory stays flat regardless of how many sessions exist on the profile. The app should remain stable indefinitely rather than dying at a fixed memory ceiling ~3 minutes after every launch.

Suggested fixes:
- Page or lazily hydrate sessions instead of loading all into the main process at startup
- Deduplicate the restore pass (4,137 lines for 1,048 sessions)
- Fix double registration of startup listeners/controllers
- Reap crashed instances before starting a new one (the EBUSY path)
- Add a cap or user setting for restored session count as a safety valve

### Error Messages/Logs

```shell
[process-memory] main process, launch → death (repeats every launch):
20:23:54  tree_rss=  466MB  electron_main:35368: 318MB   <- launch
20:24:49  tree_rss= 3444MB  electron_main:35368:2552MB
20:25:52  tree_rss= 4607MB  electron_main:35368:3747MB
20:26:22  tree_rss= 5417MB  electron_main:35368:4385MB   <- death

Restore loop — 1,048 unique session IDs across 4,137 lines:
[Restore] Skipping local_<uuid> — live session already in memory

Skills sync completes cleanly BEFORE the climb (rules out #48942):
20:23:57 [SkillsPlugin] Found 7 enabled skills
20:23:57 [SkillsPlugin] Delta: 0 to download, 0 to remove
20:23:58 [SkillsPlugin] Sync complete: 0 downloaded, 0 failed, 0 removed

Orphaned instance holding files on every relaunch:
[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY:
resource busy or locked, copyfile
'...\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
-> '...\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

Present at every startup, no detail:
[error] Sentry caught: { eventId: '...', type: 'Unknown', value: 'No message', stack: undefined }

Steps to Reproduce

1. Use a Claude Desktop profile with ~1,000+ sessions (this profile has 1,048).
2. Launch Claude Desktop (Windows, MSIX/Store install).
3. Watch main process memory in PowerShell:
   while($true){ $p = Get-Process Claude -EA SilentlyContinue | Sort-Object WorkingSet64 -Descending | Select-Object -First 1; if($p){"{0:HH:mm:ss} {1:N0} MB" -f (Get-Date), ($p.WorkingSet64/1MB)}; Start-Sleep 15 }
4. Memory climbs linearly from ~315 MB, reaching ~4.4 GB at roughly 2.5 minutes.
5. Process is killed; app auto-restarts and repeats indefinitely.

No user interaction required — the climb begins at launch regardless of what is on screen.
Reproduced on 30+ consecutive launches across two app versions.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

unknown — whichever release preceded 1.24012.9

Claude Code Version

1.25927.0 (Claude Desktop, MSIX; CCD 2.1.221)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Attaching main.log from the crash loop (four launches, 20:23–20:53).

Diagnostic method: memory measured two independent ways — the app's own [process-memory]
telemetry, and external polling of Get-Process Claude WorkingSet64 every 15s. Both agree.

Peak main-process RSS across rotated logs on this profile:
main4.log 1.24012.9 3 starts peak 4549 MB
main3.log 1.24012.9 7 starts peak 4601 MB
main2.log 1.24012.9 9 starts peak 4601 MB
main1.log 1.25927.0 9 starts peak 4624 MB
main.log 1.25927.0 4 starts peak 4421 MB

Local profile data totals ~44 MB, so the memory is not proportional to on-disk state.

main.log

[cambolts98-dev]

Truncated from the original body — the eliminations. Each of these was tested on this
profile, not assumed:

1. GPU / hardware acceleration — GPU process flat at 110–127 MB across every run
   while the main process climbed to 4.4 GB. Not a GPU-process crash; distinct from
   [Windows] Desktop app 1.24012.1: fatal GPU-process crash (0x060C201E) via in-app Browser tab; crash leaves MSIX package unlaunchable (appxState=2) until Repair #80444 / Claude Desktop App Crashing After the Latest Update on Windows #80468. Per-app GPU preference pinned to High Performance made no difference.
2. Stuck upload queue — pending-uploads held 475 items / 141.5 MB. Renamed aside,
   relaunched: memory still reached 4,421 MB and crashed on the same schedule.
3. Local storage state — Local Storage and Session Storage renamed aside to force
   a rebuild. Still climbed 402 MB → 3,869 MB in 106 seconds, same trajectory.
4. System memory pressure — 13 GB of 32 GB free at time of death.

Impact: the app is unusable on this profile. It cannot stay open long enough to complete
any task, and the loop is self-sustaining — each restart re-triggers the same restore.
No user-accessible setting limits session restore, and MSIX installs cannot pass Electron
launch flags, so none of the flag-based workarounds in related issues are even available.

[cambolts98-dev]

Flag-based workarounds are not achievable on MSIX. Launching with arguments via
Invoke-CommandInDesktopPackage fails with 0x800704C7 ("already running") because the app
relaunches itself after each crash faster than it can be held down — 12 consecutive
Stop-Process attempts still left an instance alive. So --js-flags, --disable-gpu etc.
cannot be applied on a Store install of this app at all.

[cambolts98-dev]

Process accumulation: repeated attempts to stop the app leave orphaned processes rather
than cleaning up. Count went 8 → 4 → 8 → 12 across successive stop attempts within a few
minutes. Stop-Process -Force triggers Windows Restart Manager (the app is registered for
automatic restart), and CloseMainWindow() is never handled because the main process is
saturated during the restore climb. Net effect: on MSIX there is no way to reach a state
where the app is stopped, so no launch-flag workaround can be applied at all.

[cambolts98-dev]

ROOT CAUSE FOUND, and a working workaround.

The session store is on disk, not server-side, at:
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude
local-agent-mode-sessions<account-uuid><org-uuid>\

It contained 17,643 local_.json files at ~0.9 MB each — roughly 15 GB — which the
main process reads at every launch. That is what walks it to the 4.4 GB V8 ceiling. The
"1,048 sessions" in my original report was just how far it got before dying, not the total.

Note this folder is easy to miss: Get-ChildItem on it returns almost nothing and recursive
listing comes back empty, because PowerShell 5.1 silently fails on the >260-char paths.
Earlier folder-size checks reported ~44 MB of profile data and skipped this entirely.

Fix: moved all but the 600 most recent session files to another folder. Nothing deleted.

Before: 2,065 → 3,476 → 4,309 → 4,421 MB → killed at ~2.5 min, every launch
After: 848 → 594 → 478 → 447 → 484 MB, flat and stable

Accumulation rate matters: July alone created 14,067 of these files, and August added 2,874
in six days (~480/day). So this reaches the ceiling again for any heavy user. Suggested
fixes: page/lazily hydrate sessions rather than loading all at startup, prune or archive
old sessions automatically, and cap what gets restored.