Summary
When droid is running in mission/TUI mode and the LLM is actively generating output, any attempt to scroll the terminal (mouse wheel or scrollbar drag) causes the viewport to jump immediately to the very top of the terminal scrollback buffer instead of scrolling by a small amount.
Steps to Reproduce
- Run
droid in a terminal (Windows Terminal, PowerShell, etc.)
- Start a mission and wait for the LLM to begin actively generating/streaming output
- While the LLM is working, try to scroll up using the mouse wheel or scrollbar
Expected Behaviour
Scrolling up should move the viewport a few lines at a time through the scrollback, allowing the user to read earlier output while the agent continues working.
Actual Behaviour
Any scroll attempt immediately snaps the viewport to the very top of the terminal scrollback buffer (showing the original droid startup/splash screen from session start). From the top position, one scroll step moves a few lines down, then it snaps back to the top again.
Once droid is idle (not actively outputting), scrolling works correctly.
Root Cause (Analysis)
Unlike most TUI applications (vim, htop, etc.), droid appears to draw its mission control view directly into the main terminal buffer rather than using the alternate screen buffer (\x1b[?1049h). During active LLM output, droid redraws its interface using cursor-positioning sequences (cursor home + redraw), causing the terminal emulator to follow the cursor. When the cursor is repositioned to row 1 of the TUI layout and the terminal follows it, the viewport jumps to wherever that row maps in the scrollback buffer — which is the top.
Suggested Fix
Use the alternate screen buffer (\x1b[?1049h on enter, \x1b[?1049l on exit) for the mission control TUI view, as is standard practice for full-screen TUI applications. This keeps the TUI isolated from the scrollback and leaves the main buffer history accessible after the session.
Environment
- droid version: 0.97.0
- OS: Windows 11 (10.0.26200)
- Terminal: Windows Terminal / PowerShell
- Mode: mission/interactive-cli
Summary
When
droidis running in mission/TUI mode and the LLM is actively generating output, any attempt to scroll the terminal (mouse wheel or scrollbar drag) causes the viewport to jump immediately to the very top of the terminal scrollback buffer instead of scrolling by a small amount.Steps to Reproduce
droidin a terminal (Windows Terminal, PowerShell, etc.)Expected Behaviour
Scrolling up should move the viewport a few lines at a time through the scrollback, allowing the user to read earlier output while the agent continues working.
Actual Behaviour
Any scroll attempt immediately snaps the viewport to the very top of the terminal scrollback buffer (showing the original droid startup/splash screen from session start). From the top position, one scroll step moves a few lines down, then it snaps back to the top again.
Once droid is idle (not actively outputting), scrolling works correctly.
Root Cause (Analysis)
Unlike most TUI applications (vim, htop, etc.), droid appears to draw its mission control view directly into the main terminal buffer rather than using the alternate screen buffer (
\x1b[?1049h). During active LLM output, droid redraws its interface using cursor-positioning sequences (cursor home + redraw), causing the terminal emulator to follow the cursor. When the cursor is repositioned to row 1 of the TUI layout and the terminal follows it, the viewport jumps to wherever that row maps in the scrollback buffer — which is the top.Suggested Fix
Use the alternate screen buffer (
\x1b[?1049hon enter,\x1b[?1049lon exit) for the mission control TUI view, as is standard practice for full-screen TUI applications. This keeps the TUI isolated from the scrollback and leaves the main buffer history accessible after the session.Environment