Provide a way to view the content of the background terminal

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #12457
• #12223
• #13443

Powered by Codex Action

+1

/ps

Background terminals

  • ./.venv/bin/python - <<'PY' [...]
  • ./.venv/bin/python - <<'PY' [...]
  • ./.venv/bin/python - <<'PY' [...]

  3 background terminals running · /ps to view · /clean to close

Is not helpful to understand what is happening

Implementation spec based on current main:

This looks fixable as a TUI-only change. The CLI already receives background-terminal output chunks; the main limitation today is that the TUI throws almost all of that away and /ps renders a heavily truncated history cell.

Current truncation points on main:

• tui/src/chatwidget.rs
• UnifiedExecProcessSummary only keeps recent_chunks: Vec<String>
• track_unified_exec_output_chunk(...) keeps only the last 3 non-empty lines (MAX_RECENT_CHUNKS = 3)
• tui/src/history_cell.rs
• /ps only shows the first line of command_display
• command preview is capped to 80 graphemes before width-based truncation
• chunk previews are also width-truncated and suffixed with [...]

Suggested implementation:

1. Keep the footer summary as-is.

• background terminal running · /ps to view · /clean to close is fine for the bottom pane.

1. Change /ps from “insert truncated history cell into transcript” to “open a pager overlay”.

• Reuse the existing static pager overlay in tui/src/pager_overlay.rs
• This avoids flooding transcript history and gives proper scrolling for long prompts/output

1. In tui/src/chatwidget.rs, replace recent_chunks: Vec<String> with a bounded per-process output buffer.

• A VecDeque<String> line ring buffer is probably enough for an MVP
• Bound it by total lines and/or bytes per process so memory stays predictable
• Example target: keep the last 500-2000 lines or ~128-512 KiB per running process
• No need for a config knob initially

1. Keep both:

• a short single-line summary for the footer
• the full wrapped command text for the /ps overlay

1. /ps overlay content should render, for each running process:

• process id if available
• full command/prompt text, wrapped, not first-line-only
• buffered output below it, wrapped, not hard-truncated to 3 lines

1. Nice follow-up, but not required for MVP:

• when the overlay is open, keep it live by rebuilding from the in-memory process buffers on each draw/tick
• optionally add per-process sections or jump keys later

Why this seems low-risk:

• No protocol change looks necessary for the CLI/TUI path
• output chunks already reach ChatWidget; they are just summarized too aggressively today
• the pager overlay already exists and is a better UI primitive than a transcript cell for this job

So the practical MVP is:

• store more than 3 recent lines
• stop using a transcript cell for /ps
• open a scrollable overlay showing full wrapped command text and buffered output for each running background terminal

I've very recently switched from windsurf to codex and I'm missing this capability already. There is something strangely satisfying watching the actions stream by, whether you're in the loop or not. It's also a great way to catch and steer codex in a different direction if you're in a live troubleshooting session.

It's not a perfect solution, but a useful workaround for some may be to have logs be routed to a file (for instance, I just told codex to add a rotating file handler for my python app that I'm working on so tests give me an additional artifact for observation)

+1, I would love to see the behavior also, it would be especially helpful in scenarios where the background terminal gets stuck or has a strange error when running commands.

It seems to be resolved by using ctrl+t in the newest version of codex

It seems to be resolved by using ctrl+t in the newest version of codex

This works but doesn't show the terminal output always. The panel opened from that command isn't smooth at all. Scrolling and display don't look good.

I prefer how Kiro IDE does it by showing you the terminal activities live in a normal IDE terminal panel. I can run my own commands in the terminal session, stop or kill that session easily. It's like owning full control of the terminal and the agent uses or creates new ones at will.