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

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.