[BUG] Mouse wheel scroll triggers prompt history navigation instead of scrolling conversation (macOS + Warp)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet for this exact platform/terminal combination (see "Additional Information" for related-but-not-identical issues)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When scrolling with the mouse wheel inside a Claude Code interactive session running in Warp on macOS, the scroll is intercepted as prompt history navigation (as if Up/Down arrow keys were pressed) instead of scrolling the conversation viewport / terminal scrollback. Scrolling up cycles backwards through previously submitted prompts in the input box rather than revealing earlier assistant/tool output.

This makes it impossible to review earlier turns of a long session using the mouse wheel.

What Should Happen?

Scrolling the mouse wheel up/down should scroll the conversation viewport (or fall through to native terminal scrollback) so previous turns can be reviewed, without touching the prompt input's history cursor.

Error Messages/Logs

No error is printed; this is a silent input-handling/UX issue, not a crash.

Steps to Reproduce

1. Open Warp on macOS and start a new interactive Claude Code session (claude).
2. Send a few prompts so there is scrollback/history to review (both conversation turns and submitted-prompt history).
3. Move the mouse over the terminal pane and scroll the wheel upward to try to view earlier conversation turns.
4. Observe: instead of the viewport scrolling, the input box cycles to a previously submitted prompt (as if pressing the Up arrow key repeatedly).

Control test: running codex (OpenAI Codex CLI) in the exact same Warp window/profile and repeating steps 2-4 scrolls the conversation correctly, which suggests this is specific to how Claude Code's TUI in Warp is currently handling mouse-wheel input, not a Warp-wide terminal setting.

Claude Model

Not applicable / not model-specific — reproduces regardless of which model is active.

Is this a regression?

I don't know

Last Working Version

Claude Code Version

2.1.199 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Warp

Additional Information

• macOS version: 26.5.1 (Build 25F80)
• Warp version: v0.2026.06.24.09.19.stable_02
• TERM=xterm-256color, TERM_PROGRAM=WarpTerminal
• CLAUDE_CODE_DISABLE_MOUSE is not set in my environment (default/enabled), so this is not the same trigger as issues that report this symptom only after explicitly setting CLAUDE_CODE_DISABLE_MOUSE=1.
• I inspected the installed Claude Code binary (~/.local/share/claude/versions/2.1.199) and confirmed it does emit mouse-tracking enable sequences (\x1b[?1000h, \x1b[?1006h), so mouse reporting is being requested — the issue appears to be in how the resulting mouse-wheel events (or Warp's translation of them) are handled/dispatched once received, at least in this Warp + macOS combination.
• Related (but not identical — different platform/trigger) reports that may share a root cause and could help with triage: #66601 ("Scroll wheel intercepted by prompt history navigation — no way to disable", Windows), #65833 ("scroll wheel no longer scrolls conversation — sends arrow keys instead", WSL, regression), and #70724 (same symptom but only reproduces with CLAUDE_CODE_DISABLE_MOUSE=1, Windows/fullscreen). None of these are reported specifically for macOS + Warp with default settings, which is why I'm filing separately.
• Happy to provide a screen recording or claude --debug output if useful.