Feature: Pin prompt/composer input box to bottom of terminal pane (CLI)
Variant
CLI (terminal TUI)
Feature request
Add an option to pin the prompt/composer input box to the bottom of the terminal viewport so it stays visible while the conversation/transcript scrolls above it.
Problem
In long Codex CLI sessions, the transcript grows quickly. When reviewing earlier output or scrolling through tool results, the input area can scroll out of view or feel detached from the active viewport. Users must scroll back down to compose the next message, which breaks flow during debugging and multi-step tasks.
This is especially painful when:
- Reading tool output or diffs above while drafting the next instruction
- Comparing earlier assistant messages with current terminal state
- Working in shorter terminal windows (split panes, laptop screens)
Proposed behavior
- Pinned input region: Reserve a fixed bottom band of the terminal for the composer/prompt UI (text input, model indicator, approval hints, etc.).
- Scrollable transcript only: Session history, tool calls, and command output scroll in the area above; the input box never leaves the viewport.
- No overlap: Pinned UI should not obscure transcript content at the bottom (clear separator, optional reduced font size for chrome).
- Configurable (suggested): e.g. in
~/.codex/config.tomlor equivalent:
[tui]
pin_composer_to_bottom = true # default: true (or false for legacy behavior)
composer_height_lines = 4 # optional: min rows reserved for input chrome
Reference / parity
IDE-style agent UIs (including Cursor’s composer) keep the prompt anchored at the bottom while content scrolls above. Bringing the same layout to the Codex CLI would improve ergonomics for power users living in the terminal.
Environment
- OS: macOS (Darwin 25.4.0)
- Terminal: standard macOS terminal / iTerm2-style split panes
Additional notes
Related UX improvements that pair well with this:
- Optional status/footer line pinned just above the input (model, cwd, sandbox mode)
- Smarter auto-scroll: only follow output when user is already at bottom (see also scroll-behavior requests in other agent CLIs)
Happy to test a beta build or provide screen recordings if helpful.
3 Comments
Totally agree with the need for this feature. +1
+1, Strongly agree! 👍
This was the most noticeable inconvenience when I switched from another agent CLI.
Similar requests have come up repeatedly, and although earlier ones were closed because they did not receive enough votes, interest in this feature seems to be steadily growing.
Follow-up after additional iTerm2 testing (2026-07-22): the pinned-composer interaction works functionally, but the prototype’s fixed-step virtual wheel scrolling is not yet comparable to Claude Code’s mature fullscreen scroller. This should be treated as an architectural prototype, not a production-ready feature-parity implementation. The focused, usable iTerm2 fix today is the native-scrollback branch: https://github.com/Andrewwilliamross/codex/tree/agent/fix-iterm2-native-scrollback.
I implemented and manually validated the requested pinned-composer UX.
The key architectural constraint is that Codex cannot keep the composer fixed while iTerm2/native terminal scrollback owns the viewport. The implementation therefore uses the existing opt-in
tui.alternate_screen = "always"setting as an application-owned mode rather than adding another config flag or changing defaults.In that mode:
Jump to bottom (click) ↓pill appearsExperimental branch: https://github.com/Andrewwilliamross/codex/tree/agent/fix-iterm2-scrollback
Final interaction commit: https://github.com/Andrewwilliamross/codex/commit/dfa4ccd3d19efaa22246006492ec0e028b612a54
Functional verification: 3,259
codex-tuitests passed, 4 skipped, plus manual validation of the basic scroll/pause/draft/click/resume flow. Further human testing identified the scroll-feel limitation described above.If this UX and configuration boundary align with the team’s direction, I’m happy to continue refining the prototype or open an invited PR.