Codex CLI busy-loops at ~100% CPU after controlling PTY is deleted

Summary

A stale Codex CLI process kept running after its controlling terminal disappeared and started consuming roughly one full CPU core. The process no longer had an active terminal, was not producing session logs, and did not appear to have active network connections. Diagnostics point to a codex-main thread busy-looping after stdin/stdout/stderr pointed at a deleted PTY.

This looks like the CLI is not treating EOF/EIO/error readiness from a detached PTY as a terminal condition, or is retrying it in a tight event loop.

Environment

• Codex CLI: codex-cli 0.139.0
• Binary path observed: ~/.codex/packages/standalone/releases/0.139.0-x86_64-unknown-linux-musl/bin/codex
• OS: Ubuntu 24.04.4 LTS
• Kernel: Linux 6.17.0-1013-gcp #13~24.04.1-Ubuntu SMP Thu Apr 16 02:10:24 UTC 2026 x86_64
• Invocation: codex --yolo

Observed state

A stale process was found:

PID 186204  codex --yolo
CPU ~98%-110%
Started Thu Jun 11 15:09:23 2026
cwd /home/xiongtengyan
parent 185390: bash --rcfile /dev/fd/63

Its stdio file descriptors pointed to a deleted PTY:

0 -> /dev/pts/0 (deleted)
1 -> /dev/pts/0 (deleted)
2 -> /dev/pts/0 (deleted)

The active CPU-consuming thread was:

TID 186447
comm: codex-main
state: R

Thread sample:

TID 186447 utime=14002634 stime=18633967 state=R comm=(codex-main)

The process was not writing new session content. Its session log file remained unchanged:

~/.codex/sessions/2026/06/11/rollout-2026-06-11T15-09-26-019eb73b-2317-7cc0-8455-be755ff32039.jsonl
size: 999070
mtime: 2026-06-11 15:30:58 +0000

There were no TCP sockets associated with the process at the time of inspection; only local UNIX sockets were open.

CPU / syscall evidence

A 2 second /proc sample showed high CPU time growth and extremely high read syscall growth:

sample start:
utime=14201888 stime=18685605
syscr: 243943917947

sample end, ~2s later:
utime=14201967 stime=18685719
syscr: 243963619706

That is approximately:

• utime + stime: +193 ticks in ~2 seconds, close to one CPU core
• syscr: +1,172,137 read syscalls in ~2 seconds

This suggests a tight read/event-loop retry path rather than normal model/API activity.

Expected behavior

When the controlling PTY disappears or stdin/stdout/stderr return EOF/EIO/error readiness, Codex should exit cleanly or back off without consuming a CPU core.

Actual behavior

The process survived terminal teardown and kept a codex-main thread spinning at roughly 100% CPU until manually terminated.

Workaround

Manually killing the stale process worked:

kill 186204

Notes

strace was not installed on this host, so I could not capture the exact syscall loop. The /proc data above should still narrow this down to a busy-loop around terminal/read/event handling after PTY deletion.