›_ Codex Issues
Codex Issues / #24991

Codex Desktop v26.519.81530 leaks renderer processes and causes sustained high CPU/memory pressure

Open 💬 2 comments Opened May 29, 2026 by dimasyankauskas

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:

| PID | Uptime | RSS | client-id | Notes |
|------|---------------|--------|-----------|-------|
| 1415 | 1d 19h | 1.5 GB | 4 | Original renderer — never reaped; currently CPU-active |
| 1449 | 1d 19h | 115 MB | 5 | Second renderer — never reaped |
| 27052| 1d 18h | 29 MB | 12 | Mid-session renderer |
| 68596| 1d 6h | 38 MB | 26 | Day-old renderer |
| 78803| 1d 0.5h | 33 MB | 52 | ~24h renderer |
| 2045 | 17h | 71 MB | 95 | 17-hour survivor |
| 82474| 22h | 66 MB | 87 | ~22h |
| 34386| 24h | 34 MB | 57 | ~24h |
| 99488| 21h | 60 MB | 88 | ~21h |
| 66456| 6h | 80 MB | 103 | Mid-session |
| 6704 | 5.5h | 78 MB | 140 | Recent |
| 14792| 4h | 156 MB | 147 | Recent; currently CPU-active |
| 11184| 1.5h | 161 MB | 148 | Recent; currently CPU-active |
| 11458| 29min | 86 MB | 150 | Newest |

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.
  1. 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

View original on GitHub ↗

2 Comments

jrn4z6vmwj-a11y · 8 days ago

Still reproducible on the current Codex Desktop build.

Environment:

  • Codex Desktop / ChatGPT app bundle: 26.814.41407 (build 6720)
  • Bundle ID: com.openai.codex
  • macOS 26.6 (build 25G72), arm64

Observed behavior:

  • Frequent recoverable UI beachballing during ordinary long-running local task work.
  • A live snapshot after about 28 hours of app uptime showed:
  • 70 processes whose command belongs to /Applications/ChatGPT.app, totaling about 2605 MiB RSS
  • 12 Codex (Renderer) processes, totaling about 1480 MiB RSS
  • 35 lingering cua_node/bin/node_repl processes, totaling about 234 MiB RSS
  • The largest renderer was about 430 MiB RSS.
  • There was no recent Codex .ips hang/crash report, so these appear to be UI stalls that recover rather than terminal crashes.

This extends the report to build 26.814 and suggests that renderer plus browser/computer-use worker lifecycle cleanup remains relevant. No raw logs, session transcripts, repository paths, or task content are attached.

rafamacedoo · 3 days ago

I am seeing a closely matching renderer-retention pattern on a newer ChatGPT/Codex Desktop build.

Environment:

  • ChatGPT/Codex Desktop 26.818.41509 (build 6962)
  • Bundled codex-cli 0.149.0-alpha.4.1
  • macOS 27.0 (build 26A5416b)
  • Apple Silicon with 24 GB unified memory

Live capture after approximately 28 hours of app uptime:

  • 44 Codex (Renderer) processes using approximately 5.93 GiB combined RSS
  • 55 processes in the ChatGPT parent plus direct-child process family, using approximately 7.04 GiB combined RSS
  • macOS footprint summary for ChatGPT, codex, Codex (Renderer) and Codex (Service): approximately 11 GB
  • 1 codex app-server direct child
  • Task inventory at capture: 3 active, 7 idle and 20 notLoaded Codex tasks
  • macOS swap used: approximately 3.97 GB

I also checked for the separate giant-rollout-file failure mode. The active session directory was 1.4 GB in total and the largest individual rollout was 111 MB, so there was no multi-gigabyte rollout file explaining the footprint.

Brave and Docker were also running, so Codex was not the sole contributor to system-wide memory pressure. However, the 44 long-lived renderers and the 11 GB Codex-family footprint were measured independently. The renderer count also increased from 43 to 44 during the diagnostic session.

I captured this state before performing a clean Codex restart so the process evidence would not be lost. I can provide a post-restart comparison or additional sanitised diagnostics if that would help isolate whether unloaded tasks, embedded panels or another renderer lifecycle path is retaining these processes.