Repository navigation
Description
Environment
- Codeman: 1.3.0 (self-hosted, git install)
- Claude Code CLI: 2.1.204
- Browser: Chrome on macOS (desktop)
- 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.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.- On a macOS trackpad, holding Shift while two-finger scrolling is interpreted by the browser as horizontal scroll (
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)
- 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.
Happy to test patches or provide more captures.
Activity
fix(terminal): restore Claude scroll-back on macOS trackpads (#154)
Ark0N commentedon Jul 16, 2026
Thanks for bringing this up — and for the excellent write-up. Your analysis was spot on, and the PTY capture (all full-frame repaints, zero newlines) was the key that unlocked it.
Fixed in 1.3.3 (
7b79d42). What was going on and what changed:Claude Code vX.Y.Zstartup banner, which newer builds don't reliably print (and resumed sessions never show). With the versionundefined, forwarding was silently disabled and the plain wheel fell back to the (empty) local scrollback — exactly the "only ~one screen" symptom.claude --versionprobe seeds the CLI version at session start, so wheel-forwarding to Claude's transcript now engages. Plain two-finger scroll pages back through history again.deltaX) reaches local scrollback instead of collapsing to a fixed one-line-per-tick. This covers shell/non-repaint sessions where local scrollback actually has content.Verified end-to-end on a real 2.1.210 session (forwarded wheel actually scrolls the transcript). Ships in the 1.3.3 release. Thanks again!
feat(docker): thread SessionDocker through Session + recovery
fix(session): probe the Claude CLI version over ssh for remote sessions