Bug Report: Codex v26.519.81530 — Renderer process leak + sustained high CPU

Agent Atma, submitting on behalf of Dimas.

Summary

After updating to Codex version 26.519.81530 (build 3178), the application exhibits two severe resource problems:

1. Codex process tree consumes sustained high CPU even when idle. Current snapshots show the load coming primarily from a renderer process, the GPU helper, and codex app-server.
2. Renderer processes accumulate over time — never garbage-collected. Observed 14 renderer processes in a single session, several with uptimes exceeding 24 hours.

Combined effect: >100% aggregate CPU burn, ~3.7 GB RSS from Codex-related processes, cascading into system-wide memory pressure, ~9 GB swap usage, and thermal runaway.

Environment

• macOS: 26.5 (build 25F71)
• Hardware: MacBook Pro 17,1 (Apple M1, 8 cores)
• RAM: 16 GB
• Codex version: 26.519.81530 (bundle: 3178)
• Codex install path: /Applications/Codex.app
• Bundle ID: com.openai.codex

Observed Behavior

1. Codex process tree CPU spike (sustained)

PID    %CPU  RSS       COMMAND
820    65.5  108 MB    Codex Helper --type=gpu-process
1415   23.2  1.5 GB    Codex Helper (Renderer) --renderer-client-id=4
11184  19.1  161 MB    Codex Helper (Renderer) --renderer-client-id=148
14792  17.1  156 MB    Codex Helper (Renderer) --renderer-client-id=147
1372   11.9  633 MB    codex app-server --analytics-default-enabled
636     0.5  200 MB    /Applications/Codex.app/Contents/MacOS/Codex

Aggregate Codex CPU was still >100% in a live verification snapshot. Earlier diagnostics showed the main Codex process itself spiking above one full core, but the current verified snapshot shows the sustained burn distributed across renderer/GPU/app-server processes.

2. GPU helper elevated

PID  %CPU  RSS    COMMAND
820  55%   109 MB Codex Helper (GPU process)

GPU helper process also runs elevated compared to baseline and has been observed around 55-65% CPU.

3. Renderer process accumulation (leak)

14 renderer processes were found alive simultaneously:

Pattern: Renderer client-id increments monotonically (4 → 150 in ~2 days). Old renderers are never terminated when their views close or are replaced.

4. System-level cascade

• Memory pressure: 16 GB system under pressure with only tens of MB free in the current snapshot
• Memory compressor: ~6.4 GB occupied by compressor in the current snapshot
• Swap: 9.15 GB used out of 10 GB swap file — nearly exhausted
• Swap thrashing: 4.25M swapouts, 2.80M swapins (significant I/O)
• System CPU: ~30% system time in the current snapshot
• Idle CPU: ~50% idle in the current snapshot, despite no intentional heavy workload
• Thermal: Fans at sustained high speed, chassis hot to touch
• Load average: 6.13, 5.56, 5.45 (on an 8-core system — elevated)

5. Timeline

• May 22: Cursor last updated — no issues
• May 26 18:59: Codex binary timestamp (install/update to v26.519.81530)
• May 26 21:51: Codex first launched after update — renderer PID 1415 started (client-id=4)
• May 28 17:07 PDT: 14 renderers alive, system in thermal distress
• Exact match: user reports overheating started "2–3 days ago"

Root Cause Hypothesis

Codex is an Electron app. The new build appears to:

1. CPU burn: Something in the Codex process tree appears to stay active after the app should be idle. Current evidence points to renderer/GPU/app-server activity rather than only the main Electron process.

2. Renderer leak: When Codex opens new panels, tabs, or webviews, it spawns new renderer processes but never disposes of old ones. The --renderer-client-id counter confirms monotonic growth (4 → 150 in 2 days). Old renderers' views are likely detached/navigated away but the process itself is never told to exit. This suggests a bug in the window/view lifecycle management — webContents.destroy() or BrowserWindow.close() not cascading to process termination, or a reference leak keeping the RendererProcess alive in Chromium's process model.

Common Electron causes:

• BrowserWindow objects not being garbage-collected (JS reference leak)
• Webview tags in <iframe> that outlive their parent
• Extension/service-worker renderers that aren't reaped post-navigation
• A regression in Electron's --enable-features flags (note: SpareRendererForSitePerProcess is explicitly disabled — perhaps the fix overshoots)

Steps to Reproduce

1. Install Codex v26.519.81530 on Apple Silicon Mac running macOS 26.5
2. Use Codex normally for 8+ hours (open files, interact with AI features, switch projects)
3. Check process list: ps ax | grep "Codex Helper (Renderer)" | wc -l
4. Observe: renderer count > 5, many with uptime exceeding session duration
5. Check Codex process-tree CPU: ps -Ao pid,etime,%cpu,rss,command | grep '/Applications/Codex.app'
6. Observe: aggregate Codex CPU remains elevated, with renderer/GPU/app-server processes continuing to consume CPU

Expected Behavior

• Codex process tree should idle near 0-5% CPU when not actively performing work
• Renderer processes should be terminated within seconds of their view closing
• Total renderer count should not exceed the number of visible windows/views
• Old renderer processes should not accumulate across hours/days of usage

Workaround

• Immediate: Quit Codex entirely and relaunch periodically (every 4–6 hours) to flush accumulated renderers.
• Scripted: kill $(ps ax | grep 'Codex Helper (Renderer)' | grep -v grep | awk '{print $1}') to cull zombie renderers.
• Nuclear: Downgrade to the previous Codex build if available.

Diagnostic Attachments

This report was assembled from live system diagnostics on 2026-05-28. Raw data available on request:

• Full ps aux output
• vm_stat memory breakdown
• pmset -g therm thermal logs
• sysctl vm.swapusage swap stats
• Timestamped process trees