Repository navigation
[Bug]: Desktop terminal (Cmd+J) forces viewport to bottom — cannot scroll scrollback without jump #6096
Description
Summary
On macOS desktop, opening the integrated terminal (mod+j → terminal.toggle) and scrolling up into scrollback is unreliable: the viewport keeps forcing itself back to the bottom, so I cannot read earlier terminal output without the screen jumping down again.
This is desktop Ghostty-based terminal behavior (not the mobile “can’t scroll at all” case).
Expected
- Opening the terminal may land at the bottom (live prompt) — fine.
- Once I scroll up into scrollback, the viewport should stay pinned at my scroll position until I deliberately return to the bottom (or run a “scroll to end” action).
- New output should only auto-follow if I was already at the bottom (standard terminal “stick to bottom” UX, same as Terminal.app / iTerm / VS Code).
Actual
- After opening the terminal with Cmd+J, trying to scroll to the top / earlier output fails: the view jumps back to the bottom.
- It feels like something is continuously re-pinning the viewport to the live end, so history is effectively unreadable while that fight is happening.
Steps to reproduce
- macOS → T3 Code desktop (Alpha).
- Open a project thread with an integrated terminal that has enough scrollback (run a few commands, or any long output).
- Press Cmd+J (
terminal.toggle/mod+j) to open the terminal drawer/panel. - Try to scroll up (trackpad / mouse wheel / scrollbar) to read earlier lines.
- Observe the viewport snap / jump back to the bottom instead of staying where you scrolled.
Environment
| App | T3 Code (Alpha) desktop |
| Version | 0.0.32 (com.t3tools.t3code) |
| OS | macOS |
| Shortcut | mod+j → terminal.toggle (present in ~/.t3/userdata/keybindings.json) |
| Surface | Integrated terminal (Ghostty renderer) |
Related issues (searched — not duplicates)
| Issue | Why related / why not a duplicate |
|---|---|
| #2141 Cant scroll terminal in mobile web | Same area (terminal scroll), but mobile web / no scroll at all. This report is desktop and is scroll-then-forced-to-bottom. |
| #4568 Expanding “Worked for …” scrolls to the end | Same jump-to-end while reading history UX class, but chat thread, not terminal. |
| #5434 Scroll to End button on iOS | Mobile chat scroll affordance, not desktop terminal. |
No open desktop issue found that matches “terminal scrollback fights auto-follow / jumps to bottom.”
Possible code touchpoints (from reading main)
Not a diagnosis — just breadcrumbs for maintainers:
apps/web/src/components/ThreadTerminalDrawer.tsx—fit()paths callscrollToBottom()whenisAtBottom()is true (mount fit timer ~30ms; also ondrawerHeight/resizeEpoch/ terminal identity changes).apps/web/src/terminal/ghostty/surface.ts—isAtBottom()→core.isViewportActive().- Buffer updates write new PTY data without an explicit “only follow if at bottom” guard in the React effect; if Ghostty always keeps the cursor in view on
vt_write, or ifisViewportActivestays true while the user has scrolled up, that would match this bug.
Impact
Major degradation when using the integrated terminal for anything with history (build logs, test output, long agent/shell sessions). I have to leave T3’s terminal and use an external one to read earlier output.
What this is / isn’t
| Is | Desktop terminal viewport forced to bottom / cannot stably view scrollback |
| Is not | Mobile-only scroll failure (#2141) |
| Is not | Chat thread jump-to-end (#4568) |
Workaround
Use an external terminal (Terminal.app / iTerm / Warp) for anything that needs scrollback review.
Activity
fix(web): typing in a scrolled-back terminal returns to the prompt (#509
maria-rcks commentedon Oct 12, 2026
Note
This is an automated response from a bot acting on maria's behalf.
This issue has had no activity since 2026-08-11.
Is it still relevant on the current version? If so, your version and OS would help.
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Commit b68aedf (origin/main). The desktop dev build fails on this VM (native module needs libsecret-1), so I ran the web client, which desktop wraps:
T3CODE_DEV_SEED=0 vp run dev, paired a browser, opened a thread and pressed Ctrl+J (mod+j on Linux) to open the terminal. (1) Ranseq 1 2000, sent 10 wheel events (deltaY -120) to the terminal canvas: the scrollbar moved from row 1987 to 1921 and stayed at 1921 3 s later. (2) Ranfor i in $(seq 1 40); do echo tick $i; sleep 0.25; done, scrolled up during output: the viewport stayed at row 1950 for 5 s while the buffer grew from 2015 to 2028 rows. (3) Pressed Ctrl+J twice to close and reopen the drawer: it reopened at the bottom; scrolling up 133 rows held, and dragging the scrollbar thumb to the top held at row 0. (4) 120 trackpad-like wheel events of 3px each moved up 19 rows and held. Also a scratch unit test on GhosttyTerminalCore: after scroll(-30), write() and resize() left the viewport offset unchanged and isViewportActive() false. Not tried: a real macOS trackpad with momentum scrolling.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.