What variant of Codex are you using?
CLI
What feature would you like to see?
Problem
When working with long outputs (especially in tmux), I often need to scroll up to inspect earlier content while simultaneously drafting the next prompt.
Currently, scrolling and input focus feel tightly coupled:
- I have to leave my current input context to scroll (e.g. tmux copy mode)
- Then return back to the prompt to continue typing
- This breaks the flow when iterating quickly
Expected Behavior
Allow users to scroll the transcript/output viewport independently while keeping the prompt input always editable.
Proposed interaction model
- Input box remains focused and editable at all times
- Viewport (chat/output) can be scrolled independently via keybindings:
Ctrl-J / Ctrl-K (line-wise, though conflicts with newline key binding)
- or
Ctrl-D / Ctrl-U (page-wise)
Esc jumps back to bottom (follow mode)
- Optional:
- Auto-follow (scroll to bottom) after sending a prompt
- Or auto-return after some idle time
Why this matters
This is especially important in workflows with:
- long outputs (code, logs, analysis)
- tmux / terminal multiplexers
- iterative prompting (read → refine → ask again)
Without this, users constantly context-switch between:
- scrolling mode
- input mode
which adds friction to rapid iteration.
Related Issues
Example workflow (current vs desired)
Current:
- Scroll up (tmux copy mode)
- Exit copy mode
- Type prompt
- Repeat
Desired:
- Scroll up (within Codex TUI)
- Keep typing prompt without losing context
- Press
Esc to jump back to bottom if needed
Additional context
This pattern is common in tools like terminal pagers (less, bat) and chat apps where scrollback and input are decoupled.
It would make Codex TUI much smoother for real-world dev workflows.
If this direction makes sense, I'm happy to open a PR.
Additional information
No response
What variant of Codex are you using?
CLI
What feature would you like to see?
Problem
When working with long outputs (especially in tmux), I often need to scroll up to inspect earlier content while simultaneously drafting the next prompt.
Currently, scrolling and input focus feel tightly coupled:
Expected Behavior
Allow users to scroll the transcript/output viewport independently while keeping the prompt input always editable.
Proposed interaction model
Ctrl-J / Ctrl-K(line-wise, though conflicts withnewlinekey binding)Ctrl-D / Ctrl-U(page-wise)Escjumps back to bottom (follow mode)Why this matters
This is especially important in workflows with:
Without this, users constantly context-switch between:
which adds friction to rapid iteration.
Related Issues
Example workflow (current vs desired)
Current:
Desired:
Escto jump back to bottom if neededAdditional context
This pattern is common in tools like terminal pagers (
less,bat) and chat apps where scrollback and input are decoupled.It would make Codex TUI much smoother for real-world dev workflows.
If this direction makes sense, I'm happy to open a PR.
Additional information
No response