Granular control over mouse click behavior in interactive menus (AskUserQuestion, select prompts)
Feature request
Since v2.1.181, clicking an option in select menus (permission prompts, /model, /config, AskUserQuestion dialogs, etc.) in fullscreen mode immediately selects/confirms it. This is a nice addition for some workflows, but there's no way to opt out of just this behavior without losing other mouse functionality.
The only existing controls are all-or-nothing:
CLAUDE_CODE_DISABLE_MOUSE— disables all mouse tracking (also disables scroll, hover, everything).CLAUDE_CODE_DISABLE_MOUSE_CLICKS— disables click/drag/hover entirely, which also breaks clicking links and text-drag-selection inside fullscreen rendering.
The problem
I want to keep:
- Clicking links to open them
- Mouse drag text selection
But disable:
- Click-to-select on interactive menu options (permission prompts,
/model,/config,AskUserQuestion), since accidental clicks near an option now confirm/select it unintentionally.
There's currently no combination of settings/env vars that achieves this — it's either "clicks do everything" or "clicks do nothing."
Suggested solution
A more granular env var / setting, e.g. CLAUDE_CODE_DISABLE_MENU_CLICK_SELECT=1, that disables only the click-to-select behavior on interactive select menus while leaving link-opening and text selection/drag untouched.
Environment
- Claude Code CLI, terminal usage, fullscreen rendering mode
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Strong +1 with a concrete incident supporting this. Claude Code 2.1.205, macOS, VS Code integrated terminal: I clicked into the terminal window purely to restore OS focus, the click landed on an active Bash permission prompt, and it registered as a rejection — interrupting a long agent turn mid-task (details in anthropics/claude-code#77827).
The all-or-nothing controls don't help here: I want to keep wheel scroll and drag-select, and lose only single-click-confirms-an-option. Either of these would solve it:
clickBehavior: highlightsetting — click moves the selection highlight, Enter confirms (mirrors keyboard flow, keeps mouse useful).Option 2 alone would eliminate the most common accidental path (returning to the terminal from another app while a prompt happens to be on screen).
Yeah, this is a crazy UX to have clicks to focus the window select options in the terminal.
By default, clicks in terminal CLIs should require some active user keyboard interaction, like holding down <kbd>cmd</kbd> or something.
And also a security risk, as mentioned over in another similar issue:
Definitely needs a disable flag.
Adding another scenario backing up the need for this change:
I am working on creating a subagent and I was running through tests with the agent. I clicked to my terminal window to restore OS focus do decline a command and it accepted my click as approval of the command, which happened to be a destructive git command on a worktree that the agent did not own. This is of course during development work to isolate for commands like this, but there's a greater risk that accidentally clicking a window being taken as an approval cold potentially allow destructive commands to be run. This behavior really should be opt in only.
Similar to @brianespinosa I click the shell to restore focus, but the region for 'yes' or 'no' takes up the entire line, which I have accidentally clicked on more than a few times. Either an option to disable mouse confirmation, or to reduce the confirmation area to the characters it occupies (i.e. 3 characters for 'Yes') instead of the entire line would be ideal.