codex - 💡(How to fix) Fix Codex gets stuck in high-CPU idle state after extended use [2 comments, 2 participants]

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

26.422.71525 (2210)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Codex frequently ends up in a high-CPU / high-energy state after it has been open for some time, even when it is not visibly running any task.

From the user’s perspective, Codex appears idle: no active task is running, the app is not on screen, and I am not interacting with it. However, the laptop becomes very hot, the fans run loudly, battery life drops sharply, and Activity Monitor/top shows Codex using sustained CPU.

In the attached sample trace, Codex was sampled while it appeared idle. The process was:

Codex version: 26.422.71525 (2210) macOS: 26.4.1 (25E253) Process: /Applications/Codex.app/Contents/MacOS/Codex Physical footprint: 1.1 GB Peak physical footprint: 3.6 GB Launch time: 2026-04-30 09:45:26 +1000 Sample time: 2026-05-02 14:15:18 +1000

The sample shows substantial activity inside Electron / V8 / Node, including V8 worker threads, stream/event handling, buffer allocation/copying, and optimisation/compilation-related work, despite Codex having no visible active task. The main thread shows paths through uv_run / uv__io_poll / node stream callbacks / V8 function calls, and V8Worker threads show large amounts of work under v8::internal::OptimizingCompileInputQueue::Prioritize and v8::internal::compiler::CompilationDependencies::Commit.

There is no visible error message. The failure mode is runaway or sustained background CPU/energy use while the app appears idle.

What steps can reproduce the bug?

I do not yet have a deterministic minimal reproduction.

Observed pattern:

1. Launch Codex.
2. Use it normally for some time across one or more coding sessions.
3. Leave it open after work has completed.
4. At some later point, Codex appears idle and may not even be visible on screen.
5. The Mac becomes hot, fans run hard, battery drains rapidly.
6. Activity Monitor/top shows Codex continuing to consume significant CPU despite no active task.

This does not appear immediately after launching Codex. It seems to happen after extended use, possibly after a workspace/session has been active for some time.

I captured a macOS sample while Codex was in this state and have attached it.

Session id / context window / token usage: not available. The issue is observable at the app/process level after the interactive session has finished, rather than during a visible active generation.

What is the expected behavior?

When Codex is not running a task and is not being interacted with, it should return to a low-energy idle state.

Expected behavior:

Codex should not continue consuming sustained CPU after tasks have completed. Background file watching, git integration, terminal/pty handling, model/session bookkeeping, indexing, and UI/runtime tasks should be bounded and should quiesce. CPU use should drop close to idle when the app is inactive. The app should not cause the laptop to become hot, spin up fans continuously, or drastically reduce battery life while apparently idle. Memory use should not continue growing or remain excessive without an active task.

Additional information

This is happening frequently enough that I now have to watch for Codex becoming an energy drain and manually quit it. It makes the app difficult to leave open during normal development work.

The attached sample may be useful because it was taken while Codex appeared idle. It shows the process had been open for over two days, with a current physical footprint of 1.1 GB and peak footprint of 3.6 GB, and the active stacks appear dominated by Electron/V8/Node internals rather than a visible user task.

It would be useful if Codex exposed, logged, or reported what background subsystems are active when the app believes it is idle, for example file watchers, git polling, terminal/pty streams, indexing, source-map/cache processing, renderer tasks, or V8 worker activity. That would make this class of issue easier to diagnose.

sample.txt