[BUG] 2.1.143 regression: mouse wheel scrolls input history instead of chat transcript (Windows)

Status Fixed / completed

Reported on v2.1.143

Maintainer reply ✓ Yes — claude[bot]

Activity 12 comments · opened May 17, 2026 · closed May 19, 2026

💡 Likely answer: A maintainer (claude[bot], contributor) responded on this thread — see the highlighted reply below.

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report
[x] I am using the latest version of Claude Code

What's Wrong?

After upgrading to 2.1.143, scrolling up with the mouse wheel cycles through my prior input history — i.e. it behaves as if I pressed the Up arrow — instead of scrolling the chat transcript / scrollback window.

Downgrading to 2.1.142 fully restores the expected behavior. The regression only occurs on 2.1.143 sessions.

What Should Happen?

Mouse wheel up should scroll the chat transcript (prior assistant/user messages, tool output) upward in the viewport. Cycling input history should remain bound to the Up arrow key only.

Error Messages/Logs

_No error messages — purely a UI input-handling regression._

Steps to Reproduce

On Windows 11 with Windows Terminal + PowerShell, install Claude Code 2.1.143.
Trigger condition (newly isolated): only background / agent-view sessions are affected. A freshly started foreground claude session does NOT exhibit the regression. To reproduce, do one of:

Dispatch with claude --bg "<prompt>" then claude attach <id>, or
Open any regular session, run /bg to background it, then claude agents and attach back to it.

Generate a multi-screen transcript (any long response works).
Place the cursor anywhere over the terminal and roll the mouse wheel up.
Observed: the prompt input field cycles backward through prior user messages (Up-arrow behavior).
Expected: the chat transcript scrolls upward in the viewport.
Run claude migrate-installer / reinstall 2.1.142 — bug disappears.
Reinstall 2.1.143 — bug returns.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.142

Claude Code Version

2.1.143 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Possibly the same underlying change as #58364 (iTerm2 + tmux on macOS, mouse wheel hijacked to input history on 2.1.138 / 2.1.139). That report is mac-specific and lists 2.1.138 as the first bad version; this Windows reproduction first appears at 2.1.143, suggesting either the same mouse-input handler regression has now reached the Windows TUI path, or a fix on that earlier report did not generalize.

Related: #51393 (cannot scroll up in Windows Terminal — 2.1.x regression).

Update (after further isolation): the regression is confined to the agent-view / background-session code path. Foreground sessions on 2.1.143 do not exhibit the bug at all; only sessions reached via claude attach <id> or after a /bg → claude agents round-trip. This suggests the mouse-input handler is being remapped (or not properly restored) when a session passes through the supervisor-hosted bg path.

View original on GitHub ↗

12 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

claude[bot] contributor · 3 months ago

This issue was fixed as of version 2.1.144.

henricook · 3 months ago

This is not fixed, the mouse wheel behaviour is now even more shocking - mine looks like its sending arrow keys!

margohpolo · 3 months ago

Issue just appeared for me in 2.1.146, Windows Terminal. Did not encounter it prior when on earlier versions, even 2.1.143.

ubunatic · 2 months ago

Still broken in v2.1.168 (Ubuntu 26.4, Tilix, Ptyxis, and other Terminal apps)

nadavsheinbein · 2 months ago

Please reopen the issue - still active in v2.1.169

vecalion · 2 months ago

This is not fixed!

Kaju-Bubanja · 2 months ago

This is still happening in 2.1.169 (Claude Code), see this issue for more info: https://github.com/anthropics/claude-code/issues/65398#issuecomment-4623351578
It might be a duplicate, but it was definitely not fixed and is a regression!
Makes Claude Code unusable, you need to fix it and not just declare all the issues duplicates and fixed, when that it not true

TheSupremeGod · 2 months ago

Can confirm in 2.1.183, after going to the agent view and back into a session, scroll wheel behavior changes. I tried turning off mouse reporting in my IDE (pycharm) but nothing changed.

Aternus · 2 months ago

Still happens with 2.1.176

jiaoshi888 · 2 months ago

Still reproduces in Claude Code 2.1.195 — requesting reopen

This regression is still present in the current Claude Code release, six versions past the claimed "fixed in 2.1.144".

Environment

Claude Code: 2.1.195 (latest)
Windows Terminal: 1.24.11321.0 (stable, Store)
OS: Windows 10 LTSC 2021, build 19044.7417
Shell: PowerShell 7 inside Windows Terminal (also reproduces in bash shipped with Git for Windows)

Repro (matches title; identical to original report)

Open a Windows Terminal tab → claude
Let the TUI produce enough output to require scrollback
Try any of: mouse wheel up, Shift+PgUp, drag the scrollbar thumb
Mouse wheel cycles prompt input history (not the chat transcript); Shift+PgUp does nothing; the scrollbar thumb is non-draggable

Scope-narrowing observations (rule out WT / renderer)

Ctrl+O (in-app transcript viewer) works → CC has the buffer; it just denies the terminal access to it
Exit claude (Ctrl+D / exit) → WT scrollback is immediately usable in the same tab → CC TUI is what suppresses it
A pure PowerShell tab (no CC running) in the same WT process has a fully working scrollbar → not a WT renderer bug
experimental.useAtlasEngine: false in WT profiles.defaults does not change the behavior

Version history per this thread

The same regression has now been reported across at least: 2.1.143 (original) → 2.1.146 (margohpolo) → 2.1.168 (ubunatic) → 2.1.195 (this comment). The 2.1.144 "fix" did not hold and appears to have re-broken in a different code path.

Cross-reference

Related: #51393 (closed by the inactivity bot in May; pohy commented 2026-06-17 that the same behavior was still reproducing).

Requesting reopen + a fresh look at the input-handling code path that was changed around 2.1.143/144.

unic-rub · 1 month ago

try /tui default