codex - 💡(How to fix) Fix Codex Desktop leaves orphaned zsh shell-snapshot processes burning ~100% CPU

Summary

Codex Desktop intermittently leaves orphaned shell snapshot subprocesses running under launchd. Each process is /bin/zsh -lc ... running Codex's shell snapshot capture command, and each burns roughly one full CPU core indefinitely until manually killed.

This appears distinct from existing CLI orphan/native-process issues because the runaway process is not the codex native binary or Node wrapper. It is the shell snapshot subprocess itself.

Environment

• Codex Desktop: 26.527.31326, build 3390
• Codex CLI/runtime version recorded locally: 0.133.0
• macOS: 26.5 (25F71)
• Architecture: arm64
• Shell: /bin/zsh
• App bundle: /Applications/Codex.app

Observed behavior

Multiple orphaned /bin/zsh processes appear with PPID 1, each consuming about 97-100% CPU.

Observed process command shape:

/bin/zsh -lc if [[ -n "$ZDOTDIR" ]]; then
  rc="$ZDOTDIR/.zshrc"
else
  rc="$HOME/.zshrc"
fi
[[ -r "$rc" ]] && . "$rc"
print '# Snapshot file'
print '# Unset all aliases to avoid conflicts with functions'
print 'unalias -a 2>/dev/null || true'
print '# Functions'
functions
...
setopt
alias -L
export -p

Concrete examples from this machine:

• 2026-05-30: four orphaned snapshot processes, each around 98-100% CPU for about 45-46 minutes, total roughly 400% CPU. Killing only those PIDs immediately improved CPU idle from about 36% to about 69%.
• 2026-05-31: two more orphaned snapshot processes:
  • PID 77383, about 97% CPU, running about 22 minutes
  • PID 4502, about 97% CPU, running about 8 minutes
• After killing those exact PIDs, pgrep -lf "print '# Snapshot file'" returned nothing and load average began dropping.

Diagnostics performed

The same shell snapshot pattern completes quickly when run directly with a hard timeout:

time perl -e 'alarm shift; exec @ARGV' 10 /bin/zsh -lc '[[ -r "$HOME/.zshrc" ]] && . "$HOME/.zshrc"; functions >/dev/null; setopt >/dev/null; alias -L >/dev/null; export -p >/dev/null; print ok'

Result: completed successfully in about 1s.

Snapshot files are being written under:

~/.codex/shell_snapshots/

Recent files included:

019e7a0e-5d2e-77a0-b27b-ecb6a3c1739f.1780213284925867000.sh
019e7cfc-2f3f-7ce3-aef9-e0aab975fba9.1780213362784461000.sh

This suggests the capture often reaches the output stage, but the subprocess may not exit or Codex may lose cleanup/ownership.

I also saw stale process-manager entries in:

~/.codex/process_manager/chat_processes.json

And archived Codex session output showed similar previously orphaned snapshot commands, including long-running examples.

Expected behavior

Codex Desktop should ensure shell snapshot subprocesses terminate promptly, and should kill/timeout them if snapshot capture hangs or if the parent session/thread is interrupted or restarted.

Actual behavior

Shell snapshot subprocesses can become orphaned under launchd and continue spinning indefinitely at about one CPU core each.

Impact

• Machine runs hot.
• Multiple orphaned snapshot processes accumulate across sessions.
• CPU usage can reach several full cores until manually cleaned up.

Related issues

These may be adjacent but appear to cover different process types/failure modes:

• #13928: Codex native binary persists after session exit and consumes CPU
• #14962: CLI orphan process pairs after terminal close/SIGHUP
• #10883: shell snapshot compatibility with runtime shell

Suggested next diagnostic

If this recurs, I can collect a sample before killing the process:

sample <pid> 5

That should identify where zsh is spinning.