v2.7.2 - Mobile scroll pacing fix
Scrolling the terminal on your phone moved about a fifth as far as your finger did. Drag up an inch, get a fifth of an inch of content. This release makes it one to one, and settles a question that had been sitting open since remote access shipped: whether you can actually tap the options when Claude asks you something.
Scrolling that keeps up with your finger
The mobile scroller does not scroll anything itself. Claude Code runs on the alternate screen with mouse reporting on, where there is nothing local to move, so a drag gets translated into synthetic wheel events, encoded as mouse reports, and sent up the socket. Something at the other end decides how far the content travels.
The client was calibrated for the wrong something. It assumed tmux would handle the report, because tmux's default binding scrolls five lines per wheel notch, so it emitted one report for every five rows of finger travel. But tmux only handles the report when the program inside the pane does not want it. Claude Code does want it. A live pane reports alternate_on=1 and mouse_any_flag=1, tmux forwards the report straight through, and Claude Code scrolls exactly one line per report. Send it one, get one line. Send it six, get six.
So the client was dividing by five against a program that multiplies by one, and the content crawled. The fix is that same constant set to one.
There was a second bug hiding behind the first. When a single drag produced more travel than the client would emit in one pass, the leftover distance was thrown away rather than carried forward. At the old calibration you needed a 255 pixel flick in a single frame to trigger it, which is why nobody hit it. Correcting the calibration would have dropped that threshold to 51 pixels and made it fire constantly, quietly eating part of every fast swipe. Both had to change together. The leftover distance now carries into the next pass instead of vanishing.
The drag phase also used to emit on every touch event, and phones deliver those faster than they paint. It now batches to one pass per animation frame, the same way the momentum loop already did.
Measured on the real build against the previous one, an identical 200 pixel drag at a 17 pixel row height produced 2 lines of movement before and 12 after, against 11.76 rows of actual finger travel. A 400 pixel flick now lands 23 lines with nothing dropped.
Worth saying plainly, since it was the first theory and it was wrong: this was never a network problem. It felt worst over a tunnel, which pointed suspicion at latency and at flooding the connection with reports. Claude Code's repaint after a scroll is a differential update of roughly 190 to 450 bytes with no idle chatter, so even a fast flick is a few tens of kilobytes per second. The lag was identical on a local network. It was arithmetic the whole time.
This one is a regression, and it is worth being honest about how it happened. Before the terminal was rewritten in v2.7.0, the client sent raw pixel deltas and let xterm accumulate them, which worked out to one report per row by accident. The rewrite replaced that with an explicit calculation and picked the tmux number, correcting an over-scroll that only ever existed on a code path Claude Code never takes.
Tapping the options when Claude asks
This was an open question rather than a reported break, and the answer is that it works. A tap on an option row sends a click report, and Claude Code both selects and confirms that option from it. No arrow keys, no on screen key row, nothing else needed.
Two things to know. The trust prompt you get before the session starts is keyboard only, because at that point nothing has turned mouse reporting on yet, so tapping an option there does nothing and you need the arrow keys. And the rows are small, about 11 pixels tall at 60% zoom, so tapping is accurate but fiddly. Zooming in first helps.
Full changelog: v2.7.1...v2.7.2
Requires Node ≥ 22.22, tmux, ttyd, git, and the Claude Code CLI. Reaching the board remotely also needs cloudflared, which Dispatch checks for only when you enable remote access. Setup is in the README.