Mouse capture in TUI breaks Linux PRIMARY-selection middle-click paste (no opt-out)
Environment
- Claude Code: 2.1.153
- OS: Linux, Wayland session with XWayland
- Reproducible in any terminal, with or without tmux
Problem
The TUI enables xterm mouse reporting to support copy-on-select and
right-click paste (changelog entries in 2.1.151, 2.1.152, 2.1.153,
2.1.157, 2.1.160). Once mouse reporting is on, the terminal forwards
all mouse events to Claude Code and stops handling them locally. This
breaks the standard Linux workflow:
- Select text anywhere on the system (PRIMARY selection, served
by XWayland to X11 clients)
- Focus the terminal running Claude Code
- Middle-click to paste into the prompt
The middle-click is consumed by Claude Code; the PRIMARY selection is
never pasted. Drag-to-select inside the prompt is similarly hijacked.
Confirmed reproducible both inside tmux and in a plain terminal with
no multiplexer, so this is at the Claude Code layer (not tmux'''s
mouse mode or set-clipboard).
Shift+middle-click works as a bypass (terminal-level escape from
mouse reporting), but requiring a modifier for every paste is a
regression for users who rely on PRIMARY heavily — which is most
Linux desktop users.
Request
Add a settings.json key — e.g. mouseCapture: false orcopyOnSelect: false — that disables xterm mouse reporting and
returns mouse handling to the terminal. As of 2.1.153 there is no
such toggle (checked docs at code.claude.com/docs/en/settings and
grep'''d the installed binary; no CLAUDE_CODE_* env var covers it
either).
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
related, but not a duplicate! this issue report is about:
select with left + middle-click to paste
#65039 and #61936 are concerned about right click
#66056 is the closest to this.
looks like this is the nuclear option to get the desired behavior back:
an actual (fine grained) option would be nice(r) though :-)
Not sure why we have now 2 mouse buttons to paste: middle and right. Looks like right should be left for context menu...
On GNOME Terminal (VTE) the copy-on-select does nothing but still pops the "copied X chars" toast, so it looks like it worked. VTE ignores the OSC 52 clipboard write, so nothing lands - I only found out when a later paste dumped text I'd copied ages ago. The false success is the worst bit.
CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1fixes it by handing selection back to the terminal, but the toast shouldn't claim success when the write was dropped.