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

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

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

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

1. Sample the full Codex process tree:

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

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