Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix CLI: /status orphan spins at 100% CPU with revoked stdio after interrupted turn on macOS [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#19958•Fetched 2026-04-29 06:24:42
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
VeechiYipVeechiYip
Participants
github-actions[bot]github-actions[bot]VeechiYipVeechiYip
Timeline (top)
labeled ×3commented ×1unlabeled ×1

Code Example

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

---

fd 0: (revoked)
fd 1: (revoked)
fd 2: (revoked)
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

The issue can be mitigated by manually killing the orphaned native child process or modifying the Codex code to handle revoked stdio and exit cleanly.

Guidance

  • Investigate the Codex code to determine why the native child process is not exiting when stdio is revoked, and consider adding a check for revoked stdio to trigger a clean exit.
  • Use the lsof and sample commands to verify that the issue is indeed caused by the native child process spinning in a tight loop around reading from revoked stdio.
  • Consider adding a timeout or a mechanism to detect and handle interrupted commands to prevent similar issues in the future.
  • Manually killing the orphaned process may provide a temporary workaround, but a more permanent solution will require modifications to the Codex code.

Example

No code snippet is provided as the issue requires modifications to the Codex code, which is not publicly available.

Notes

The issue appears to be specific to the CLI /status command and revoked stdio, and may not be related to existing reports of high-CPU usage caused by git metadata loops.

Recommendation

Apply a workaround by manually killing the orphaned process until a permanent solution can be implemented, as upgrading to a fixed version is not an option given the information provided.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

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

#task chaining#parallel task#integration issue#index setup#retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix CLI: /status orphan spins at 100% CPU with revoked stdio after interrupted turn on macOS [1 comments, 2 participants]