CLAUDE_CODE_DISABLE_MOUSE_CLICKS does not disable right-click paste

Description

CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 does not disable right-click paste. Its name implies mouse clicks are ignored, but right-click still pastes the clipboard into the prompt. The only variable that stops it is CLAUDE_CODE_DISABLE_MOUSE=1, which also disables wheel scrolling — so there is currently no way to keep wheel scroll while suppressing click-driven paste.

Steps to reproduce

1. Copy any text to the clipboard.
2. Launch Claude Code with the variable set, e.g. in PowerShell:

``powershell
$env:CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1; claude
``

1. Left-click once in the input area, then right-click.

Expected behavior

With CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1, click-derived actions (including right-click paste) are ignored while wheel scrolling continues to work.

Actual behavior

Right-click still pastes. Verified across all three mouse modes on the same machine and version:

| Variable | Resulting mode | Right-click | Wheel scroll |
| --- | --- | --- | --- |
| (none) | full | pastes | works |
| CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 | scroll | still pastes | works |
| CLAUDE_CODE_DISABLE_MOUSE=1 | off | no paste | dead (PgUp/PgDn still works) |

Likely cause

From strings in the shipped binary (2.1.246), the mode selection is:

function Me(){
  if (n.CLAUDE_CODE_DISABLE_MOUSE !== void 0)        return n.CLAUDE_CODE_DISABLE_MOUSE ? "off" : "full";
  if (n.CLAUDE_CODE_DISABLE_MOUSE_CLICKS !== void 0) return n.CLAUDE_CODE_DISABLE_MOUSE_CLICKS ? "scroll" : "full";
  return "full";
}

and the corresponding mode-set helpers:

cn = b(MOUSE_NORMAL) + b(MOUSE_BUTTON) + b(MOUSE_ANY) + b(MOUSE_SGR)   // enable all
fn = b(MOUSE_NORMAL) + b(MOUSE_SGR)                                     // reduced set
Mo = I(MOUSE_SGR) + I(MOUSE_ANY) + I(MOUSE_BUTTON) + I(MOUSE_NORMAL)   // disable all

Wheel events are delivered over the same mouse-reporting mode as button presses, so keeping the wheel working in scroll mode requires leaving DECSET 1000 enabled — and mode 1000 reports press/release for every button, the right one included. The button event therefore still arrives and is still acted on.

Suggested fix

In scroll mode, keep mouse reporting enabled for wheel events but ignore button press/release for buttons 0–2, acting only on wheel buttons (64/65). That would make the variable do what its name says and give users both behaviours.

Why this matters beyond the variable

In a GUI host that renders its own context menu over the terminal (in my case the Daintree IDE, but the same applies to any Electron/xterm.js host), a right-click does two things at once: the host opens its context menu, and Claude Code pastes. It reads as a bug even though each half behaves as designed, and today the only escape is to give up wheel scrolling entirely.

Environment

• Claude Code version: 2.1.246
• OS: Windows 11 Pro (10.0.26200), x64
• Terminal: xterm.js inside an Electron host (Daintree 0.33.0); also reproduced conceptually against the mechanism described in #66056
• TUI mode: fullscreen (alternate screen buffer)

Note on the alternate screen buffer: because Claude Code runs in the alt screen, disabling mouse reporting does not hand wheel scrolling back to the terminal — there is no scrollback there for the host to scroll. So CLAUDE_CODE_DISABLE_MOUSE=1 genuinely loses wheel scroll rather than delegating it. PgUp/PgDn continues to work, which is a usable fallback but not an obvious one.

Related

• #66056 — same underlying mechanism (mouse reporting capturing right-click), but the inverse symptom: there the terminal's own context menu is suppressed. This report is specifically that the documented opt-out does not work.
• #72173 — CLAUDE_CODE_DISABLE_MOUSE_CLICKS and text selection (closed).
• #81472 — copy/paste meta tracking issue.