›_ Codex Issues
Codex Issues / #19958

CLI: /status orphan spins at 100% CPU with revoked stdio after interrupted turn on macOS

Open 💬 3 comments Opened Apr 28, 2026 by VeechiYip
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.125.0

Which environment is this happening in?

  • macOS Darwin 25.4.0 arm64
  • Apple Silicon / Homebrew install
  • Node wrapper: /opt/homebrew/bin/codex
  • Native binary: @openai/codex-darwin-arm64/.../codex

What happened?

After an interrupted /status command, Codex left an orphaned native child process running indefinitely at about one full CPU core.

The live process tree looked like this:

23974     1 S      0.0   node /opt/homebrew/bin/codex /status
23975 23974 R    100.0   .../vendor/aarch64-apple-darwin/codex/codex /status

The process had been running for more than 30 minutes at ~100% CPU with no active terminal attached.

Evidence

lsof -p 23975 showed that standard streams were revoked:

fd 0: (revoked)
fd 1: (revoked)
fd 2: (revoked)

sample 23975 2 showed the main thread overwhelmingly in read from libsystem_kernel.dylib; Tokio worker threads were mostly parked/waiting. This looks like a tight loop around reading from revoked/closed stdio rather than useful work.

The corresponding session JSONL shows that the triggering user command was /status, and the turn was interrupted shortly after it started.

Expected behavior

If the parent session is interrupted or stdio is closed/revoked, the native Codex child should exit cleanly instead of spinning.

Actual behavior

The node wrapper becomes orphaned under PID 1, the native child remains in R state, and the child consumes ~100% CPU indefinitely.

Related but different existing reports

I found existing high-CPU reports around desktop/extension git metadata loops, but this stack appears different:

  • #18467 reports desktop app CPU from git-origins polling.
  • #18463 / #17394 report stable-metadata or git metadata loops.
  • This report is specifically CLI /status plus revoked stdio plus the native child spinning in read.

Notes

This happened on an upgraded, long-lived Codex environment rather than a fresh install. The local ~/.codex directory is large, but the live CPU culprit in this case appears to be the orphaned /status child with revoked stdio.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19945

Powered by Codex Action

VeechiYip · 4 months ago

Thanks for the duplicate pointer. I reviewed #19945. I think it may be related at the stdio/TTY lifecycle layer, but this report is not the same failure mode.

Key differences:

  • #19945 is about codex exec in a detached/no-controlling-TTY context on Linux, where the command exits successfully with 0 bytes of output.
  • This issue is about the interactive TUI path (codex /status) on macOS after an interrupted turn. The process does not exit; the node wrapper becomes orphaned under PID 1, the native child stays in R state, and the child consumes ~100% CPU indefinitely.
  • In this issue, lsof showed fd 0/1/2 as (revoked), and sample showed the native child main thread overwhelmingly in read. That points to a spin/hang after stdio is revoked, rather than a silent early exit.

So I am keeping this open unless maintainers confirm it is the same root cause as #19945 and prefer to track both under one issue. The common theme may be that recent CLI versions do not handle detached/revoked stdio consistently across subcommands and runtimes.

VeechiYip · 4 months ago

Adding a user-impact note, because this is more than a cosmetic CPU spike for me.

At the moment I effectively have to keep macOS Low Power Mode enabled when using Codex. If I turn Low Power Mode off, the machine heats up quickly and the fans spin hard.

The more frustrating part is that quitting Codex and closing the terminal is not enough. The orphaned native codex /status process can keep running in the background, so I still have to open Activity Monitor and manually stop that process.

That makes the failure mode easy to miss and fairly costly in day-to-day use, especially on battery.