opencode icon indicating copy to clipboard operation
opencode copied to clipboard

[Bug] TUI scroll position resets to session start after approving commands that exceed terminal height

Open TuringTutee opened this issue 2 weeks ago • 4 comments

Description

After upgrading to v1.0.223, when approving a bash command whose output exceeds the terminal's vertical space, the TUI resets scroll position to the first message in the session instead of staying at the current position.

Steps to Reproduce

  1. Start a session with several messages (enough to require scrolling)
  2. Have Claude execute a command that produces output taller than the terminal window
  3. Approve the command (press y or Enter)
  4. After command completes, observe scroll position

Expected Behavior

TUI should remain scrolled to the current message/command output area.

Actual Behavior

TUI jumps to the first message in the session, forcing user to scroll through entire conversation history to return to current context.

Environment

  • opencode version: v1.0.223
  • OS: Linux
  • Terminal: WezTerm

Notes

This is a regression - did not occur in previous versions. Particularly disruptive in long sessions.

TuringTutee avatar Jan 05 '26 01:01 TuringTutee

Additional Reproduction Details

Confirmed Variables

Terminal-specific: Bug reproduces in WezTerm but not in Alacritty.

Terminal TERM value Bug reproduced?
WezTerm xterm-256color ✅ Yes
Alacritty alacritty ❌ No

Both terminals report identical dimensions (tput lines = 24, tput cols = 80).

Refined Reproduction Steps

  1. Open OpenCode in WezTerm
  2. Have a session with enough content to require scrolling (a few tool calls)
  3. Trigger a bash command where the command text itself is 40+ lines (not just output)
  4. Observe:
    • Approval dialog extends past TUI viewport bottom
    • Cannot scroll within the approval dialog to see full command
    • After pressing Enter, TUI jumps to session start

Minimal Reproduction Command

python3 -c "
# Line 1: Test output for OpenCode command approve bug
# Line 2 through 42: padding comments...
# (40+ lines of comments)
print('done')
"

Hypothesis

The TERM=xterm-256color vs TERM=alacritty difference may cause different terminfo capability handling for:

  • Alternate screen buffer behavior
  • Scroll region handling
  • Viewport dimension queries during modal dialog rendering

TuringTutee avatar Jan 05 '26 02:01 TuringTutee

Updated Findings: Two Separate Bugs

After further testing, this appears to be two distinct issues:

Bug 1: Dialog overflow (terminal-agnostic)

The approval dialog extends past the TUI viewport when the command text exceeds terminal height. User cannot scroll within the dialog to see the full command, forcing a blind approve.

Reproduces in: WezTerm ✅, Alacritty ✅

Bug 2: Scroll-to-top after approve (WezTerm-specific)

After approving an oversized command, the TUI scroll position resets to the first message in the session.

Reproduces in: WezTerm ✅, Alacritty ❌

Test Matrix

Session Length Terminal Dialog Overflow Scroll-to-top
Short WezTerm
Long WezTerm
Short Alacritty
Long Alacritty

Root Cause Hypothesis

  1. Dialog overflow: OpenCode doesn't constrain dialog height to viewport or implement internal scrolling for the approval modal.

  2. Scroll-to-top: WezTerm handles alternate screen buffer or scroll region escape sequences differently than Alacritty. The TERM=xterm-256color (WezTerm) vs TERM=alacritty difference may trigger different terminfo code paths.

TuringTutee avatar Jan 05 '26 02:01 TuringTutee

Further Testing: GNOME Terminal (Ubuntu default)

Tested on GNOME Terminal which also uses TERM=xterm-256color like WezTerm.

Results

  • Dialog overflow: ✅ Yes (same as all terminals)
  • Scroll-to-top: ❌ No

Updated Test Matrix

Terminal TERM Dialog Overflow Scroll-to-top
WezTerm xterm-256color
GNOME Terminal xterm-256color
Alacritty alacritty

Conclusion

The scroll-to-top bug is WezTerm-specific, not related to the TERM value. Both GNOME Terminal and WezTerm use xterm-256color but only WezTerm exhibits the scroll reset behavior.

This points to something specific in WezTerm's:

  • Alternate screen buffer handling
  • Scroll region escape sequence interpretation
  • Or how it handles the TUI framework's viewport management

TuringTutee avatar Jan 05 '26 03:01 TuringTutee

Correction: Scroll-to-top reproduces in Alacritty with longer sessions

With a sufficiently long session, the scroll-to-top bug does reproduce in Alacritty.

Updated Understanding

The scroll-to-top is not terminal-specific - it's an OpenCode bug that triggers based on session length. WezTerm just has a lower threshold to trigger it.

Terminal Dialog Overflow Scroll-to-top (short session) Scroll-to-top (long session)
WezTerm ✅ (triggers earlier)
GNOME Terminal Not yet tested
Alacritty

Root Cause Hypothesis (revised)

Both bugs are likely OpenCode core issues:

  1. Dialog overflow: No height constraint or internal scroll for approval modal
  2. Scroll-to-top: Viewport/scroll position not preserved after dismissing oversized modal - severity varies by terminal but fundamentally an OpenCode issue

WezTerm may just be more sensitive to whatever scroll position handling OpenCode is doing.

TuringTutee avatar Jan 05 '26 04:01 TuringTutee