TUI: add an optional split layout for conversation and activity
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- PR merge metrics
- PR metrics pending
Description
What variant of Codex are you using?
CLI / terminal TUI
What feature would you like to see?
Add an opt-in retained split layout that keeps the human/assistant conversation on the left and operational activity (tool calls, commands, edits, diffs, status output) on the right.
Example configuration:
[tui]
layout = "split"
The current shared transcript is still the default. The proposed layout activates only when explicitly configured and an alternate-screen surface is available.
Why this would help
During long agent runs, command output, diffs, tool calls, and polling updates can dominate the transcript. The actual conversation and decisions become difficult to follow even though they are usually the highest-value context for the user.
Separating the two streams makes it possible to:
- keep the prompt, questions, reasoning summaries, and assistant responses readable;
- monitor commands, edits, diffs, and background activity without losing the conversation;
- independently scroll either stream while continuing to compose the next message;
- preserve the existing combined transcript on narrower terminals.
This is related to the pinned-composer and independent-scrolling requests in #26311 and #15874, but it adds a distinct semantic split between conversation and operational activity. It is also adjacent to the narrative/log distinction discussed in #13544.
Proposed behavior
- At 120 columns or wider, render
CHATon the left andACTIVITYon the right, separated by a one-column divider. - Keep the composer and status surface pinned below the left conversation pane.
- Route mouse/trackpad wheel events by pointer position so each transcript scrolls independently.
- Below the width threshold, render a retained combined
TRANSCRIPTview instead. - Respect
--no-alt-screenandtui.alternate_screen = "never"by falling back to the existing inline transcript. - Keep
tui.layout = "single"as the default, with no change to existing behavior.
Working prototype
- Branch: https://github.com/mikekhristo/codex/tree/agent/split-pane-tui
- Diff against upstream: https://github.com/openai/codex/compare/main...mikekhristo:codex:agent/split-pane-tui
- Current commit: https://github.com/mikekhristo/codex/commit/081bdf1
The prototype introduces a small HistoryCellStream classification. Conversation cells opt in explicitly; operational cells remain the safe default so newly added tool/status cells do not accidentally appear in the chat pane. The retained renderer consumes the same committed and live history cells as the existing transcript rather than rewriting model-visible history.
The first mouse implementation exposed an important terminal detail: DEC alternate-scroll mode converts trackpad gestures into Up/Down keystrokes, which made the composer navigate prompt history. The current prototype enables real mouse capture only for the split surface and routes wheel events to pane-local scroll state. Physical Up/Down keys remain composer-history controls.
Validation
just test -p codex-tui: 3,450 passed, 5 skippedjust fix -p codex-tui: cleanjust fmt: clean- Added wide and narrow
instasnapshots - Added regression coverage for pane targeting, viewport offsets, alternate-screen restoration, and real mouse-event delivery
- Manually exercised on macOS with iTerm2 and a trackpad
Known tradeoffs
- Mouse capture can require Shift-drag for native terminal text selection, depending on the terminal.
- The prototype uses fixed-step wheel scrolling; smooth/inertial scroll behavior could be refined.
- The complete prototype is about 1,000 changed lines including tests and snapshots. If the direction is accepted, it can be split into reviewable stages: first the neutral history-stream classification/rendering accessors, then the opt-in retained layout and mouse interaction.
Does this interaction and configuration boundary align with the TUI roadmap? If so, I would be happy to split the prototype as requested and open an invited PR.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the codex-tui prototype branch and its diff against main, then run just test -p codex-tui and inspect the added wide/narrow snapshots and interaction regression coverage. Done means an accepted opt-in split layout preserves the default transcript, handles width and alternate-screen fallbacks, and supports independent pane interaction without changing model-visible history.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100