Codex desktop app pegs CPU on macOS after latest update; fans surge and system lags even on small requests

Resolved 💬 7 comments Opened Apr 18, 2026 by hacksurvivor Closed Apr 18, 2026

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

What version of the Codex App are you using (From “About Codex” dialog)?

Latest version as of April 18, 2026 after updating the Codex desktop app on macOS. I do not have the exact build number in front of me.

What subscription do you have?

Pro (100 USD)

What issue are you seeing?

After updating to the latest Codex desktop app on macOS, the app appears to use very high local CPU even for very small requests. The machine’s fans ramp up aggressively, the whole computer starts lagging, and Codex becomes unexpectedly heavy to use.

In Activity Monitor, the Codex process was observed at about 276.5% CPU during a small request.

This did not feel normal before the update.

What steps can reproduce the bug?

Update the Codex desktop app to the latest version on macOS.
Open the Codex app.
Send even a small / simple request.
Observe Activity Monitor and overall system behavior.
CPU usage for Codex can spike very high (in my case around 276.5%), fans become very loud, and the whole Mac starts lagging.

What is the expected behavior?

Small requests should not cause runaway local CPU usage, loud fan ramping, or whole-system lag. Since model inference is remote, the desktop app should remain relatively light during normal use.

Additional information

Platform: macOS
Symptom started after updating to the latest Codex desktop app version.
Repro seems possible with very small requests, not just large tasks.
I have a screenshot from Activity Monitor showing the Codex process at 276.5% CPU.

If useful, I can follow up with the exact app version from the About dialog and additional system details.

View original on GitHub ↗

7 Comments

hacksurvivor · 3 months ago

Additional evidence from Activity Monitor on macOS:

The high CPU usage is not limited to the main Codex process. There are also multiple hot renderer helper processes.

Observed at the same time:

Codex Helper (Renderer) at about 118.8% CPU
Codex Helper (Renderer) at about 117.3% CPU
WindowServer at about 45.1% CPU
main Codex process at about 35.3% CPU

This suggests the regression may be concentrated in renderer / UI activity rather than only the main app process.

Combined with the earlier screenshot showing Codex at about 276.5% CPU, this looks like a desktop rendering/performance issue after the recent update, and it correlates with loud fan ramping and whole-system lag even on small prompts.

I can provide the exact app version and macOS version if needed.

github-actions[bot] contributor · 3 months ago

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

#18463
#18378
#18264

Powered by Codex Action

hacksurvivor · 3 months ago

Closing this out — fixed after the latest app update. gg wp

agplusman · 3 months ago

still screaming for me on latest version

happyf-weallareeuropean · 3 months ago

@agplusman for me is not plug spin hot but results similar
<img width="1057" height="136" alt="Image" src="https://github.com/user-attachments/assets/88dffc33-d194-42e1-8f83-e45898e4bbf9" />

feisha20 · 3 months ago

Why has such a serious issue occurred, and why doesn't the official team provide downloads for previous versions???

orangejam72 · 2 months ago

Reproducing on current build. Adding a concrete signal from the logs in case it helps:

System

Codex.app 26.422.21637 (Electron 41.2.0)
macOS 26.5 (25F5058e), Darwin 25.5.0
Apple M4 Pro

CPU / memory at peak (from ps aux)
| Process | %CPU | RSS |
|---|---|---|
| Codex (main) | 108% | 503 MB |
| Codex Helper (Renderer) | 122% | 1.98 GB |
| codex app-server | 1.3% | 44 MB |

App is idle — no open thread, no active turn — but both main and renderer sit at 100%+ indefinitely.

What's driving it: a tight idle-poll loop in the [git] [git-origins] worker.

Single 5-minute session log (~/Library/Logs/com.openai.codex/YYYY/MM/DD/codex-desktop-<uuid>-<pid>-t1-i1-*.log):

grep -c "worker-complete" → 13,879
That's ~27 events/second, sustained
99%+ of them are dirCount=0 elapsedMs=0 originCount=0 — nothing actually changed, nothing to resolve

Sample (from start of log):

2026-04-24T16:54:45.386Z info [git] [git-origins] worker-complete dirCount=0 elapsedMs=0 hostId=local originCount=0
2026-04-24T16:54:45.387Z info [git] [git-origins] worker-complete dirCount=0 elapsedMs=0 hostId=local originCount=0
2026-04-24T16:54:45.444Z info [git] [git-origins] worker-complete dirCount=0 elapsedMs=0 hostId=local originCount=0
2026-04-24T16:54:45.507Z info [git] [git-origins] worker-complete dirCount=0 elapsedMs=0 hostId=local originCount=0
... (every ~37 ms for the entire session)

Ruling out state-driven theories:

~/.codex/state_5.sqlite threads table: 0 rows (no saved threads)
~/.codex/config.toml: only [projects."$HOME"] trust_level = "trusted", nothing stale
Electron Local Storage leveldb: no workspace-path keys, no unexpanded "~" strings
One-off ENOENT: path does not exist: ~ warning on the very first tick, then never repeats — so this is not #13988

With essentially no local state to drive it, the 27 Hz poll rate looks like a code-level default rather than something clearable by clearing caches, wiping ~/.codex, or resetting workspaces. That also matches that users in this thread report no improvement from the usual reset workflows.

Tangent that may or may not be related: the very first worker-complete fired with dirCount=1 elapsedMs=1 resolved a workspace whose path was a literal "~" (unexpanded). Looks like something is passing the tilde straight to fs somewhere in worker.js — see stack: LY → ZZ.getStableMetadata → ZZ.getRepoRepository → ZZ.getWorktreeRepository. It doesn't cause the loop, but it's a separate path-expansion bug worth flagging.

Happy to share full (redacted) log files or run any extra diagnostics if useful.