[P0][Regression] macOS app OOM-crashes at startup: external-agent-import parses 1.73 GB from Claude Desktop's app-support directory on every launch

ChatGPT on MacOS is freezing because of this for 10 minutes after I launch it

Reproduced on a newer build, with some additional findings — most importantly why this never stops retrying.

Environment

• ChatGPT.app 26.730.61639 (build 6234) — extends the affected range beyond the 6067/6119 reported here. Also reproduced on 6119 and on 26.721.81911 (build 5973).
• Bundled Codex CLI 0.147.0-alpha.1.2, macOS 26.5.2 (25F84), M-series, 16 GB RAM.
• Source directory: ~/Library/Application Support/Claude/local-agent-mode-sessions/ — 5.0 GB across 23,171 files (roughly 3× the 1.73 GB reported in the original post).

Different OOM signature, same trigger

OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
EXIT CODE: 133

The GC log shows the heap pinned at the ceiling right before death:

632061 ms: Mark-Compact (reduce) 3951.9 (3959.1) -> 3951.8 (3958.8) MB, last resort; GC in old space requested
632074 ms: Mark-Compact (reduce) 3951.8 (3958.8) -> 3951.8 (3957.8) MB, last resort; GC in old space requested

Crash reports show EXC_BREAKPOINT / SIGTRAP on CrBrowserMain inside Codex Framework, with the faulting frame under node::fs::AfterInteger.

It is not only a startup crash — it recurs on a ~10 minute cycle

This is worth emphasizing, since the title frames it as startup-only. In one instrumented run the process idled at ~240 MB for 632 seconds, then died. Sampling RSS every 5s, the last reading before death was 241 MB — the jump to ~3950 MB happened in under 5 seconds, in a single allocation burst.

The app log's last entry before every OOM is the same:

12:55:46.482  externalAgentConfig/import/readHistories
12:55:47.315  external_agent_import_provider_stage_finished providerId=claude-code sessionCount=40 stage=detect status=success durationMs=825
12:55:49.133  OOM

Three independent reproductions, same sequence each time.

Why it retries forever

external_agent_config_imports in ~/.codex/state_5.sqlite has 0 rows.

That is the completion-record table added in #28396. Because the process is killed before it can persist a record, nothing is ever marked as imported, so the next detect pass runs again — and dies again. That is what turns "slow/expensive startup work" into a permanent crash loop with no user-visible way out.

Related: #26637 and #34449 treat this path as a performance problem. From here it presents as a hard availability bug — #34449 merged 10 days before the OOM reports started, so the configurable detection limits do not cover this case.

Confirmations of things already reported here

• --js-flags=--max-old-space-size and NODE_OPTIONS are both silently ignored. Three attempts at 8192 and 10240 MB died at 3939, 3946 and 3938 MB respectively — the limit never moves.
• Opening Settings → Import actively triggers the scan. The panel hangs on "Checking for imports" / "Loading import history" while it runs. This matches #33283, which was auto-closed as a duplicate 31 seconds after being filed.

Isolation

Running the same binary with an empty CODEX_HOME starts and stays stable at ~650 MB, so the app bundle itself is fine.

One aggravating factor worth noting separately: the electron-persisted-atom-state key in ~/.codex/.codex-global-state.json (227 KB, 336 atoms) raises the baseline heap enough to make the app OOM during startup rather than minutes later. Removing that key moved time-to-crash from ~13 seconds to ~10 minutes, but did not fix the underlying crash — the import still kills it on its next cycle.

Mitigation, with numbers

Archiving files older than 14 days out of local-agent-mode-sessions/ (17,381 files, 3.86 GB moved; 1.1 GB / 5,794 files left in place):

| | before | after |
|---|---|---|
| scan peak | OOM at ~3950 MB | 757 MB / 1074 MB / 1151 MB, memory released each time |
| outcome | dead in 13 s – 11 min | stable, no crashes |

The scan now completes and returns the memory instead of exploding. Same operation, same code path — only the input size changed.

Suggested fixes

Streaming or batching the read would fix the root cause, but two cheaper guards would stop the crash loop on their own:

1. Record an attempt in external_agent_config_imports before doing the expensive read, so a crash cannot produce an infinite retry.
2. Bound the work by total bytes, not just session count — sessionCount=40 says nothing about whether those 40 sessions are 40 MB or 4 GB.

Confirming this diagnosis with a strong data point from #37493 (now closed as duplicate of this issue).

Deterministic reproducer: my ~/Library/Application Support/Claude/ is 19 GB / 79,740 files — roughly 10× the size reported above. At that size the crash is not a coin flip: the app dies on every launch, ~6–15 s in, on both 26.730.61639 (build 6234) and 26.803.41515 (build 6321). Crash signatures alternate between the V8 heap OOM on CrBrowserMain and EXC_BREAKPOINT (SIGTRAP) in V8 GC code on a V8Worker thread — consistent with dying at slightly different points of the same runaway import.

Clean control: the identical builds run fine on my other Mac (M4 Pro, macOS 26.3.1), which has essentially no Claude data. Before finding this issue I'd chased the wrong variables and ruled them out one by one:

• Fresh CODEX_HOME + fresh Codex Application Support → still crashes (consistent with the import reading Claude's directory, not Codex state)
• Clean direct install from the full appcast zip, size + codesign verified → still crashes
• macOS version: updated the affected machine 26.2 → 26.6.1, newer than the working machine → still crashes, identical signature

The data-size correlation is the only variable left standing, and it matches this issue's mechanism exactly.

Last working build here is 26.727.51351; I've pinned it (chflags uchg + blocked SUFeedURL) since there's no setting to disable the import scan. Full .ips crash reports for both crashing builds are attached.

An off switch for external-agent-import (or lazy/bounded import) would resolve this for heavy Claude Code users, who seem to be the population hit hardest.

48 GB M3 Max: reversible isolation test confirms the trigger

I ran a controlled isolation test on another affected machine.

Environment

• Mac15,9, Apple M3 Max, 48 GB RAM
• macOS 26.6
• ChatGPT/Codex Desktop 26.730.61639, build 6234
• ~/Library/Application Support/Claude/local-agent-mode-sessions:
• 10,386,424 KiB (~9.9 GiB)
• 104,902 files
• 8,322 local_*.json files
• 16,709 nested .jsonl files

Baseline

With the Claude directory in its normal location, build 6234 consistently
terminated after approximately 8–9 seconds:

• CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
• V8 heap approximately 3.99 GB
• EXC_BREAKPOINT / SIGTRAP
• CrBrowserMain
• stack included v8::String::NewFromUtf8,

node::StringDecoder::DecodeData, and Node filesystem callbacks

Build 26.803.41515 (6321) also failed in 6–15 seconds when tested with a
separate Electron profile.

Reversible isolation test

1. Fully stopped Claude Code.
2. Confirmed with lsof that nothing held the directory open.
3. Renamed only local-agent-mode-sessions to a sibling path.
4. Launched the same installed build 6234 with an isolated Electron profile.
5. Monitored the main process for 60 seconds.

Result

• The application survived the full 60-second test.
• No V8 OOM or SIGTRAP occurred.
• Main-process RSS peaked at 1,219,168 KiB during startup, then fell and

stabilized near 509,408 KiB.

• The test process was terminated normally afterward.
• The Claude directory was restored unchanged.

This also demonstrates that 48 GB of physical RAM does not protect against the
defect; the limiting resource is the Electron/V8 heap populated by the import.

Could this be treated as a launch-blocking availability regression rather than
only a performance issue? An immediate mitigation could be shipped before the
full streaming fix:

1. Disable automatic external-agent import by feature flag.
2. Require explicit user initiation from Settings → Import.
3. Apply aggregate byte/file/time limits before parsing.
4. Persist an attempted/failed scan so an OOM cannot create an infinite retry

loop.

1. Fail the importer independently without terminating the desktop process.

Third independent confirmation of the root cause — and a new data point on the retry loop.

Build 26.803.61601 (6396) is still affected: two launch crashes on Aug 11 on a 16 GB M-series MacBook (macOS 26.6.1/25G76) — EXC_BREAKPOINT (SIGTRAP) on CrBrowserMain, uptimes 7.7 s and 14.2 s, faulting stacks in v8::Isolate::LowMemoryNotification / v8::CppHeap::CollectGarbage.

Intervention on the same machine, same build, ~25 minutes later: moved every local_*.json older than 72 h out of ~/Library/Application Support/Claude/local-agent-mode-sessions — 2,161 files / 4.13 GiB moved, leaving 38 files / 29 MB. Build 6396 then launched clean on the first try: >75 s uptime, steady RSS ~318 MB (vs ~2.9 GB pre-archive startup peak), zero new crash reports. Only the payload changed; consistent with @santiromer's archive result and @pgolec's rename test.

New: after that first successful launch, external_agent_config_imports in ~/.codex/state_5.sqlite still contains 0 rows. So the missing completion record is not only a crash artifact — even a surviving import doesn't persist one, meaning the full scan apparently re-runs on every launch regardless. A persisted completion record and/or an mtime/byte cap on the scan would each independently mitigate this.

No change in importer behavior observed through 6396; nothing in the changelog for 26.803.x either.

Still reproducible in 26.803.81509 (build 6415) — worse: full local state wipe does not help

Confirming this regression persists in the latest build. My data point is a heavier case than the OP's:

• Environment: ChatGPT 26.803.81509 (build 6415), macOS 26.6.1 (25G76), Apple Silicon (Mac17,9)
• Claude data scanned: ~/Library/Application Support/Claude/local-agent-mode-sessions = 3.3 GB across 22,959 files (~1,000 local agent sessions)
• Result: OOM crash-loop 6–16 s after every launch; app is completely unusable

Captured from a terminal launch:

[86980:0x12001410000]  6227 ms: Mark-Compact (reduce) 3577.4 (3612.3) -> 3577.4 (3612.1) MB ... last resort; GC in old space requested
ERROR:owl/common/node_bindings.cc:109] OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Crash signature (.ips): EXC_BREAKPOINT (SIGTRAP) on CrBrowserMain, main-thread stack ending node::fs read callback → node::StringBytes::Encode → v8::String::NewFromTwoByte → V8 fatal. The last app-log lines before death are always external_agent_import_provider_stage_finished ... providerId=claude-code sessionCount=10 stage=detect, ~2 s before the crash. lsof polling during startup shows the main process enumerating hundreds of files under local-agent-mode-sessions/.

Additional findings:

1. Wiping all local app state does not help — I removed ~/Library/Application Support/Codex, all Codex/com.openai.codex caches, com.openai.codex.plist, HTTPStorages, and ~/.codex entirely; the app re-scans Claude's directory and OOMs identically on a 100% fresh profile. Reinstalling the app also has no effect.
2. --js-flags="--max-old-space-size=16384" is ignored — same OOM at the ~3.6 GB ceiling, so there's no user-side launch workaround.
3. Regression timeline matches #33088: in 26.721.81911 this same scan appeared to run only when opening Settings (app crashed ~3 s after opening Settings, identical stack via NewFromUtf8); since the startup scan was introduced it's a launch crash-loop.

Happy to provide full .ips reports or run instrumented builds.

Another confirmation, and one of the larger payloads reported: on a macOS Apple Silicon machine (heavy Claude user), ~/Library/Application Support/Claude/local-agent-mode-sessions was 21 GB across 148,953 files. ChatGPT/Codex desktop 26.803.41515 (6321) OOM-crash-looped on every launch (dead in <20 s; a lower-RAM Mac showed a blank white window and died even sooner). Moving that directory aside -> the app launches clean and stays stable; restoring ~/.codex sessions afterward is fine. So it is purely the external-agent-import scan volume, not Codex's own state or the ChatGPT account (reproduced across two machines / two accounts). +1 for an off-switch or an mtime/byte cap on the scan.

Update: build 26.810.52044 (6662) still contains the same unbounded Cowork manifest-parse ordering.

A read-only inspection of the currently installed app bundle (Contents/Resources/app.asar, .vite/build/main-BIHCWhv-.js) shows:

• Mk(accountOrgDirs) enumerates every *.json in each account/org directory and its agent/ subdirectory via zk().
• It immediately runs Promise.all(t.map(Ik)).
• Ik calls bE; bE performs readFile(path, "utf8") followed by JSON.parse.
• Only after all promises resolve are the parsed manifests deduplicated by sessionId.

I found no pre-read stat/mtime filter, file-count limit, per-file size ceiling, or aggregate-byte cap in this path. Therefore, age/session limits applied later cannot bound the initial V8 allocation burst.

Build 6662 also exposes external-agent-import-sync-enabled (default false) for autosync, but that is not a clear “never scan Claude data” guard around this detection path.

Important: I am not claiming a fresh OOM reproduction on 6662. After the Aug 11 move-only archive, this machine's live payload is currently small (last measured earlier today: 140 local_*.json files / 115,778,659 bytes), and I did not restore or modify the protected archive. This is static confirmation that the vulnerable ordering remains in the latest installed build.

An immediate safe hotfix would be to stat/filter and enforce an aggregate-byte cap before any content read, replace the unbounded Promise.all with limited concurrency, and add an explicit opt-out or isolate discovery from the desktop main process.

Confirmed fixed in 26.818.22352 (build 6872) — verified at 3.6 GB scale

Follow-up to my Aug 13 report: today's build resolves this on my machine, and the fix appears deliberate rather than incidental.

Empirical test: I restored my full Claude session store (3.6 GB, ~23k files, 2.3 GB of .jsonl transcripts — more than the load that crash-looped 26.803) and launched. The app survived, peak RSS ~1.1 GB during the scan, settling at ~495 MB. Previous builds hit the ~3.6 GB V8 heap ceiling and died within 6–16 s. Zero OOM/FATAL lines on a terminal launch.

Bundle inspection (Contents/Resources/app.asar, same read-only method as pkruger1977's Aug 16 comment): the import path is rewritten with explicit budgets —

• sessionBytes: 16*1024*1024 and sessionMessages: 1e4 per session
• sessionAttempts: 500 plus a directoryEntries budget per scan
• maxSessionAgeMs default 30 days
• a history-limit skipped-reason with graceful deferral instead of unbounded Promise.all readFile+parse

The unbounded ordering pkruger1977 found in 26.810.52044 is gone in 6872.

Caveat for the heavy cases in this thread: my store is 3.6 GB — the 19–21 GB / ~150k-file reports may still stress the 500-attempt/entry-budget path differently, so worth re-testing at that scale before closing.