Codex CLI native process can remain orphaned/headless and spin at 100% CPU after session completes #28794

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   performance

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jun 17, 2026
2. github-actions commented on Jun 17, 2026

   

   github-actionsBot

   on Jun 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex CLI busy-loops at ~100% CPU after controlling PTY is deleted #28315
   • Codex Desktop leaves headless Playwright/Chrome workers running after session close, causing macOS replayd to stay at ~150% CPU #28352
   • Windows: codex mcp-server / app-server and their child MCP servers are never reaped (accumulate to hundreds over time) #28361

   Powered by Codex Action
3. mychaelconnolly commented on Jun 18, 2026

   

   mychaelconnolly

   on Jun 18, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Reviewed the suggested duplicates.

   #28315 looks like the closest match. It reports a native codex CLI process busy-looping around one full core after its controlling PTY/stdio became invalid, with the hot thread identified as codex-main. This issue is probably in the same failure family.

   I do not think #28352 or #28361 are exact duplicates of this report. They are related lifecycle/process-cleanup leaks, but the leaked or hot processes there are different layers:

   • Codex Desktop leaves headless Playwright/Chrome workers running after session close, causing macOS replayd to stay at ~150% CPU #28352: headless Playwright/Chrome workers and macOS replayd after visual/browser/computer-use sessions.
   • Windows: codex mcp-server / app-server and their child MCP servers are never reaped (accumulate to hundreds over time) #28361: Windows codex mcp-server / app-server and child MCP server accumulation.

   The novel evidence in this issue is narrower and points at the native Codex worker itself rather than only helper processes:

   • Reproduced on macOS with Codex CLI 0.140.0.
   • Hot process was the native codex child, not just MCP, Playwright, Chrome, or other helper descendants.
   • Process had no TTY and revoked stdio shape: fd 0/1 revoked, fd 2 /dev/null.
   • Process tree still had a parent node plus MCP/lazy-gate descendants, so this was not just a detached helper-only leak.
   • Matching session log had already recorded task_complete at 2026-06-16T22:32:24Z, but the native process remained alive and hot the next morning.
   • Native codex accumulated about 831 CPU minutes before killing only that stale tree returned CPU to idle.

   So I would treat this as either a macOS/Node-wrapper variant of #28315, or a follow-up to keep open until shutdown/stdio-invalid handling is confirmed for the native worker layer. If maintainers prefer one tracker, #28315 is the only suggested duplicate I would consider close enough.
4. mychaelconnolly commented on Jun 21, 2026

   

   mychaelconnolly

   on Jun 21, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Follow-up recurrence with a different symptom shape.

   On 2026-06-21, I hit another Codex lifecycle/resume failure while using the Claude-side codex@openai-codex plugin (codex-companion.mjs, plugin version 1.0.4) to run a rescue task against a local git checkout.

   This one did not present as an obvious hot orphaned native worker like the original report. Instead, a resumed Codex thread stopped producing output after completing normal read-only shell commands.

   Observed:

   • Job: task-mqnf26ko-fg5mbn
   • Kind: rescue
   • Codex session/thread: 019ee61c-7478-7662-a657-25eefd999f2c
   • Turn: 019ee8e7-da27-7880-b6ff-161ed5862300
   • Start: 2026-06-21T06:39:28.981Z
   • Last useful job update: 2026-06-21T06:39:46.149Z
   • Manual cancel: 2026-06-21T15:15:32.869Z
   • Duration before cancel: about 8h36m
   • Recovery: cancel stuck job, then start a fresh Codex session/thread.

   The important detail: the last observed shell commands were benign read-only inspection commands and completed successfully. The job then produced no verdict/output until manual cancellation.

   Sanitized log excerpt:

   [2026-06-21T06:39:46.100Z] Running command: /bin/zsh -lc "nl -ba <local-repo>/<source-file> | sed -n '<range>'"
   [2026-06-21T06:39:46.100Z] Command completed: /bin/zsh -lc "nl -ba <local-repo>/<source-file> | sed -n '<range>'" (exit 0)
   [2026-06-21T06:39:46.142Z] Running command: /bin/zsh -lc "nl -ba <local-repo>/<test-file> | sed -n '<range>'"
   [2026-06-21T06:39:46.200Z] Command completed: /bin/zsh -lc "nl -ba <local-repo>/<test-file> | sed -n '<range>'" (exit 0)
   [2026-06-21T15:15:32.868Z] Codex turn interrupt failed: no active turn to interrupt
   [2026-06-21T15:15:32.869Z] Cancelled by user.
   

   The companion status path kept reporting the job as running/verifying and later showed the cancelled job as:

   task-mqnf26ko-fg5mbn | cancelled | rescue | Codex Resume
   Duration: 8h 36m
   Codex session ID: 019ee61c-7478-7662-a657-25eefd999f2c
   

   I would separate this from the original high-CPU evidence:

   • Original #28794: native codex worker survived session completion, lost stdio/TTY, and burned CPU.
   • This recurrence: a resumed long-lived Codex session stopped returning a verdict after successful shell reads; status stayed running/verifying until manual cancel; fresh session recovered.

   Possible correlation: this happened on a heavily reused/resumed Codex session after many successful short rescue tasks. It may be a session/resume state-machine stall rather than a terminal/PTY busy-loop.