v2.1.150: scroll wheel no longer scrolls conversation — sends arrow keys instead

I saw this in one chat, but not in others in 2.1.156. resuming the same chat that had this problem in another terminal did not exhibit the issue.

I have the same issue for a few days.

• OS: Ubuntu 26.4
• HW: AMD x86_64
• Claude: v2.1.168
• Terminals: Ptyxis (Ubuntu default), Tilix, Foot, Mate Terminal, and others

Scrolling still works in other TUI apps (mc, vim) and worked in claude before.

Yes, and some keyboards don't even have the PgUp/PgDn keys.

Yes, and some keyboards don't even have the PgUp/PgDn keys.

Like mine 😢 Is there a workaround?

> Yes, and some keyboards don't even have the PgUp/PgDn keys. Like mine 😢 Is there a workaround?

Haven't found anything so far, it's so annoying

This is so annoying,.... it's not usable at all.

@claude is there way to rollback/disable? There are plenty of keyboards without PgUp/PgDn so you have to use combinations...

Please provide workaround

This one helped me: https://github.com/anthropics/claude-code/issues/12953#issuecomment-4556388031

This one helped me: #12953 (comment)

Confirmed /tui fullscreen then /tui default fixed it for me Thanks!

The newest version v2.1.169 helped me.

Seen in version - Claude Code v2.1.173

it is annoying

Still reproduces on v2.1.174 (current), so this is not yet fixed.

Environment: WSL2 (Ubuntu 24.04), native terminal, TERM=xterm-256color, not in tmux, with "tui": "fullscreen" set in ~/.claude/settings.json.

Symptom: identical to the original report. Mouse wheel up no longer scrolls the transcript; it cycles the prompt input box backward through previously-typed prompts (arrow-key behavior). It appeared on an auto-update and survived a full reboot.

Workaround that restores native terminal scrollback: removing "tui": "fullscreen" from ~/.claude/settings.json (reverting to the default non-fullscreen TUI) lets the terminal handle wheel scrollback again. The trade-off is losing fullscreen rendering. CLAUDE_CODE_DISABLE_MOUSE=1 also disables the mouse capture, but per #66808 and #62294 it leaves scrollback only partly working (full-page granularity, no line-level scroll).

Request: make mouse-wheel transcript scrolling work inside the fullscreen TUI, or expose a dedicated setting to keep wheel events as native terminal scrollback rather than mapping them to input-history navigation.

still broken @ cc 2.1.175
tui: default - is a workaround

As a work around while we wait for a fix, I found that going to .claude/settings.json and changing tui to "fullscreen", then back to default while the window was open seemed to fix it.

I wasn't able to simply switch between fullscreen and default via /tui alone (Claude v2.1.175) but with the help of Claude itself, it told me that it has to do with the renderer being used and that if I did the following it would fix it.

1. Add the following to your settings.json/settings.local.json

"env": {
    "CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN": "1"
 }

1. Run "/tui default". This should cause Claude code to reload and pick up the new setting.

Once I did these two things, I am able to get scroll back properly. It does seem to remove things like "jump to the end" feature of the other renderer, but this might be a good solution until it is fixed. I am making a note myself to come back in a few versions and see if it has been fixed to then remove the setting.

I hope it solves the problem for people.

Honestly, this kind of interface thrashing is kind of worrying. Did anyone look at this and say "yes! our users have been clamoring to use PGUP/PGDN"

FWIW this is my workaround:

• DISABLE_MOUSE releases mouse capture, so the wheel goes to the terminal instead of Claude.
• DISABLE_ALTERNATE_SCREEN keeps output in native scrollback, so there's something for the wheel to scroll.

CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude

Also seeing it @ cc 2.1.175.
Workaround - Not using TUI

FWIW this is my workaround: DISABLE_MOUSE releases mouse capture, so the wheel goes to the terminal instead of Claude. DISABLE_ALTERNATE_SCREEN keeps output in native scrollback, so there's something for the wheel to scroll. CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude

god bless you! :D

I can't believe there's no official fix yet for this (very) annoying issue...

Disabled TUI

Using CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 OR /tui default disables the new renderer.
CLAUDE_CODE_DISABLE_MOUSE=1 just disables mouse interactions (which are awful enough.

I'm guessing the whole feature was done by Claude unsupervised.

type /tui default to fixed

Also hitting this on macOS

• OS: macOS (Darwin 24.6.0)
• IDE: PyCharm 2025.2
• Claude Code JetBrains plugin: 0.1.14-beta
• CLI: reproduces on 2.1.179 and after upgrading to 2.1.193

It's annoying as hell. Please fix

If you use Warp on MacOS:

1. open settings
2. features
3. in the "Terminal section" enable the options "Enable Mouse Reporting" and "Enable Scroll Reporting"
4. restart Claude
5. now /tui fullscreen works good and mouse scroll scrolls the view, not the commands history

Found that on MacOS the issue appears with some third party scrolling apps like Smooze and SmoothScroll as they send arrow key events. Disabling animation with these apps and sending scroll events fixes the issue.

/tui default fixed it for me. The new mouse interactions are awful. Every time I clicked in the window to get focus it would interpret that as an answer to a question. I want to scroll to view conversation not, scroll in the input box. I turned off all the mouse interactions. Yeah it does look like Claude coding Claude without a human looking at it and saying yeah that sucks.

why would i ever want to scroll through prompts instead of using the arrow keys? roll this back please

Thsi desperatly needs fixing. it makes the cli unusable.

OS: macOS (Tahoe 26.5.2)
IDE: Rider 2026.1.4
Claude Code JetBrains plugin: 0.1.14-beta

I've tried everything and nothing seems to resolve it permanently. Sometimes scrolling will work, but often times not. Just cycles through my input history.

Seems like I'm stuck with having to hold down the fn + arrow keys to scroll history until this is fixed.

UPDATE: This only appears to be an issue for claude agents . Having CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 and only using claude and /resume for resuming that specific session allows me to scroll history.

Is there any way to disable the agents view, so this doesnt happen?

It's now very annoying to use via termux on android phone, now you must have the keyboard up in order to scroll, which drastically reduces the experience and amount of text, and scrolling is repeatedly tapping a tiny hit target instead of swiping - please please add an option to restore arrows for message window.

+1

This is still a problem in version 2.1.222.

+1 to the other comments here. This change is garbage. Rarely do I scroll back through prompts. Frequently, I scroll the conversation. Now I have to take my hand off the mouse and find my pgup/pgdn keys to do what should be a simple hands-on-mouse wheel interaction. One would argue that the most frequently-used operation should also be the one that does not require you to switch between physical devices.

Guys - stop making the TUI "better" like this. Ridiculous.

I don't get how this became a feature. Seriously, how does this make sense?

In the space where I naturally find myself using the keyboard, I will activate mouse scrolling, and in the space where I hover over with my mouse, I will require using the keyboard. Huh? I would love to understand where this feature came from. When did someone want to "ctrl + r" effectively through previous commands and think, "You know what? What I need here is to scroll without any indication of the scale of the history I'm scrolling through." Therefore, having some scroll-type momentum will allow me to find my previous command faster. And who is reusing previous chat prompts that often, anyway?

Not least the fact I can't really tell before getting slapped in the face by it when or not this is activated. Then I get a helpful little warning: "Scroll wheel is sending arrow keys · use PgUp/PgDn to scroll."

YOU KNOW WHAT? MY MAC KEYBOARD DOESN'T HAVE PGUP AND PGDN KEYS, SO I LITERALLY NEVER USE THEM... And now I'm trying to find out where they are...

Sorry, that's a rant... But is there likely to be a resolution on this or not? I.e., is it in scope to revert or solve?

Some of it is configurable via terminal settings, but some environments, like termux android are a pain in the butt. I even tried forking termux to add this configuration, but the software registry depends on the package name, and you can't take over the package name. It's a pain.

I ended up writing my own harness and using qwen 3.8 over this crap.

With all the compute in the world it takes 3 months to fix the mouse wheel behaviour? Where are those 10X engineers when you need them, guess not at Anthropic

@anthropics / @claude any idea what's happening with this bug?

is CLAUDE_CODE_DISABLE_MOUSE=1 the workaround?

I was never having this problem until today. I had no idea know what changed, I just assumed it was a big weird change in one of the multiple daily update downloads I have been seeing lately (seems like an excessive update frequency?).

Eventually I figured out that Opus had decided for some reason to stealthily change the _current active_ conversation to a "background" conversation (and we remained actively in it) and somehow that changes the UI and messes up the scroll wheel in this way. Once I used /stop and /exit and restarted Claude Code CLI, I could once again scroll up through the conversation output with the mouse wheel.

I agree with others - I don't know why I would ever opt for that mouse wheel behavior.

Okay, the root of this bug is that claude turned on TUI w/ mouse wheel handling, but they forgot that there are a decent number of terminal emulators that don't pass mwheel, but use arrow keys.

They wanted the arrow keys for editing the input message (when multi-line) and when selecting options for answers.

But what they didn't do, is make it so if it's not multi line, or if you were at the top or bottom of your selection, that you scrolled the message view.

This is all too random. One session gets active and then you have to exit and resume