Mouse wheel scrolls Claude Code input instead of terminal history

[lucieleblanc]

Summary

A user reported that when using Claude Code in Warp, mouse-wheel or trackpad scrolling scrolls the Claude Code input line instead of the terminal output/history. This makes it difficult to review prior output while working.

This may be related to terminal mouse/scroll reporting behavior; turning off Warp's mouse and scrolling reporting setting may be a workaround.

Steps to reproduce

1. Open Claude Code in Warp.
2. Produce enough output that scrolling back is needed.
3. Use mouse-wheel or trackpad scrolling while Claude Code is active.

Expected behavior

Scrolling should let the user review terminal output/history.

Actual behavior

Scrolling affects the Claude Code input line instead of the terminal output/history.

Additional context

Reported from internal Slack: https://warpdev.slack.com/archives/C08KTPNQN65/p1780419159949509

[warp-for-oss]

@lucieleblanc

Here's what I found while triaging this issue:

This looks consistent with Warp forwarding scroll events to a terminal app that has mouse/scroll reporting enabled. As a temporary workaround, try toggling off Scroll Reporting or Mouse Reporting from Warp's View menu; this may restore Warp-side history scrolling, but can change mouse behavior inside TUI apps.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a short screen recording showing the scroll gesture while Claude Code is active?
2. Which Warp version/channel were you using when this happened?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude Code appears to be receiving wheel/trackpad scroll events through Warp's terminal mouse/scroll reporting path, so scrolling affects the app input instead of Warp scrollback/history..

Triage summary

This looks like a Warp terminal mouse/scroll reporting interaction with Claude Code rather than a general scrollback rendering issue. The report says wheel/trackpad scrolling is consumed by the active Claude Code UI/input instead of moving through Warp terminal history, and Warp currently has code paths that forward scroll-wheel events to terminal apps when mouse and scroll reporting are enabled.

Reproducibility

Medium. The reported steps are concrete and match a plausible code path, but the public issue does not include OS/version details, Warp build/channel, or a recording, and I did not independently reproduce it during this pass.

Likely root cause

Claude Code likely enables terminal mouse tracking while it is active. In that state, Warp may send scroll events to the running terminal app as mouse-wheel input instead of handling them as scrollback/history navigation. The relevant implementation areas are terminal mouse/scroll reporting settings, alt-screen scroll handling, block-list handling for long-running commands, and ANSI terminal mode tracking.

Duplicate check

I checked the open issue list and recent closed issues. There are related issues about mouse reporting, trackpad behavior in TUI apps, and Claude Code rich input, but I did not find two or more likely duplicates with the same symptom.

Suggested follow-up

A short screen recording and the reporter's Warp version/channel would help confirm whether this is the expected mouse-reporting path, a regression, or a Claude Code/version-specific interaction.

Question reasoning

1. Can you attach a short screen recording showing the scroll gesture while Claude Code is active? — The issue is a visual/input-routing symptom, and a recording would confirm whether the scroll is being consumed by Claude Code's UI/input area versus failing to move Warp scrollback at all.
2. Which Warp version/channel were you using when this happened? — The public report was copied from an internal Slack report without version details, and the version/channel would help determine whether this is a current regression or an existing terminal reporting behavior.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[singhbad]

this is same in MobaXterm too

[mebius-san]

I have this issue on my end, the "toggling off Scroll Reporting or Mouse Reporting" workaround is not working.

[ScottNybo-CL]

This behavior is also present in vscode-server (docker container) terminal on linux. Have not been able to find a workaround.

[Fredrik-Petersson]

Got the same issue as well in MobaXterm. I am using tmux to keep the session alive.

[sheiddy]

Run this inside claude code cli and it should work as expected:

/tui default

[Fredrik-Petersson]

Run this inside claude code cli and it should work as expected:

/tui default

Thanks for replying but I was already in the default mode and the command made no difference. For me it looks like the scroll back works when not using tmux so in my case it may be a conflict between using the session manager and claude code.

[Fredrik-Petersson]

Looks like there is a lot of issues with at least MobaXterms terminal implementation that conflicts with tmux so I started to run Claude Code directly without any session handler (as I am on a local network with no connection issues) and now the scrolling works as expected. Maybe Warp has a similar implementation as tmux does conflicting with some other terminal applications. It also appears as if you connect from Windows or Linux can make a big difference.