openai / openai/codex

TUI: add an optional split layout for conversation and activity

Open
#38,073 1 comment 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

CLI config enhancement TUI
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 CHAT on the left and ACTIVITY on 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 TRANSCRIPT view instead.
  • Respect --no-alt-screen and tui.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

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 skipped
  • just fix -p codex-tui: clean
  • just fmt: clean
  • Added wide and narrow insta snapshots
  • 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.