Should the TUI composer stay visible while reading scrollback?

[me2seeks]

Maka's TUI uses the terminal's native scrollback for conversation history. The composer and status line live at the end of that output.

This works naturally while following the latest response, but it becomes awkward when reading older content. A user can scroll upward to inspect an earlier answer or a long tool result, but after reading it they must scroll all the way back to the bottom before they can see the composer and continue typing.

Question

Should the TUI keep the input composer and status line visible at the bottom of the viewport while the user scrolls through conversation history?

The intended experience would be:

• conversation history can scroll independently;
• the composer remains available, so the user can start typing from any reading position;
• the current status remains visible;
• new output does not unexpectedly take the user away from the part of history they are reading.

This is adjacent to #3811, which discusses making permission mode more visible in the input area, but the question here is about whether the whole input/status area should remain anchored.

Trade-offs

The current native-scrollback model preserves normal terminal selection, copying, and scrollback behavior. Keeping a footer fixed may require an application-owned transcript viewport or another split-layout approach, which would also need clear behavior for mouse wheels, Page Up/Down, selection, resizing, and long or streaming output.

A fixed footer also consumes viewport rows in small terminals. It may be worth keeping only the composer fixed, or collapsing the status line while the user is reading history.

Questions to settle

1. Is returning to the bottom before typing a meaningful usability problem in real TUI use?
2. Should both the composer and status line remain fixed, or only the composer?
3. If the user starts typing while viewing older history, should the transcript stay in place or jump to the latest message?
4. When new model or tool output arrives, should the TUI preserve the user's reading position and show an unread indicator?
5. Can this be achieved without losing the terminal's native selection, copying, and scrollback behavior?

This discussion is about the desired interaction first; it does not assume a particular rendering or scrolling implementation.

AI assistance disclosure: Drafted and published with Codex at the author's direction.