You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Input device: MacBook trackpad — no external mouse tested (see caveat below)
Problem
In a Claude session I can no longer scroll back through the terminal output. Scrolling up with a two-finger swipe only reaches roughly one screen (~34–36 lines); as new output arrives, older lines disappear and I can't scroll back to them. This used to work normally around 1.2.x — a plain two-finger scroll reached the terminal's scrollback.
Caveat: I use a MacBook trackpad and have not tested with a physical mouse wheel, so I can't confirm whether Shift+wheel behaves differently there. This report is specifically about the trackpad experience.
Steps to reproduce
Open a Claude session in the web UI on macOS/Chrome with a trackpad.
Produce more output than fits on screen (e.g. ask Claude to print 1–50).
Two-finger scroll up.
Expected: reach the top of the output (line 1). Actual: only reach ~line 34–36; earlier lines are gone and can't be scrolled back to.
What I found while digging (may help narrow it down)
I captured ~54 KB of the live PTY stream from a Claude session. It is entirely full-frame repaints: synchronized-update markers (CSI ?2026h/l, ~2130 of them) and absolute cursor addressing (CSI <row>;<col>H, ~2130), with 0 newlines in the whole stream. So Claude Code (≥ 2.1.187) repaints the viewport in place and never scrolls output into the terminal's scrollback. tmux confirms the pane is in the alternate screen with history_size=0.
On a macOS trackpad, holding Shift while two-finger scrolling is interpreted by the browser as horizontal scroll (deltaY ≈ 0), so the Shift+wheel branch of the container wheel handler never fires. Combined with the point above, there doesn't seem to be a working gesture for a trackpad user to page back through a Claude session's history.
Expected behavior
A macOS trackpad user should be able to scroll back through a Claude session's history the way it worked in ~1.2.x.
Possible directions (just suggestions)
An opt-out / setting to keep the plain wheel on local scrollback for users who prefer it, or
A trackpad-friendly gesture for local scrollback that doesn't rely on Shift (horizontal on macOS trackpads), or
Ensuring the forwarded-wheel path reliably reaches Claude's own transcript on trackpads.
Environment
Problem
In a Claude session I can no longer scroll back through the terminal output. Scrolling up with a two-finger swipe only reaches roughly one screen (~34–36 lines); as new output arrives, older lines disappear and I can't scroll back to them. This used to work normally around 1.2.x — a plain two-finger scroll reached the terminal's scrollback.
Steps to reproduce
Expected: reach the top of the output (line 1).
Actual: only reach ~line 34–36; earlier lines are gone and can't be scrolled back to.
What I found while digging (may help narrow it down)
CSI ?2026h/l, ~2130 of them) and absolute cursor addressing (CSI <row>;<col>H, ~2130), with 0 newlines in the whole stream. So Claude Code (≥ 2.1.187) repaints the viewport in place and never scrolls output into the terminal's scrollback.tmuxconfirms the pane is in the alternate screen withhistory_size=0._shouldForwardWheelToApp(from feat(web): restore tap/click/wheel mouse interaction when server strips mouse DECSETs #144) forwards the plain wheel to the CLI for claude ≥ 2.1.187 (so Claude scrolls its own transcript), and moves the local xterm scrollback onto Shift+wheel.deltaY ≈ 0), so theShift+wheelbranch of the container wheel handler never fires. Combined with the point above, there doesn't seem to be a working gesture for a trackpad user to page back through a Claude session's history.Expected behavior
A macOS trackpad user should be able to scroll back through a Claude session's history the way it worked in ~1.2.x.
Possible directions (just suggestions)
Happy to test patches or provide more captures.