[Bug] TUI chat transcript auto-scrolls to bottom on every token, blocking user from reading previous output

[moneylau0415-code]

[Bug] TUI chat transcript auto-scrolls to bottom on every token, blocking user from reading previous output

Summary

In the interactive TUI chat view, the conversation transcript forcibly scrolls to the bottom on every streamed assistant token, so any attempt to scroll up and read earlier output (a tool result, a previous paragraph, an error message) gets yanked back as soon as the next token arrives. There is no way to pause follow-mode or to scroll back without re-engaging follow-mode.

Environment

• mcode version: @minimax-ai/code@0.5.3 (CLI installed via npm i -g)
• TUI mode: regular (also reproduces in fullscreen)
• Host: Termux 0.119.0-beta.3 (Android 17, device 25098PN5AC, xterm.js viewport-based render path)
• Workspace: empty ~

Reproduction

1. npm i -g @minimax-ai/code
2. mcode (enter interactive TUI)
3. Send a prompt that elicits a long streaming answer, e.g. "explain how React reconciliation works, in detail, with examples"
4. While tokens are streaming in, try to scroll up with the touchscreen / wheel / Page Up to read a paragraph that just scrolled off-screen.
5. Observed: the viewport snaps back to the bottom on the very next token chunk. It is essentially impossible to read anything that was emitted earlier in the same turn, or earlier turns that have been pushed off-screen by the latest one.
6. This affects only the chat transcript — tool result panes, status line, and the input composer do not have this issue, which rules out the host terminal (Termux) or SCROLL extra-key behavior as the cause. Other terminals (e.g. macOS Terminal.app, gnome-terminal) reproduce the same way.

Expected

A user-controlled follow / unfollow toggle (analogous to Termux's SCROLL extra-key termux/termux-app@5fc2b4c, or the scroll-lock pattern used by tmux/less). Specifically:

• When the user scrolls up, the viewport must not snap back on subsequent output until the user explicitly re-enables follow (e.g. End, G, or a FOLLOW toggle key).
• Streaming output should keep piling up below the user's current viewport without yanking it.
• The threshold for "is the user at the bottom?" should be generous (≥ one line / ~50 px), not a few pixels.

Actual

Every new token triggers a re-render that calls scrollIntoView (or equivalent mTopRow = 0) on the active transcript row, unconditionally. There is no user-scrolled-up detection, no follow-mode flag, and no setting to disable it.

Root cause (from inspecting the installed bundle)

The TUI's ChatTranscript-style component — located in one of the minified chunks under chunks/ (@minimax-ai/code ships as a bundled CLI; the TUI render path lives in the launcher + the conversation-transcript React/Ink component) — re-anchors the cursor row on every update. Because the bundles are minified, the exact minified symbol is hard to cite, but the symptom is unambiguous: any new content forces scroll-to-bottom even when the user is many lines away.

Suggested fix

Adopt the pattern that already proved correct in Termux itself:

1. Track userScrolledUpRef (boolean) on the transcript scroll container.
2. On scroll events from the viewport (touch / wheel / key), set userScrolledUpRef = (scrollTop + clientHeight + threshold < scrollHeight).
3. When new tokens arrive, only call scrollIntoView / set mTopRow = 0 if !userScrolledUpRef.
4. Clear userScrolledUpRef when:
   • the user scrolls all the way to the bottom, or
   • the user presses a dedicated FOLLOW / End / G key, or
   • a new user turn starts (i.e. the user just submitted a new prompt and clearly wants to see the response).
5. Expose a FOLLOW toggle in the extra-keys bar (or key-bind a Ctrl+L / F6 style toggle) so users can manually resume follow-mode without scrolling all the way down.

Workaround (until fixed)

Use the non-TUI mode for any prompt whose response you intend to read carefully:

mcode exec "your prompt" | less -R

This bypasses the transcript renderer entirely, but loses interactive follow-up. Acceptable for one-shot tasks, not for long multi-turn sessions — which is precisely the use case most affected by this bug.

Impact

Every long-running, multi-turn mcode session is affected. Users routinely lose the ability to reference earlier tool output or earlier parts of the assistant's reasoning, which materially degrades the agent workflow this CLI is designed for. The same bug is reported (separately) for @tencent-ai/codebuddy-code@2.157.0; the underlying UX defect is identical, suggesting a cross-pollinated TUI pattern.

[1anZhang]

Thank you for the detailed report and reproduction steps. They helped us reproduce the Termux regular-mode snap-back and uncover a related fullscreen scrolling bug.

For regular mode in Termux, enabling scroll lock with the SCROLL extra key prevented the snap-back in our reproduction, while streaming output continued normally.

Regular mode uses Termux's native scrollback. In the version you reported, Termux can return that viewport to the bottom on any screen update, including MCode's activity indicator updates even when no new model tokens arrive. The SCROLL key toggles this automatic scrolling for the current terminal session. Termux's implementation

To enable it:

1. Edit ~/.termux/termux.properties and add 'SCROLL' to your existing extra-keys layout. If you do not already have an extra-keys setting, you can add this minimal example:

   extra-keys = [['ESC','TAB','CTRL','ALT','SCROLL']]

2. Save the file, then run this in a Termux shell:

   termux-reload-settings

3. Return to the Termux session running MCode and tap SCROLL in the extra-keys bar. Depending on the key style, it may appear as ⇳. From the default state, one tap disables automatic scrolling; another tap restores it. The toggle applies separately to each Termux session.

Adding the configuration only creates the button; you still need to tap it. Then try scrolling up during a long response. You can keep using interactive MCode while reading earlier output.

In our fixed-size reproduction, regular mode with SCROLL enabled held the reading position across 140 streamed chunks. Fullscreen mode also held its position with both plain text and Markdown. These checks used the released 0.5.3 CLI and Termux's original terminal parser and viewport methods in a headless harness; we have not yet confirmed the result on a physical Android device.

Your report also led us to a separate fullscreen resize bug: enlarging the viewport could unexpectedly re-enable following after scrolling up. We opened #350 to preserve the user's follow state through that layout change. Your reported fullscreen behavior without a resize remains unresolved, so we are keeping this issue open.

Please let us know whether SCROLL resolves the regular-mode behavior on your device. If it still jumps with scroll lock enabled, or in fullscreen, a short screen recording and the input method used (touch, mouse wheel, or Page Up), including any on-screen keyboard opening or closing, would help us narrow down the remaining case. Thanks again for helping us improve this experience.