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

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?

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 }

1. Memory climbs linearly from ~315 MB, reaching ~4.4 GB at roughly 2.5 minutes.
2. 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