Summary
Codex Beta Desktop can enter a runaway CPU state in the main app process after a large Computer Use-heavy thread. In this case, Activity Monitor showed the main Codex (Beta) process at ~286-293% CPU while no agent command/tool/build was visibly running.
Environment
- Codex Beta:
26.506.31421
- macOS:
26.5 (25F71)
- Machine: Apple Silicon Mac
- Repo/workspace at the time: local throwaway workspace, not running a build
What happened
- I used Codex Desktop with Computer Use to interact with the native WhatsApp macOS app.
- The thread accumulated many large
get_app_state outputs and screenshots/accessibility trees from WhatsApp.
- After the interaction stopped, Codex Desktop continued consuming very high CPU.
- Activity Monitor filtered to
codex showed the main Codex (Beta) process at ~286-293% CPU for multiple minutes.
- The supporting helpers (
codex, codex_chronicle, Computer Use helpers, renderers) were much lower. The hot process was the main app process.
Expected behavior
When no agent task/tool call/build is active, Codex Desktop should return to low idle CPU usage.
Actual behavior
The main app process stayed hot:
PID 69514
Process: /Applications/Codex (Beta).app/Contents/MacOS/Codex (Beta)
CPU at triggered capture: 292.9%
The triggered capture was taken while Activity Monitor showed the spike.
Evidence captured
I captured a diagnostic folder with:
triggered/ps-20260510-020509.txttriggered/top-20260510-020509.txttriggered/sample-pid-69514-20260510-020509.txtcodex-version.txtmacos.txt- Activity Monitor screenshots showing
Codex (Beta) around 286-293% CPU
The sample file shows the hot process is inside the Electron/V8/Node main app process. I am not attaching full local Codex databases or full conversation logs because they may contain private metadata.
Suspected trigger
This may be related to Codex Desktop rendering/diffing/maintaining a very large active transcript containing repeated Computer Use screenshots and accessibility-tree outputs. That is a hypothesis, not a confirmed root cause.
Notes
The local feature server, WhatsApp, Computer Use helper processes, and model inference were not the apparent hot process. The sampled hot process was the main Codex (Beta) app process itself.
codex-beta-cpu-triggered-diagnostics.zip
Summary
Codex Beta Desktop can enter a runaway CPU state in the main app process after a large Computer Use-heavy thread. In this case, Activity Monitor showed the main
Codex (Beta)process at ~286-293% CPU while no agent command/tool/build was visibly running.Environment
26.506.3142126.5 (25F71)What happened
get_app_stateoutputs and screenshots/accessibility trees from WhatsApp.codexshowed the mainCodex (Beta)process at ~286-293% CPU for multiple minutes.codex,codex_chronicle, Computer Use helpers, renderers) were much lower. The hot process was the main app process.Expected behavior
When no agent task/tool call/build is active, Codex Desktop should return to low idle CPU usage.
Actual behavior
The main app process stayed hot:
The triggered capture was taken while Activity Monitor showed the spike.
Evidence captured
I captured a diagnostic folder with:
triggered/ps-20260510-020509.txttriggered/top-20260510-020509.txttriggered/sample-pid-69514-20260510-020509.txtcodex-version.txtmacos.txtCodex (Beta)around 286-293% CPUThe
samplefile shows the hot process is inside the Electron/V8/Node main app process. I am not attaching full local Codex databases or full conversation logs because they may contain private metadata.Suspected trigger
This may be related to Codex Desktop rendering/diffing/maintaining a very large active transcript containing repeated Computer Use screenshots and accessibility-tree outputs. That is a hypothesis, not a confirmed root cause.
Notes
The local feature server, WhatsApp, Computer Use helper processes, and model inference were not the apparent hot process. The sampled hot process was the main
Codex (Beta)app process itself.codex-beta-cpu-triggered-diagnostics.zip