[BUG] First mouse-wheel event after a scroll direction change is swallowed (macOS, Ghostty)

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 2, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When reversing scroll direction in the Claude Code transcript (default TUI, mouse
capture active), the first wheel event after the reversal is ignored:

  • With one wheel event per tick (Ghostty mouse-scroll-multiplier = discrete:1):

the first tick after a direction change does nothing; the second tick scrolls one line.

  • With three events per tick (Ghostty default discrete:3): a normal tick scrolls

3 lines, but the tick that reverses direction scrolls only 2. Alternating single
ticks up/down oscillate between two positions 2 lines apart instead of 3
(observed top lines: 6, 8, 6, 8 while same-direction ticks move 5 → 8).

Control experiment — the terminal delivers symmetric events. Same terminal, same
mouse, same mouse-reporting mode, using less:

seq 1 200 | less --mouse --wheel-lines=1

Scrolling down, the top line goes 4, 7, 10; back up 7, 4, 1; alternating down/up
yields 4, 7, 4, 7 exactly. less receives the same 3 events per tick and stays
perfectly symmetric, so the wheel events reach the application intact — Claude Code
drops the first event after each direction change.

What Should Happen?

Every wheel event scrolls the transcript by the configured step; a direction change
is not special. Alternating one tick down / one tick up should return to the same
position each time, as it does in less in the same terminal.

Error Messages/Logs

None — no error output; the event is silently dropped.

Steps to Reproduce

  1. Run claude in Ghostty on macOS and produce output longer than one screen.
  2. Scroll up a few ticks with a physical mouse wheel; note the top visible line.
  3. Scroll down one tick, then up one tick, alternating.
  4. Observe the off-by-one-event asymmetry described above.
  5. Compare with seq 1 200 | less --mouse --wheel-lines=1 in the same terminal:

less scrolls perfectly symmetrically with the same wheel input.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

  • Terminal: Ghostty 1.3.1 (not in the dropdown list), shell zsh.
  • Model: Fable 5 (claude-fable-5); the bug is in the TUI scroll handling and

model-independent.

  • Behavior is identical with and without scroll-acceleration normalization

(LinearMouse), so macOS pointer/scroll acceleration is ruled out.

  • Reproduced with both mouse-scroll-multiplier = discrete:1 and the Ghostty

default discrete:3, i.e. independent of how many wheel events one physical
tick produces.

View original on GitHub ↗