Right-click paste broken since ~2.1.167: mouse reporting captures right-click, requires Shift+right-click workaround

Confirming this regression on additional platforms not yet listed here — Claude Code v2.1.186.

• macOS Terminal (Terminal.app): right-click does nothing — no context menu, no paste.
• KDE Konsole 25.08.01 on Ubuntu 25.10 (kernel 6.17), accessed over RDP via Microsoft "Windows App": right-click does nothing.
• Konsole locally on Linux: native select + right-click broken; only Shift+right-click works.

So the Shift+right-click bypass is inconsistent: it works in some terminals but on macOS Terminal and Konsole over RDP there's no working right-click path at all, leaving no reliable copy/paste. The in-app scrolling is nice, but losing native copy/paste by default — with no opt-out — is a real, cross-platform regression.

Request: please add a persistable setting to disable mouse tracking, e.g. "enableMouseTracking": false (or "mouseReporting": false) in settings.json.

Breaking copy/paste (or Linux middle-click) is like breaking the ENTER key. It is such basic functionality that NO application, under ANY circumstances, should EVER break it.

Move fast and break things, I get it ... but don't break the damn operating system!

This seems to be doubly broken when trying to yank with y in tmux. This was a really important part of my workflow. Sonnet could not figure it out, but Opus did, at the cost of breaking the ability to scroll 🤦. I hope I don't have to start regularly burning my tokens fixing problems caused by speed-over-perfection:

  Setup: Claude Code 2.1.195, fullscreen TUI ("tui": "fullscreen"), inside tmux (mouse on), X11.

  Issue: Can't drag-select text in the Claude Code pane. Fullscreen renderer grabs mouse → app asserts xterm mouse reporting (\033[?1000h) → tmux sees app wants mouse, keeps
  mouse_any_flag=1, routes drag to app instead of entering copy mode. Drag selects nothing, y yanks nothing. Other panes fine.

  First fix — failed: CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1. Only kills internal click handling; app still emits the mouse-reporting escape. Not a real documented var. Proof:
  $ env | grep CLAUDE_CODE_DISABLE_MOUSE
  CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1
  $ tmux display -p "#{mouse_any_flag}"
  1          # still grabbing

  Actual fix: CLAUDE_CODE_DISABLE_MOUSE=1 (documented under fullscreen docs, "Keep native text selection"). Opts out of mouse capture, keeps flicker-free render. App stops asserting mouse
  reporting → mouse_any_flag → 0 → tmux handles drag → copy mode → y yanks again.
  // ~/.claude/settings.json
  "env": { "CLAUDE_CODE_DISABLE_MOUSE": "1" }
  Verify: tmux display -p "#{mouse_any_flag}" → 0.

  Trade-off: lose in-app click-to-cursor / click-expand / Ctrl-click URL / wheel-scroll. Keyboard scroll stays. One-off alt: Shift+drag. Nuke-fullscreen alt:
  CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1.

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

I'd say, just invert the logic: press shift for claude-only actions, per default terminal default behaviour.

Version: 2.1.196
OS: macOS
Terminal: iTerm2
Issue: Cannot select or copy text from Claude responses. Right-click does not show context menu. The problem appeared recently — was working fine in previous weeks.
Workaround tried: Fn+select, Option+select — neither works on this setup.

Still reproducible on version 2.1.196 (macOS + iTerm2). Cannot select or copy text from Claude responses. Right-click does not show context menu. Fn+select and Option+select workarounds do not work on this setup.

It is becoming worse.
It is not just inconvenience, I cannot copy anything in either mode.
So it is really buggy.
If in claude-copy mode, I get broken incomplete lines. If claude-copy is disabled (and I have to use shift nonetheless), it looks like I can copy in the context menu, but the clipboard is empty.

The only way to get output from claude is to ask him to write to a file. terminal content cannot be copied at all in no way.

Additional reproduction + workaround (Linux / gnome-terminal / VTE 0.76.0)

Environment:

• Claude Code 2.1.183
• Linux Mint (Ubuntu 24.04 base)
• gnome-terminal 3.52.0 with VTE 0.76.0
• TERM: xterm-256color

Observed behaviour:

• Right-click: no context menu (mouse event consumed by Claude Code)
• Shift+right-click: also produces no menu (unlike the workaround in the issue body — may be VTE 0.76.0 specific)
• Shift+Ctrl+C with text selected via normal click-drag: clipboard unchanged (selection never registers with VTE because mouse events are intercepted)
• Shift+Ctrl+V: works fine (paste doesn't require a VTE selection)
• Setting TERM=xterm before launching has no effect — mouse tracking is enabled unconditionally

Root cause (confirmed): Mouse tracking mode prevents VTE from registering click-drag as a text selection, so there is nothing for Shift+Ctrl+C to copy.

Working workaround:
Hold Shift while click-dragging to select text — this forces VTE to handle the mouse event for selection rather than passing it to Claude Code. After selecting with Shift+drag, Shift+Ctrl+C copies correctly.

The Shift+right-click workaround documented in the issue body does not appear to work on gnome-terminal 3.52.0 / VTE 0.76.0.