TUI: add an optional split layout for conversation and activity

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

• 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 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.