[BUG] Scroll wheel intercepted by prompt history navigation — no way to disable

Real-world impact: this was one of the main reasons I moved part of my daily workflow to OpenAI Codex CLI.

Environment: Claude Code v2.1.173, macOS (Apple Silicon), Ghostty-based terminal (cmux), Logitech MX Master 3.

Like most terminal users, my muscle memory is: arrow keys = recall input history, mouse wheel = scroll back through output. Codex CLI and Gemini CLI both honour this — they don't enable mouse reporting, so the terminal's native scrollback just works. Claude Code grabs the wheel and converts it to prompt-history cycling in the main view; in Ctrl+O transcript mode on Ghostty the wheel does nothing at all (#67633). Reading what the model produced is the core loop of using these tools, and right now it fights the user.

Things I tried that don't help: Ghostty mouse-reporting = false, scroll multiplier tweaks. The only working workaround is CLAUDE_CODE_DISABLE_MOUSE=1, which restores perfect native wheel scrolling — I now have it permanently in my ~/.zshrc.

Request: either make wheel scrolling scroll the transcript (like every other pane-based TUI), or ship a supported setting to opt out of mouse capture. The fact that the "disable the mouse" escape hatch improves the mouse experience says it all.

There is a supported way to disable this — it's just buried in the fullscreen-rendering docs. The wheel is captured because the fullscreen (alternate-screen) renderer became the default around 2.1.172.

• Restore native terminal scrolling: run /tui default, or for a permanent hard override add to ~/.claude/settings.json:

``json
{ "env": { "CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN": "1" } }
``
The classic renderer keeps the conversation in your terminal's native scrollback, so the wheel works as before.

• Keep flicker-free fullscreen but stop mouse capture: set CLAUDE_CODE_DISABLE_MOUSE=1 (scroll Claude's own view with PgUp/PgDn).

Docs: https://code.claude.com/docs/en/fullscreen

ITERM workaround.. in other comments i will try with another terms

Environment

• Claude Code 2.1.178, fullscreen renderer (/tui fullscreen)
• macOS, iTerm2 3.6.11, TERM=xterm-256color

Root cause

The fullscreen renderer uses the terminal's alternate screen buffer. By default, iTerm2 translates the scroll wheel into ↑/↓ arrow keys when an app is in alternate-screen mode, and it isn't forwarding wheel events to the app. Claude receives the arrow keys, the prompt box treats them as history navigation, and Claude warns you. So the fix is terminal-side: stop the arrow translation and let iTerm2 forward real wheel events to Claude.

The fix (iTerm2 — 3 toggles)

1. Stop wheel → arrow translation

• Settings → Advanced → search "Scroll wheel sends arrow"
• Set "Scroll wheel sends arrow keys when in alternate screen mode" → No

1. Forward wheel events to the app

• Settings → Profiles → [your profile] → Terminal → Mouse reporting
• Enable "Enable mouse reporting"
• Enable "Report mouse wheel events"

No claude restart needed — iTerm2 applies these live. If it doesn't take effect immediately, toggle /tui fullscreen off/on or open a new tab to re-arm mouse tracking.

Optional scroll tuning (all verified in the 2.1.178 binary):

• CLAUDE_CODE_SCROLL_SPEED=3 — wheel scroll multiplier, clamped to 0.1–20 (3 ≈ vim default). Or run /scroll-speed for a live preview. (env var → needs restart)
• "wheelScrollAccelerationEnabled": false in ~/.claude/settings.json — disables wheel scroll acceleration.
• CLAUDE_CODE_DISABLE_MOUSE=1 — fully releases mouse capture (keeps native selection, but you lose wheel-scroll/click-to-position; accepts 1 or true). (env var → needs restart)

Keyboard scroll (always works, any platform): PgUp / PgDn, and Ctrl+Home / Ctrl+End to jump to top/bottom. On Mac: Fn+↑ / Fn+↓.

<img width="970" height="624" alt="Image" src="https://github.com/user-attachments/assets/c25e9fac-f9fd-498d-b24d-67ae3cf18a8b" />

<img width="1018" height="503" alt="Image" src="https://github.com/user-attachments/assets/e209ef4a-4234-4a0d-a1ce-2bb45ba5cbc6" />

Adding a Windows data point plus a usage-frequency argument for prioritisation.

Environment: Claude Code, fullscreen / alternate-screen renderer (now the default since ~2.1.172), Windows 11.

This is a default-behaviour regression, and the core of it is a frequency mismatch: binding the mouse wheel to prompt-history navigation optimises for the rarest action at the expense of the most common one.

• Scrolling back through output: on the order of hundreds of times a day.
• Recalling a previous prompt from history: maybe once a week.

The new default has those exactly backwards — the wheel now drives the ~weekly action, and there is no wheel path left to the ~hourly one. Arrow keys are already the natural (and previous) home for history recall; the wheel's natural home is scrollback.

/tui default and CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 do restore the old behaviour, but an opt-out buried in the fullscreen docs doesn't undo a regressed default — most users hit the broken behaviour first and never find the setting.

Request (same as the OP): make the wheel scroll the transcript by default (or cursor-aware so it scrolls whatever the pointer is over), and keep history on the arrow keys. At minimum, surface the toggle prominently instead of in the fullscreen renderer docs.

Still reproducing on v2.1.206 (macOS 26.4.1, Ghostty 1.3.1, fullscreen renderer / "tui": "fullscreen").

Scrolling the mouse wheel while the pointer is over/near the prompt input box navigates prompt input history (like Up/Down) instead of scrolling the conversation. The changelog mentions this was fixed once in v2.1.160, but it's back.

What I want is narrow: keep fullscreen, keep wheel-scrolls-transcript, but have the wheel never touch prompt history. Ideally one of:

• a config toggle (env var / settings.json / /config) to disable "wheel over prompt = navigate history", or
• context-aware scrolling: wheel over the transcript scrolls the transcript; wheel over the prompt box scrolls the transcript too (or does nothing) — but never cycles input history.

The existing controls are all too coarse for this:

• CLAUDE_CODE_DISABLE_MOUSE=1 — kills the wheel entirely
• CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 — drops clicks, but the wheel still hits history
• wheelScrollAccelerationEnabled / CLAUDE_CODE_SCROLL_SPEED — speed/acceleration only

Going back to the classic renderer "fixes" it (native terminal scrollback) but sacrifices the whole reason to run fullscreen. A targeted option to decouple the wheel from prompt history would be the ideal fix. 👍

Still broken in 2.1.218.

Also, copy on select is broken, as is clicking into the text field to place the cursor.

this is actually pissing me off so much can someone please fix this no I don't want to use my mouse wheel to scroll through my prompt history

the entire terminal is fucked with this new agent orchestration whatever shit it is like i just want to use claude one agent in one terminal can there not be like a /simple mode or something

Still reproducing on 2.1.220 — Windows 10, Windows Terminal / PowerShell, fullscreen renderer.

Exact OP symptom: the wheel arrives as arrow keys, cycles prompt input history, and the "Scroll wheel is sending arrow keys · use PgUp/PgDn to scroll" banner shows.

On Windows there is no terminal-side escape hatch equivalent to the iTerm2 toggles posted above, so the only real fix is abandoning fullscreen entirely: /tui default (or "tui": "default" in ~/.claude/settings.json), which restores native scrollback and normal wheel behaviour — at the cost of losing the fullscreen renderer altogether.

+1 to the frequency argument above: scrolling back through output is a hundreds-of-times-a-day action, history recall a rare one — the wheel should never drive history. A targeted toggle (or context-aware wheel) would let Windows users keep fullscreen.