Codex Desktop (Windows): 浏览器进程在 V8 堆内存不足时终止; 连接器目录大小与崩溃率成正比

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 …