Codex CLI: Background Process Leak + Missing Job Control #7932

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