TUI: compact successful command entries in the transcript

What variant of Codex are you using?

CLI (TUI)

What feature would you like to see?

Make command activity in the TUI transcript more compact without hiding information that can affect the user.

In command-heavy sessions, a successful command with no output currently occupies three rows:

• Ran git status --short
  └ (no output)

The transcript quickly becomes dominated by repeated Ran ..., (no output), and separator rows. This makes it difficult to find the conversation and remember the session's goal at a glance.

Proposed behavior:

1. Do not render the (no output) child row when a command succeeds without stdout or stderr.
2. Do not insert a blank separator row between adjacent command cells.
3. Keep the command row itself, non-empty output, failures, warnings, and other state that may influence the user.
4. Preserve existing spacing at boundaries with non-command content so the conversation remains readable.

This is intentionally narrower than hiding tool calls or folding transcript sections. The goal is to remove rows that carry no additional information while keeping consequential activity visible.

Additional information

Related requests:

• #18396 asks for a way to hide tool calls/output.
• #33534 proposes user-controlled folding of completed transcript sections.

This proposal is complementary: it improves the default expanded transcript and does not require interaction or hide substantive output.

I prototyped the behavior against current main:

• Branch: https://github.com/quigor/codex/tree/tui/compact-command-history
• Compare: https://github.com/openai/codex/compare/main...quigor:codex:tui/compact-command-history

The prototype covers main scrollback rendering, reflow, transcript overlay rendering, and app-server row accounting. Formatting, lint fixes, and focused renderer/reflow tests pass. The full codex-tui run completed 3,630 tests with 50 failures whose test names do not reference the touched renderer, spacing, or reflow paths.

An upstream solution is preferable to distributing a local fork: a fork would require recurring rebases, make the running version less obvious, and risk diverging from normal Codex updates.