Repository navigation
Codex Beta main process spins at ~290% CPU after large Computer Use thread #21987
Description
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_stateoutputs and screenshots/accessibility trees from WhatsApp. - After the interaction stopped, Codex Desktop continued consuming very high CPU.
- Activity Monitor filtered to
codexshowed the mainCodex (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.
Activity
github-actions commentedon May 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
thread-stream-state-changedsnapshots for completed long threads, causing extension-host/renderer CPU spikes #20781Powered by Codex Action
IgorGanapolsky commentedon May 12, 2026
I hit a similar shape while testing long Computer Use sessions. One thing worth separating in the diagnostic is whether the hot path is transcript rendering/state retention versus a still-running tool loop.
A useful capture set for this failure has been:
Codex (Beta)PID while hotps/topsnapshots for the main app, helper, and Computer Use helper processesget_app_stateaccessibility trees/screenshotsIf the same app build idles normally on a fresh thread but spins on the large Computer Use thread, that points more toward main-process transcript/render bookkeeping than macOS permissions or model work.
I keep a Mac agent workstation checklist here that may help people rule out the setup-layer causes before blaming the app process: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html
For anyone who wants the Mac setup audited instead of doing it manually, I packaged that as a fixed setup service too: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/