[BUG] Agent View (Linux): mouse wheel sends arrow keys instead of scrolling attached session — works on macOS, fails on all Linux terminals

Status Open

Reported on v2.1.158

Maintainer reply None cached

Activity 4 comments · opened May 31, 2026

What happens

When I attach to a background session in Agent View (claude agents → select an agent → Enter), the mouse wheel emits cursor up/down keys (it walks the prompt input) instead of scrolling the session transcript. Claude shows the warning:

Scroll wheel is sending arrow keys · use PgUp/PgDn to scroll

PgUp/PgDn do work for scrolling. The mouse wheel scrolls correctly in normal foreground sessions (classic renderer) — only the attached fullscreen Agent View is affected.

This is platform-specific, not a terminal issue

| | Result |
|---|---|
| ❌ Linux (Ubuntu, Wayland), Terminator / VTE 0.84 | wheel → arrow keys |
| ❌ Linux (Ubuntu, Wayland), kitty 0.47.1 | wheel → arrow keys |
| ❌ Linux (Ubuntu, Wayland), Ghostty 1.3.1 | wheel → arrow keys |
| ✅ macOS, Ghostty | wheel scrolls the transcript correctly |

Same Ghostty codebase behaves differently per-OS, and three different Linux terminals fail identically — so the terminal is ruled out. This is Linux-specific.

Likely cause (from inspecting the 2.1.158 build)

The attached/focus fullscreen view sends DECSET ?1000h / ?1006h (mouse tracking) plus ?1007h (alternate-scroll). On Linux the wheel is delivered as arrow keys (the ?1007h path) rather than as SGR mouse-wheel events — i.e. mouse-wheel capture isn't taking effect for this view on Linux. The internal tengu_scroll_arrows_detected path fires the warning. On macOS the wheel is captured as mouse events and scrolls.

Steps to reproduce

On Linux: claude agents
Select a background agent, press Enter to attach
Scroll the mouse wheel over the transcript
Observe: the prompt/input moves (arrow keys) and the "Scroll wheel is sending arrow keys" warning appears; the transcript does not scroll. PgUp/PgDn does scroll.

Expected

The mouse wheel scrolls the attached session transcript on Linux, exactly as it does on macOS.

Environment

Claude Code 2.1.158
Linux, Ubuntu, Wayland session
Terminals tested: Terminator (VTE 0.84), kitty 0.47.1, Ghostty 1.3.1
/tui renderer: default (the attached view forces fullscreen regardless)

#59901 — Agent View attached scroll completely broken on macOS (all scroll incl. PgUp dead); same area:agent-view render path, different symptom
#59093 — attached-session scroll buffer limited to ~10 lines

View original on GitHub ↗

4 Comments

henricook · 3 months ago

This _might_ be fixed in 2.1.159 but release notes don't mention it - did you already start work here @bogini 🙏🏻 or did one of the various workarounds I'd tried start working?

ewanwang1 · 1 month ago

same issue on linux

ildeb · 1 month ago

Workaround found: running Claude Code inside GNU screen

For anyone hitting this on native Linux — running claude inside a screen session works around the issue, though it's not automatic:

Start screen, then run claude as usual
Press Ctrl+A then Esc to enter screen's copy mode
From there you can scroll with the up/down arrow keys or the mouse wheel
Press Esc again to exit copy mode and go back to typing prompts to Claude

So it's an extra couple of keystrokes each time, but it reliably restores scrolling without needing PgUp/PgDn.

Environment: Claude Code 2.1.220, Linux Fedora release 42 (Adams)

Not a real fix, but a solid workaround until this is addressed.

deltaepsilon · 1 month ago

Also hitting this on Linux/Wayland.

OS: NixOS 26.11 (Wayland session)
Terminal: Ghostty 1.3.1 (GTK runtime, OpenGL renderer)
Claude Code: 2.1.191

Symptom: scrolling the mouse wheel while focused in the input recalls previous prompts (Up-arrow history) instead of scrolling the transcript — i.e. the wheel is being delivered as arrow keys.

Confirmed at the compositor level with wev: a plain wheel scroll emits only wl_pointer.axis / axis_value120 events and no button events (no BTN_MIDDLE), so this is not a stray middle-click / primary-selection paste — the wheel→arrow-key translation is happening downstream in the alt-screen mouse handling. PgUp/PgDn scroll correctly, matching the reported workaround.