Codex Desktop v26.527.30818 sustained main-process CPU burn after update

Open 💬 4 comments Opened May 29, 2026 by dimasyankauskas

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug Report: Codex v26.527.30818 — sustained main-process CPU burn after update

Report from Agent Atma on behalf of Dimas.

Executive Summary

After updating Codex Desktop from v26.519.81530 to v26.527.30818 (build 3370) on 2026-05-29, the resource issue reported previously remains reproducible and appears more severe in the current live sample.

The current build shows sustained high CPU in the main Codex process, not only renderer/helper processes. The main process was observed around 157-198.5% CPU for more than 50 minutes after launch, with main-process RSS around 1.0-1.5 GB and aggregate Codex-related RSS around 4.0 GB.

This update also changed the app runtime from Electron Framework.framework to Codex Framework.framework v148.0.7778.179. That framework change did not resolve the resource defect; the dominant symptom has shifted to sustained main-process CPU burn.

Environment

macOS: 26.5 (build 25F71)
Hardware: MacBook Pro 17,1 (Apple M1, 8 cores)
RAM: 16 GB
Codex version: 26.527.30818
Codex build: 3370
Codex Framework: 148.0.7778.179
Bundle ID: com.openai.codex
Install path: /Applications/Codex.app

Severity

This is a high-severity desktop resource regression:

Sustained CPU burn continues when the app should be near idle.
The main app process alone consumes roughly 1.5-2 CPU cores in live samples.
Aggregate Codex-related CPU remains above 200% in verification snapshots.
Memory pressure remains significant, with aggregate Codex-related RSS around 4 GB.
The issue compounds with system services such as syspolicyd and WindowServer, making the machine noticeably degraded.

Confirmed Evidence

Live verification on 2026-05-29 around 14:30 PDT:

PID    ELAPSED  %CPU    RSS       COMMAND
42126  55m      157.5   1.49 GB   /Applications/Codex.app/Contents/MacOS/Codex
42702  55m       1.6    0.85 GB   /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
456    18h      131.3   0.24 GB   /usr/libexec/syspolicyd
404    18h       50.8   0.06 GB   WindowServer

Earlier in the same validation window, the main Codex process was sampled at:

PID    %CPU    RSS       COMMAND
42126  189.6   1.08 GB   /Applications/Codex.app/Contents/MacOS/Codex
42126  198.5   1.01 GB   /Applications/Codex.app/Contents/MacOS/Codex

Aggregate Codex process-tree sample:

aggregate_cpu=217.5%
aggregate_rss=4027.6 MB

System load remained elevated:

load averages: 6.68 10.18 8.65

Version And Runtime Change

The installed app reports:

CFBundleShortVersionString: 26.527.30818
CFBundleVersion: 3370
Codex Framework: 148.0.7778.179

The installed framework path confirms the runtime change:

/Applications/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/148.0.7778.179

The framework metadata reports:

CFBundleIdentifier: com.openai.codex.framework
CFBundleShortVersionString: 148.0.7778.179
CFBundleVersion: 7778.179

Comparison With Prior Build

| Metric | v26.519.81530 prior diagnostics | v26.527.30818 current diagnostics | Notes |
|---|---:|---:|---|
| Main Codex CPU | ~107% in prior sample | ~157-198.5% | Worse in current sample |
| Main Codex RSS | ~633 MB in prior sample | ~1.0-1.5 GB | Higher in current sample |
| Aggregate Codex RSS | ~3.7 GB | ~4.0 GB | Still very high |
| Load average | ~6.9 short-term | ~6.6-9.5 short-term observed | Still elevated |
| Runtime framework | Electron 42.x | Codex Framework 148.0.7778.179 | Runtime changed |
| Swap used | ~9 GB before restart | ~3.4 GB after restart/update | Lower due to restart effect, not necessarily a fix |

Observed Behavior

1. Main process consumes roughly 1.5-2 CPU cores

The current dominant issue is no longer just renderer accumulation. The main executable at /Applications/Codex.app/Contents/MacOS/Codex remains CPU-hot for an extended period.

This is not a short startup spike in the observed session. The same main-process PID was still consuming high CPU after more than 50 minutes of runtime.

2. Codex process tree remains memory-heavy

The main process RSS is around 1.0-1.5 GB, and aggregate Codex-related RSS is around 4.0 GB. That is high for an app that should be mostly idle.

3. Framework update did not resolve the resource defect

The previous build showed severe renderer/process-tree CPU and memory pressure. The new build changes the runtime framework and now shows severe sustained main-process CPU burn. This suggests the issue persisted across the runtime change and may have shifted location within the process architecture.

4. System services are also hot in the same window

syspolicyd was observed between roughly 35% and 131% CPU in the same validation window. This may be related to validating or scanning updated app binaries, but that causal link is not confirmed. It should be treated as a correlated system impact, not as proven root cause.

WindowServer was also elevated, around 40-50% CPU in samples.

Root-Cause Hypothesis

The evidence points to a persistent high-frequency loop or work source in the main Codex process after the v26.527.30818 update.

Plausible areas for internal investigation:

main-process event loop or message pump repeatedly waking instead of blocking
IPC path between the main process, app server, and renderer processes
telemetry, accessibility, screen-capture, or file-monitoring work scheduled too frequently
framework-level regression in Codex Framework v148.0.7778.179
post-update validation or startup work that does not quiesce

This report does not claim a specific root cause. The actionable finding is that the main process remains hot long after launch and should be profiled with Instruments/sample traces.

Steps To Reproduce

Install or auto-update to Codex Desktop v26.527.30818 on Apple Silicon macOS 26.5.
Launch Codex.
Let the app remain open after startup.
Sample the main process:

ps -p "$(pgrep -x Codex)" -o pid,etime,%cpu,rss,comm

Sample the full Codex process tree:

ps -Ao %cpu,rss,command | grep '/Applications/Codex.app'

Observe sustained high CPU in /Applications/Codex.app/Contents/MacOS/Codex, with aggregate Codex CPU above 200% in the reported session.

Expected Behavior

Main process should settle near idle after startup.
Codex process tree should not sustain multi-core CPU use without active work.
Main-process RSS should not climb above 1 GB in an idle or near-idle state.
Updating the runtime framework should not leave the desktop app in sustained CPU burn.

Actual Behavior

Main process remains around 157-198.5% CPU after launch.
Aggregate Codex process-tree CPU remains above 200% in verification snapshots.
Aggregate Codex RSS remains around 4 GB.
System load remains elevated, with syspolicyd and WindowServer also hot in the same window.

Temporary Workaround

The only reliable local workaround is to quit Codex completely and relaunch. In severe cases, force-quit all Codex processes:

pkill -f '/Applications/Codex.app'

This is a mitigation only; the issue reappears after relaunch/update in the observed session.

Diagnostic Data Available

The following diagnostics were collected locally and can be provided in redacted form:

ps aux sorted by CPU
timestamped process tree snapshots
vm_stat
sysctl vm.swapusage
pmset -g therm
bundle and framework metadata from app Info.plist
framework path and version verification

No private project paths, usernames, tokens, secrets, or raw session identifiers are included in this report.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

#24991
#23849
#24185
#25036
#25077

Powered by Codex Action

dimasyankauskas · 3 months ago

Thanks. I reviewed the linked issues. This is related to the broader Codex Desktop CPU/GPU/performance cluster, including #24991, but I believe #25159 adds distinct regression evidence for the newer v26.527.30818 build.

The key difference is that after the update to v26.527.30818 / build 3370, the dominant load shifted to the main Codex process itself, sustained around 157-198.5% CPU for 50+ minutes, with the app now using Codex Framework 148.0.7778.179 rather than the earlier Electron Framework path.

So this may be best treated as either:

a regression datapoint on the same underlying performance bug, or
a follow-up to #24991 showing the issue persists/worsened after the framework update.

Happy to close or consolidate if maintainers prefer one canonical issue, but leaving this open for now because it contains newer-version evidence.

dimasyankauskas · 3 months ago

Additional debug evidence from the same affected session:

I captured a 5-second macOS sample of the hot main Codex process. The main thread is spending most sampled time inside Codex Framework servicing Node/libuv stream reads into JavaScript callbacks, rather than simply idling in the native app event loop.

Process: Codex [42126]
Version: 26.527.30818 (3370)
Physical footprint: 1.4G
Physical footprint (peak): 2.9G

uv__io_poll
  node::LibuvStreamWrap::OnUvRead
    node::StreamBase::CallJSOnreadMethod
      node::AsyncWrap::MakeCallback
        v8::Function::Call

I also found stale node_repl / codex app-server --listen stdio:// helper pairs in the same session. Terminating only those stale helper pairs reduced aggregate Codex CPU, but did not resolve the core issue:

Before stale-helper cleanup:
aggregate_cpu >200%

After stale-helper cleanup:
aggregate_cpu=136.6%
main Codex process=108.5%
stale helper pairs=0

So stale helper accumulation appears to contribute to process-tree pressure, but the main-process CPU burn persists independently and still needs a product-side fix.

dimasyankauskas · 3 months ago

Additional context and candidate fix areas:

I’m a heavy Codex user because I resonate with OpenAI’s broader direction for AI. I’ve moved a meaningful part of my daily development and product workflow here, so I’m sharing this from sustained real-world use.

I really want this to work for daily use, and I’m motivated to help make it better.

The local sample evidence shows the hot main-process path repeatedly going through Node/libuv stream reads into JavaScript callbacks:

uv__io_poll
  node::LibuvStreamWrap::OnUvRead
    node::StreamBase::CallJSOnreadMethod
      node::AsyncWrap::MakeCallback
        v8::Function::Call

Based on that, candidate areas to investigate:

Main-process stream/event handling

Check whether high-volume app-server/helper events are being drained directly on the main process without enough batching, backpressure, or yielding.
If so, batch/coalesce events or move high-volume stream processing off the main/UI process, posting only UI-relevant state deltas back.

Helper/session lifecycle cleanup

I found stale node_repl / codex app-server --listen stdio:// helper pairs accumulating.
Killing only those stale helpers reduced aggregate Codex CPU from >200% to ~136%, but main-process CPU remained ~108%.
That suggests stale helpers amplify process-tree pressure, while the main-process hot loop persists independently.
Each helper/session likely needs a clear owner lifecycle, heartbeat/timeout, and deterministic teardown when a thread/workspace/session closes.

Suggested validation:

Add an idle regression test that opens/closes multiple Codex sessions, waits 5-10 minutes, then asserts:
no orphaned node_repl or codex app-server --listen stdio:// children remain;
main Codex process settles below an idle CPU threshold;
renderer/helper count returns to expected baseline;
aggregate RSS does not keep climbing.
Compare Instruments/sample traces before and after the fix to confirm the main process is no longer dominated by the uv__io_poll -> OnUvRead -> MakeCallback path.

My read is that this may involve both helper lifecycle cleanup and main-process event-stream backpressure, but I am framing that as an investigation path rather than a confirmed root cause.