Codex Desktop leaves orphaned zsh shell-snapshot processes burning ~100% CPU

Confirmed this is a thing on my machine. The fan was on for no reason, I checked and there were 5-7 zsh processes that had to be killed manually.

Same issue from the CLI

I hit the same problem through Codex CLI on macOS, not the desktop app. Here is what I found:

• MacBook Pro M1 Pro, macOS, zsh
• Incident: Codex CLI 0.145.0
• Now running: Codex CLI 0.146.0
• Eleven snapshot zsh processes passed my full identity checks. One earlier pilot was verified separately from its PPID, TTY, children, command shape, and snapshot markers.

One process had been using most of a core for more than an hour:

PID       PPID TTY  %CPU ELAPSED  COMMAND
69976        1 ??   78.1 01:25:08 /bin/zsh

What helped

• I revalidated each matching PID immediately before sending an individual SIGTERM to that exact process.
• Result: matched=11 skipped=0 terminated=11 survived=0. The pilot had already been terminated separately.
• The next scan found zero matches. CPU idle recovered to 84.12%, then 92.7%.
• For noninteractive shell startup, I changed NVM loading to:

source "$NVM_DIR/nvm.sh" --no-use

Interactive NVM still works, and I have not seen new matches since making this change. That does not prove NVM caused the issue, and it does not fix Codex cleanup.

What may be happening

• The released 0.146.0 shell_snapshot path, and the version on current main, still use setsid(), kill_on_drop(true), and a timeout without explicitly cleaning the process group.
• Process-group cleanup already exists elsewhere in 0.146.0.
• The released 0.146.0 timeout test checks that the direct shell PID disappears, but not a child it has forked.

This fits the failure, although a descendant must exist when the timeout occurs.

What I think Codex should change

• Terminate the whole snapshot process group on timeout and cancellation.
• Add a regression test that forks a sleeping child and verifies that both processes are gone.

I have a cleanup tool and isolated Tokio reproducer, and can share either to validate a fix

Additional confirmation with process-group and stack evidence

I can confirm this is still reproducible on a newer Codex Desktop build, and the evidence strongly supports the process-group cleanup explanation in the previous comment.

Environment

• Codex Desktop: 26.730.61639, build 6234
• Embedded Codex runtime reported in local logs: 0.147.0
• macOS 26.5.2 (25F84), arm64
• zsh with NVM 0.39.0
• App bundle on this installation: /Applications/ChatGPT.app, bundle id com.openai.codex

PID/PGID timeline

Two incidents were correlated from Codex's SQLite logs, macOS unified logs, ps, and lsof:

14:29:39.935  snapshot zsh group leader 50222 starts
14:29:42      descendant zsh 50933 starts in PGID 50222
14:29:49.923  codex_core::shell_snapshot logs:
                "Snapshot command timed out for zsh"
14:29:49.932  group leader 50222 exits

14:29:40.290  snapshot zsh group leader 50244 starts
14:29:42      descendant zsh 50934 starts in PGID 50244
14:29:50.276  second shell snapshot timeout
14:29:50.285  group leader 50244 exits

Afterward:

PID    PPID  PGID   STATE  CPU
50933  1     50222  R      ~94-100%
50934  1     50244  R      ~98-100%

The original group leaders no longer existed, but the surviving processes retained their dead leaders' PGIDs. Both had no TTY, stdin was /dev/null, and stdout/stderr were pipes whose reader ends no longer existed. The Codex backend process that launched the snapshots was still running, so reparenting did not require a full app exit or restart.

This looks like: the timeout kills the direct shell/group leader, a zsh descendant created during shell initialization survives in the same process group, and the kernel reparents that descendant to PID 1.

CPU stack

A 3-second native sample of one survivor collected 2,452 stack samples:

• 2,208 samples (~90%) were in zsh execwhile
• the stack included script sourcing, shell-function execution, command substitution (getoutput), and a shell while loop
• 738 top frames were sigprocmask
• 471 top frames were stat
• lsof showed the process still had both .zshrc and .nvm/nvm.sh open
• there were no samples in write, poll, kevent, functions, alias, or export

The hottest path is therefore a zsh loop during NVM initialization, before the snapshot reaches the functions/aliases/exports output phase. The strongest candidates are NVM's upward path-search functions such as nvm_find_project_dir or nvm_find_up, but the native stack does not expose the exact shell function name, so that part remains unconfirmed.

The closed output pipes appear to be a consequence of the timeout, not the cause of the CPU spin.

Recurrence and output-size evidence

At the time of inspection:

• 58 zsh snapshot timeouts had been logged that day across 32 distinct thread IDs
• 10 orphan snapshot zsh processes were simultaneously consuming roughly one core each
• failures occurred across ordinary user tasks and internal/background tasks, not one specific session
• other snapshots on the same machine succeeded in about 2 seconds and produced approximately 250 KB / 9,833 lines
• manually sourcing the same .zshrc completed in about 5 seconds, and isolated functions, setopt, aliases, and exports checks all exited successfully

This argues against machine performance, snapshot output size, or an unconditional .zshrc infinite loop as the primary cause.

Interpretation

The NVM loop is an environment-dependent trigger for the 10-second timeout, but the persistent orphan/high-CPU behavior is a Codex lifecycle bug: timeout/cancellation cleans up the direct child but not all descendants in the snapshot process group.

A regression test that has the snapshot shell fork a busy or sleeping descendant, then verifies that both the leader and descendant are gone after timeout/cancellation, should cover this failure mode.