[Bug] Accidental mouse clicks on selection prompts misfire; mitigation breaks fullscreen scrollback

Bug Description

# Accidental mouse clicks on selection/permission prompts easily misfire; the only mitigation env var is undiscoverable, and combining it with fullscreen breaks scrollback ## Summary Two related problems with mouse handling in the fullscreen renderer: 1. Interactive selection prompts (tool-permission prompts, AskUserQuestion option menus, /model, /config) became mouse-clickable. A single stray click confirms/rejects an option with no deliberate confirm step, so accidental clicks easily misfire — including rejecting a tool-permission prompt. 2. The only mitigation, the env var CLAUDE_CODE_DISABLE_MOUSE=1, is hard to discover (no settings.json key, not surfaced in /config or docs), and when combined with the fullscreen renderer it makes scrollback look broken — the conversation appears truncated/"lost" even though the data is intact. ## Environment - Claude Code v2.1.193 (env var presence confirmed in the installed binary) - macOS (Darwin 25.5.0), fish shell - Fullscreen renderer (mouse capture enabled, introduced ~v2.1.187) ## Problem 1 — accidental click misfire ### Repro / observed behavior 1. A selection prompt is on screen (e.g. a tool-permission prompt). 2. A stray/accidental mouse click lands on the prompt area. 3. The click immediately selects/confirms (or rejects) an option — there is no second deliberate confirm step. In a single session this caused a tool-use permission prompt to be rejected twice by accidental clicks. ### Why it's a problem Users naturally move and click the mouse for unrelated reasons (scrolling, window focus, switching apps) while a prompt is visible. A single stray click that confirms a choice is destructive and surprising, especially for permission prompts where the click can reject or approve an action. ## Problem 2 — mitigation is undiscoverable, and breaks scrollback in fullscreen ### Mitigation today (and why it's insufficient) CLAUDE_CODE_DISABLE_MOUSE=1 does disable click capture, but: - It is an env var only — there is no settings.json key, so it is neither persistent per-project/profile nor discoverable. - It is not surfaced in /config or in the documented settings UI. - It is all-or-nothing (also disables click-to-expand, etc.). ### Additional symptom: broken scrollback with CLAUDE_CODE_DISABLE_MOUSE=1 + fullscreen The fullscreen renderer draws to the alternate screen buffer (\x1b[?1049h), which by design has no native scrollback. - With mouse capture ON, Claude Code intercepts wheel events and scrolls its own internal view, so history is reachable. - With CLAUDE_CODE_DISABLE_MOUSE=1, wheel events are handed to the terminal. The alternate screen has nothing to scroll, so the terminal surfaces stale main-buffer content instead. The result is that the live conversation appears truncated or "history lost" / mixed with old content, even though the conversation data is intact. In other words, the two supported settings (fullscreen renderer + disable mouse) combine into a confusing, degraded scrollback experience. A user who disables mouse to stop accidental clicks then loses reliable history scrolling. ## Requests 1. A single click on an option should only move focus/highlight; require a second deliberate action (Enter, or a confirm button) before confirming — avoid instant click-to-confirm, especially on permission prompts. 2. Add a discoverable, persistent setting in settings.json (e.g. "disableMouse": true or "mouse": "off") rather than env-var only, and optionally surface it in /config. 3. When mouse is disabled under the fullscreen renderer, keep wheel scrolling bound to Claude Code's own internal view (or otherwise prevent the stale main-buffer scrollback), so disabling mouse does not break history. 4. Document CLAUDE_CODE_DISABLE_MOUSE=1 (and its interaction with the fullscreen renderer) in the official docs.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.193
• Feedback ID: 93aac87b-8ee3-47e5-8f30-021a1049917d

Errors

[]