Summary
This issue collects several related discussions around subagent delegation, background terminal/subagent lifecycle management, and task visibility in the TUI.
We have implemented a working fork, Open Codex CLI, that explores one possible direction:
- more proactive parallel-first subagent planning
- nonblocking background execution for terminals and subagents
- a persistent
Down task panel for inspecting and managing background work
- task-list visibility in the same panel, so plan/task progress is not only visible as a compact status-line counter
Fork: https://github.com/LEON-gittech/codex
The implementation is fork-specific today, but the interaction model may be useful as prior art for upstream Codex.
Related upstream discussions
Subagent planning / delegation
These point to a common theme: Codex needs a clearer policy for when to split work into subagents, how aggressive that split should be, and how repo/user instructions should shape the delegation strategy.
Background terminals / nonblocking execution
These discussions all touch the same interaction problem: long-running terminal or subagent work should remain visible and manageable, but it should not block the main conversation loop.
Design direction explored in Open Codex CLI
1. Parallel-first subagent planning policy
Open Codex currently implements this mostly through the instruction layer rather than a hardcoded scheduler.
The policy asks the main agent to classify non-trivial work by independent axes before editing:
- investigation
- review
- test discovery
- docs/reference comparison
- validation
- implementation
When independent axes exist, the agent is encouraged to spawn read-only subagents first, while keeping final code changes in one implementation lane unless write ownership is clearly disjoint.
This is intentionally more proactive than the default conservative behavior, but still bounded:
- do not duplicate work between main thread and subagents
- do not spawn if the next critical-path step is blocked on the result
- prefer read-only lanes for evidence gathering
- keep implementation centralized unless ownership is cleanly separable
- report what each lane found before finalizing
2. Nonblocking background execution
Open Codex treats long-running terminals and subagents as background work by default.
The goal is to avoid this pattern:
Waiting for background terminal...
Waiting for subagent...
Instead, background work continues independently while the user can keep typing and submitting new messages.
The foreground model turn still shows normal Working state when the model is active, but background terminals/subagents are tracked separately and summarized in the status line.
3. Persistent Down task panel
Open Codex adds a persistent bottom-pane panel opened with Down.
The panel separates:
TasksSubagentsTerminals
It updates in place rather than inserting a chat-stream summary.
For terminals, the detail view shows:
- status
- elapsed runtime
- wrapped command/task metadata
- recent output tail
- stop action when the process is stoppable
For subagents, the detail view shows:
- agent title / nickname
- role
- task prompt
- status
- elapsed runtime
- progress lines when available
4. Plan/task monitoring
In addition to background terminals and subagents, Open Codex also surfaces the latest plan/task list in the same Down panel.
This matters because compact status-line counters are useful, but insufficient when the user wants to inspect:
- what tasks exist
- which tasks completed
- which task is currently active
- what remains pending
So the panel acts as a lightweight task manager for the current session.
Other features in Open Codex CLI
Open Codex also includes several adjacent TUI / workflow improvements:
/effort slash command for changing reasoning effort- query-level
ulw / ultra / xhigh marker support for one-turn xhigh reasoning
- per-turn reasoning effort visibility in the status line while the turn is running
/export <path> for markdown session export- status-line token throughput visibility
- workspace git diff stats in the status line
- Open Codex-aware npm update prompts
- active memory staging on top of upstream memories
- stale turn output protection in the TUI
- improved user-query highlighting in chat history and composer
More details are in the fork README:
https://github.com/LEON-gittech/codex
Why this may be useful upstream
The core idea is that background work should be first-class TUI state, not a blocking foreground wait state.
A useful upstream design could separate three concepts:
-
foreground model activity
The main assistant is currently generating or deciding.
-
background task activity
Terminals/subagents are still running, but they should not block input.
-
task management UI
Users need a stable place to inspect, switch, stop, and review background work.
This distinction makes the TUI easier to reason about:
Working means the foreground model is active- background work is visible but nonblocking
- users can inspect details through a dedicated panel
- completed work can be surfaced without hijacking the chat stream
Implementation reference
The current implementation is available here:
https://github.com/LEON-gittech/codex
This is not proposed as a direct patch to copy verbatim. It is a working fork implementation that may help evaluate the interaction model and identify which parts would be appropriate for upstream Codex.
Summary
This issue collects several related discussions around subagent delegation, background terminal/subagent lifecycle management, and task visibility in the TUI.
We have implemented a working fork, Open Codex CLI, that explores one possible direction:
Downtask panel for inspecting and managing background workFork: https://github.com/LEON-gittech/codex
The implementation is fork-specific today, but the interaction model may be useful as prior art for upstream Codex.
Related upstream discussions
Subagent planning / delegation
Feature request: mission-entropy detection and bounded sub-agent delegation #21858 - mission-entropy detection and bounded sub-agent delegation
Feature request: mission-entropy detection and bounded sub-agent delegation #21858
Subagent spawn policy conflicts with repo-level workflow instructions #16996 - subagent spawn policy conflicts with repo-level workflow instructions
Subagent spawn policy conflicts with repo-level workflow instructions #16996
Feature Request: Support for higher or configurable sub-agent spawning limits #16183 - configurable sub-agent spawning limits
Feature Request: Support for higher or configurable sub-agent spawning limits #16183
These point to a common theme: Codex needs a clearer policy for when to split work into subagents, how aggressive that split should be, and how repo/user instructions should shape the delegation strategy.
Background terminals / nonblocking execution
Background Terminal Sessions #3968 - Background Terminal Sessions
Background Terminal Sessions #3968
Feature request: Claude Code-like /monitoring for background terminals #17737 - Claude Code-like monitoring for background terminals
Feature request: Claude Code-like /monitoring for background terminals #17737
A way to view full output of background terminals #16935 - view full output of background terminals
A way to view full output of background terminals #16935
/stop <id>to terminate a single background terminal #17821 -/stop <id>for a single background terminal/stop <id>to terminate a single background terminal #17821Persistent orphaned subagents, missing lifecycle controls, and eventual session freezes #19197 - orphaned subagents, lifecycle controls, session freezes
Persistent orphaned subagents, missing lifecycle controls, and eventual session freezes #19197
These discussions all touch the same interaction problem: long-running terminal or subagent work should remain visible and manageable, but it should not block the main conversation loop.
Design direction explored in Open Codex CLI
1. Parallel-first subagent planning policy
Open Codex currently implements this mostly through the instruction layer rather than a hardcoded scheduler.
The policy asks the main agent to classify non-trivial work by independent axes before editing:
When independent axes exist, the agent is encouraged to spawn read-only subagents first, while keeping final code changes in one implementation lane unless write ownership is clearly disjoint.
This is intentionally more proactive than the default conservative behavior, but still bounded:
2. Nonblocking background execution
Open Codex treats long-running terminals and subagents as background work by default.
The goal is to avoid this pattern:
Instead, background work continues independently while the user can keep typing and submitting new messages.
The foreground model turn still shows normal
Workingstate when the model is active, but background terminals/subagents are tracked separately and summarized in the status line.3. Persistent
Downtask panelOpen Codex adds a persistent bottom-pane panel opened with
Down.The panel separates:
TasksSubagentsTerminalsIt updates in place rather than inserting a chat-stream summary.
For terminals, the detail view shows:
For subagents, the detail view shows:
4. Plan/task monitoring
In addition to background terminals and subagents, Open Codex also surfaces the latest plan/task list in the same
Downpanel.This matters because compact status-line counters are useful, but insufficient when the user wants to inspect:
So the panel acts as a lightweight task manager for the current session.
Other features in Open Codex CLI
Open Codex also includes several adjacent TUI / workflow improvements:
/effortslash command for changing reasoning effortulw/ultra/xhighmarker support for one-turnxhighreasoning/export <path>for markdown session exportMore details are in the fork README:
https://github.com/LEON-gittech/codex
Why this may be useful upstream
The core idea is that background work should be first-class TUI state, not a blocking foreground wait state.
A useful upstream design could separate three concepts:
foreground model activity
The main assistant is currently generating or deciding.
background task activity
Terminals/subagents are still running, but they should not block input.
task management UI
Users need a stable place to inspect, switch, stop, and review background work.
This distinction makes the TUI easier to reason about:
Workingmeans the foreground model is activeImplementation reference
The current implementation is available here:
https://github.com/LEON-gittech/codex
This is not proposed as a direct patch to copy verbatim. It is a working fork implementation that may help evaluate the interaction model and identify which parts would be appropriate for upstream Codex.