Repository navigation
CLI: /status orphan spins at 100% CPU with revoked stdio after interrupted turn on macOS #19958
Description
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:
- Codex desktop app pegs CPU on macOS after latest update; fans surge and system lags even on small requests #18467 reports desktop app CPU from
git-originspolling. - sustained high CPU after launch/reopen (persists during use) + model picker broken #18463 / VS Code extension: high renderer CPU in non-git workspace caused by repeated git stable-metadata worker loop #17394 report
stable-metadataor git metadata loops. - This report is specifically CLI
/statusplus revoked stdio plus the native child spinning inread.
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.
Activity
github-actions commentedon Apr 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
VeechiYip commentedon Apr 29, 2026
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:
codex execin a detached/no-controlling-TTY context on Linux, where the command exits successfully with 0 bytes of output.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 inRstate, and the child consumes ~100% CPU indefinitely.lsofshowed fd 0/1/2 as(revoked), andsampleshowed the native child main thread overwhelmingly inread. 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 commentedon Apr 30, 2026
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 /statusprocess 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.