Codex CLI: Background Process Leak + Missing Job Control

What feature would you like to see?

Summary

Codex CLI currently has a critical issue with background process handling when an ongoing task is interrupted. In addition, the CLI lacks a transparent way to manage long-running or background commands.

This issue can lead to runaway processes that are difficult to stop and significantly harms trust in the tool.

---

Concrete example (real usage case)

In one session, Codex CLI was running a uv-based crawler that repeatedly launched Chrome instances for scraping.

I decided to stop the task and exited the interaction using Esc to interrupt the Codex session.

Observed behavior:

• The Codex CLI interaction stopped
• However, the underlying crawler process continued running in the background
• Chrome pages kept opening repeatedly
• The process was difficult to identify and terminate manually
• From the user’s perspective, the task was effectively “out of control”

This is particularly dangerous for tasks that:

• Spawn browsers (Chrome / Playwright / Puppeteer)
• Perform filesystem mutations
• Consume significant CPU / memory
• Run network-heavy crawlers or agents

---

Expected behavior

When a Codex session is interrupted (Esc / Ctrl-C / cancel):

• All child processes spawned by Codex should be terminated
• No orphaned background processes should remain
• The system should respect the user’s explicit intent to stop execution

At minimum, the user should be clearly informed if something continues running in the background.

---

Root cause (likely)

This appears to be a process lifecycle / signal propagation issue, possibly:

• Child processes not attached to a process group
• Interrupt signals not forwarded to spawned commands
• No centralized job tracking within the CLI

---

Feature request: Explicit background command management

Rather than allowing implicit, invisible background execution, I strongly suggest adding first-class job control to Codex CLI.

Proposed design (one possible approach):

• When Codex runs a long-lived command:

• It is registered as a “job”
• Active / background jobs are displayed below the input prompt
• Users can:

• Press ↓ to focus the job list
• Press Enter to inspect / stop / kill a job
• Jobs should show:

• Command name
• Runtime duration
• Status (running / paused / completed / failed)
• Interrupting a session should:

• Either stop all jobs by default
• Or explicitly ask whether to keep them running in background

This would:

• Make execution transparent
• Prevent accidental runaway processes
• Align Codex CLI with expectations from mature CLI tools (e.g. job control in shells, task panes in modern TUI tools)

---

Why this matters

Codex CLI is positioned as an agentic, long-running automation tool.

Invisible background processes that survive session interruption:

• Break user trust
• Violate intent
• Create real system risk

Introducing proper job control would be a major step toward making Codex CLI production-grade rather than “fire-and-forget”.

---

Happy to provide more examples if helpful.

Additional information

_No response_