›_ Codex Issues
Codex Issues / #15620

High CPU usage when idle: background git/subprocess churn in Codex (Electron/Node) even when UI is inactive

Resolved 💬 5 comments Opened Mar 24, 2026 by michaeltyson Closed Apr 9, 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)?

Version 26.318.11754 (1100)

What subscription do you have?

200/month

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Codex exhibits sustained CPU activity while idle, even when:

  • no tasks are running
  • no user interaction is occurring
  • the app is not visible (fullscreen on another macOS Space)

A system trace shows the main thread is asleep in the AppKit run loop (waiting for events), with no rendering or UI activity. Despite this, background threads remain active.

The activity is concentrated in Electron/Node internals, with repeated subprocess management and stream handling. The trace shows frequent calls to:

  • uv_run, uv__io_poll, uv__wait_children
  • uv_spawn, posix_spawn
  • LibuvStreamWrap::OnUvRead, EmitToJSStreamListener::OnStreamRead
  • V8 lifecycle paths such as HandleWrap::OnClose and BackingStore::~BackingStore

There is also a dedicated git thread doing work.

This suggests Codex is repeatedly spawning subprocesses (likely git-related), reading their output, and tearing them down, even while idle.

No explicit error messages are shown; the issue is persistent background activity and CPU usage in an idle state.

What steps can reproduce the bug?

  1. Launch Codex
  2. Open a project/repository
  3. Ensure no active tasks are running
  4. Switch to another macOS Space (so Codex is not visible)
  5. Leave the app idle for a short period (e.g. 1–5 minutes)
  6. Observe CPU usage in Activity Monitor or sample the process

Optional (for verification):

  • Take a sample in Activity Monitor
  • Observe repeated subprocess activity (uv_spawn, posix_spawn) and stream handling even while idle

No specific code snippet is required; this occurs in normal usage with no prompts or active sessions.

Session/token/context details: not applicable (no active Codex session).

What is the expected behavior?

When Codex is idle and not visible:

  • CPU usage should drop close to zero
  • No repeated subprocess spawning should occur
  • Background activity should be minimal or fully suspended
  • The app should remain in a quiescent state until user interaction or an explicit task begins

Additional information

  • This appears to be backend (Electron/Node/libuv) activity, not a rendering issue; the UI thread is idle.
  • The pattern strongly suggests polling or supervision logic (likely git/repo-related) that continues running even when the app is inactive.
  • Memory usage observed: ~230 MB current, ~565 MB peak, consistent with allocation churn rather than steady-state usage.
  • The issue may be mitigated by:
  • suspending polling when the app is hidden or on another Space
  • replacing subprocess polling with event-driven mechanisms (e.g. filesystem watchers)
  • batching or caching repo state queries

Codex while totally idle (was consuming 50-60% CPU and making my M5 Pro MacBook Pro's fans run hard):
codex5.txt

Codex while working on 2 threads:
codex.txt

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 5 months ago

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

  • #14469
  • #13988

Powered by Codex Action

jerometremblay · 5 months ago

Check if you have a non-git folder with a lot of files, it causes codex to spam git commands on each files individually. (See #15631 )

michaeltyson · 5 months ago

Update: This is still an issue on Version 26.323.20928 (1173)

With the window hidden and nothing running, the main thread is idle, but Codex is still busy in the background. The trace shows:
• repeated V8Worker optimisation work in OptimizingCompileInputQueue::Prioritize 
• repeated uv_spawn / posix_spawn activity on the git worker
• continued JS callback / transfer / backing-store cleanup around that work

This looks like a persistent background work loop, not UI/rendering load. 

It did settle after a few minutes, but not without my MacBook Pro getting hot and spinning up its fans hard.

codex.txt

@jerometremblay Thanks for that. I do have a large project - 10k files or so - but I'm not sure there's much I can do about that. It's all under git anyway.

michaeltyson · 5 months ago

And just for completeness, here is a trace where Codex was working in two threads ("The git worker still looks pathological").

  • UI thread still is not the culprit. CrBrowserMain is mostly sitting in the normal event loop and mach_msg, which again argues against this being primarily rendering load. 
  • V8 optimisation churn is still very prominent. Multiple V8Worker threads are active in v8::internal::OptimizingCompileInputQueue::Prioritize, with some RunCompilationJob activity too. That is the same signature as before, just more pronounced while it is actively working threads. 
  • The git worker still looks pathological. This trace shows extremely heavy uv_spawn / posix_spawn activity, along with socketpair, fcntl, ioctl, setsockopt, and a very large amount of HandleWrap::OnClose callback cleanup. That strongly supports the same repeated subprocess spawn → stream/read → close cycle as before. 
  • JS/IPC/buffer churn is still present. There is continued OnUvRead / OnStreamRead activity, TransferData::FinalizeTransferWrite, BackingStore destruction, and other callback/cleanup paths, which fits the same model of subprocess output or worker IPC being pumped through JS with a lot of overhead. 

What is different in this trace is mostly degree:

  • The git worker looks even busier here than in the idle/backgrounded samples.
  • There are more active V8 worker samples.
  • The trace reads like the same machinery, but under a workload that keeps it continuously engaged rather than intermittently waking up. 

I should mention that there is nothing significant appearing in the console.

codex.txt

michaeltyson · 5 months ago

An update. On a hunch after @jerometremblay mentioned a non-git folder with a lot of files being a possible cause, I realised that I keep all my build products in a ".DerivedFiles" in the project root (and listed in .gitignore). Codex would occasionally create additional derived files folders, too, on its own initiative.

I tried moving these to a folder outside the project root for all my different worktrees and it looks like the problem may have gone away entirely. At least I haven't had the problem for a number of hours now.

So this indeed does look like Codex going rogue with git on stuff in the project root.