Codex Desktop (Windows): browser process aborts with V8 heap OOM; crash rate scales with connector catalog size

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.61454

What subscription do you have?

Business

What platform is your computer?

No response

What issue are you seeing?

App: Codex Desktop 26.901.51231 (MSIX from Microsoft Store, OpenAI.Codex_<version>_x64__<publisher>) Chromium/Electron: 152.0.7977.83 OS: Windows 11 10.0.26200 x64, 20 CPUs, 32 GB RAM codex CLI: 0.144.4 (shares ~/.codex) Plan: ChatGPT paid

Summary

The Codex Desktop browser (main) process repeatedly aborts with a V8 JavaScript heap out-of-memory error. This is not system memory exhaustion — the process working set at the time of the abort was roughly 1 GB on a 32 GB machine. The failure is against V8's own per-isolate heap ceiling inside the app's Node bindings layer.

Crucially, crash frequency scales with the size of the connected Apps/connector tool catalog. Removing connectors (and nothing else) cut the crash rate by more than half. That correlation is the strongest signal in this report and should point at the leak.

Crash signature

From the Crashpad minidump (ptype: browser):

Exception code : 0x80000003   (STATUS_BREAKPOINT — deliberate abort)
Faulting module: chrome.dll + 0x3A8078D
Thread         : 44820

The fatal log line captured in the same dump, on the same thread:

[41664:44820:0909/112341.259:ERROR:owl\common\node_bindings.cc:109]
OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

CALL_AND_RETRY_LAST means V8 performed a final full GC and still could not satisfy the allocation, so this is genuine old-space exhaustion rather than fragmentation or a transient spike.

The process command line contains no --js-flags and no --max-old-space-size, so the default V8 heap limit applies. Because the abort is a breakpoint handled by Crashpad, Windows logs no Application Error event — from the user's point of view the app simply vanishes with no dialog and no error.

Crash rate vs. catalog size

Crashpad reports collected over three days on one machine, correlated with the codex_apps tool catalog size (measured from the app's own persisted mcp-extension-sidebar-catalog state):

Date | Crashes | codex_apps tools | Catalog size -- | -- | -- | -- 09-07 | 9 | 398 (473 total) | 2042 KB 09-08 | 5 | 398 | 2042 KB 09-09 | 4 | 284 (332 total) | 1310 KB

"After" reflects two changes: removing the Microsoft 365 connectors, and moving ten oversized sessions/*.jsonl rollout files (1.44 GB, largest 288 MB) out of ~/.codex. Crashes became less frequent but did not stop.

Expected behaviour

The browser process should not exhaust the V8 heap as a function of how many connectors an account has enabled. Specifically:

1. The Apps catalog should not accumulate in the JS heap across repeated app/list calls.
2. app/list should not fire ~130 times per re-initialisation, and MCP child restarts should not trigger a full catalog re-broadcast storm.
3. A V8 OOM in the browser process should surface to the user rather than vanishing silently.

Reproduction

Not reliably reproducible on demand, but strongly correlated with:

• a large number of enabled ChatGPT connectors (300+ tools in codex_apps)
• long-running sessions with several open threads
• MCP servers configured (4 here: 2 stdio, 2 streamable HTTP)

Crash rate on this machine is currently ~4/day at 332 tools, and was ~9/day at 473 tools.

Related

• #24397 — startup blocks on eager MCP/App connector initialisation
• #21134 — renderer/app-server memory growth and TRACE log churn on long threads
• #38176 — renderer excessive memory
• #21326 — renderer high CPU, re-render/reconciliation loops
• #36971, #19540, #14666, #11984, #20573 — related memory reports

None of these identify the V8 heap OOM in owl/common/node_bindings.cc or the correlation with connector catalog size.

What steps can reproduce the bug?

Feedback ID: no-active-thread-01a08951-e615-7561-9c95-449926a9195d

What is the expected behavior?

No response

Additional information

No response

Start by reading owl/common/node_bindings.cc around the reported V8 OOM log, then trace the app/list calls and mcp-extension-sidebar-catalog state mentioned in the report. Compare catalog behavior across repeated initialization and MCP child restarts using a large connector catalog. Done means the browser process no longer exhausts its V8 heap as catalog size grows and OOM failures do not vanish silently.