Codex Desktop (macOS): renderer OOM crash loop (~5 min) with many concurrent threads — unbounded thread history retention, post-reload refetch storm, 170+ leaked renderer processes

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #34751
• #33786
• #33603
• #34685

Powered by Codex Action

Cross-linking supply-side evidence for the refetch storm documented here: in #33786 (and my duplicate #34915, now closed into it) there is a symbolized sample profile of what the app-server does to serve each of those thread/turns/list requests — it rebuilds the page by re-parsing the entire rollout JSONL:

codex_app_server::request_processors::thread_processor::build_thread_turns_page_response
codex_app_server::request_processors::build_legacy_api_turns_from_rollout_items
codex_app_server_protocol::protocol::thread_history::ThreadHistoryBuilder::handle_rollout_item

So the thread/turns/list×1,275 flood you measured is doubly expensive: the renderer re-ingests full histories (your OOM loop), and the app-server re-deserializes the complete rollout per request (on my machine: two live ~600 MB rollouts → steady ~210–228% CPU in the app-server from the first minute after launch).

One data point suggesting the same root defect has a second failure mode: my machine (26.715.72359 build 5718, macOS 26.5.2, arm64) runs few concurrent threads but two very large ones, and Crashpad shows no renderer loop — instead 7 sidecars since 07-18, all ptype:"browser", ~8–16 h apart, each matching a SIGABRT .ips with the #34213 signature (node::OOMErrorHandler → v8::ExternalMemoryAccounter::Update on the git worker thread). So: many medium threads → renderer OOM loop (this issue); few giant threads → main-process worker OOM. Both sit downstream of unbounded history rehydration, which #33786 measures on the server side.

Update: process-lifecycle leak confirmed from a second angle — helpers survive full app quit, some for 4–5 days.

After fully quitting the app (verified: 0 Codex (Renderer) processes, main ChatGPT process gone), these were left behind, all reparented to launchd (ppid 1):

• 41 orphaned cua_node kernel processes (cua_node/bin/node --experimental-vm-modules .../kernel.js), ~0.8 GB RSS combined, with uptimes of up to 5 days 7 hours — i.e. they have been surviving app quits/relaunches for days, not just this session.
• 14 orphaned browser_crashpad_handler processes from Codex Framework.framework/Versions/150.0.7871.124/Helpers/, including some 5+ days old.

So in addition to the renderer accumulation reported above (172 live renderers after ~15 h inside a running session), Computer Use kernels and crashpad handlers are never reaped on app exit either. Expected behavior: quitting the app should terminate or reap its helper process tree.

Quitting did release everything else: ~17.8 GB of renderer RSS and the 4.4 GB / ~180% CPU app-server were reclaimed; system free memory went from 55% to 76%.

Update: controlled restart experiment quantifies the causal chain — the renderer-process leak is workload-driven and is what re-arms the OOM loop.

After a full quit (which reclaimed everything per my previous comment), I relaunched and instrumented the fresh session (30 s sampling of RSS/process counts, plus a watcher on Crashpad pending/).

Phase 1 — light load (first hour): main-window renderer survived the entire hour with the same PID. RSS ranged 1.3 → 3.5 GB peak → recovered to 2.5 GB (GC reclaimed >2 GB when streaming paused). System memory 76% free, swap quiet. Renderer count crept 21 → 26 (~5/hour). Zero renderer crashes. So the renderer's memory use is recoverable when the system has headroom — the multi-GB peak alone is survivable.

Phase 2 — agent farm resumed (~2.5 h, ~16 concurrent conversations streaming):

• Renderer process count: 26 → 159 (~50+/hour under load; the leak scales with thread/tool activity, not wall-clock time), total renderer RSS 18.6 GB
• System free memory: 76% → 25%; swap 8 GB volume ~90% used
• Renderer crashes resumed (2 in 50 min; ptype: renderer sidecars at 11:04 and 11:54 local), main-window renderer dead after 3.5 h total
• Replacement renderer reached 2.35 GB within 85 s of spawn (~28 MB/s) from the post-reload resume/refetch of all threads

So the measured chain is: concurrent-thread activity → leaked renderer processes accumulate → system memory/swap exhaustion → main renderer can no longer absorb its own 3–3.5 GB peaks → OOM crash → thread/turns/list refetch storm rebuilds at ~28 MB/s → repeat every few minutes. Fixing renderer reaping alone would likely break the loop, since Phase 1 shows the renderer survives its peaks when the system has headroom.

Separate crash mode captured (distinct bug, happy to file separately): one un-uploaded minidump from this session was not a renderer at all — ~/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService crashed with EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE 232 bytes past a 543 KB worker-thread stack limit (stack overflow), on a thread alongside AXNotificationObserver threads observing Microsoft Outlook — i.e. unbounded recursion while walking a large accessibility tree. Matching SkyComputerUseService-*.ips reports exist from Jul 19/20/22.

@zaptrem Thanks — the rollout re-parsing profile slots right into our measurements: the steady ~170–180% app-server CPU we logged (4.4 GB RSS after 17 h) is well explained by re-deserializing complete rollouts for each of the 1,275 thread/turns/list calls we counted in a 2,000-RPC window.

Our setup is the "many medium threads" shape (10–16 concurrent conversations, multi-MB histories each), and every crash sidecar we've inspected is ptype: "renderer" — none browser — which is consistent with your two-failure-mode split: many medium threads overwhelm the renderer first; few giant threads hit the main-process git worker's external-memory accounting first (#34213). Both downstream of unbounded history rehydration.

One addition from our data: rehydration volume alone didn't kill the renderer when the system had headroom (it peaked at 3.5 GB and GC'd back to 1.3 GB during a light-load hour). It's the leaked renderer processes (26 → 159 in 2.5 h under load, 18.6 GB) exhausting system memory that turns the same peaks fatal. So renderer reaping + incremental/paginated turn serving would likely each independently break the loop.

Update: This regression has accelerated with recent Codex Desktop updates. On the current macOS build (26.727.51351), renderer crashes/reloads now recur every 2–3 minutes during active use, making the application nearly unusable. The main app process remains alive while the window blanks and reloads, and Crashpad continues to show renderer failures. This is materially worse than the earlier ~3–5 minute cadence.