[Feature Request] Add option to disable clickable Yes/No prompts in terminal

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/70539

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The extension of the click zone into previously blank space seems especially dangerous - I've accidentally chosen responses on a dozen prompts today when just trying to focus a window. Here's a visual example, where I tend to think clicking in the nice blank space is safe, and it triggers the acceptance of this command.

<img width="1115" height="625" alt="Image" src="https://github.com/user-attachments/assets/59801525-cafb-431e-a9e1-148cabadc585" />

This is hands down one of the worst features to be added with no option to turn it off. Every day since it's been added I have accidentally answered questions and had to burn tokens to undo and get back to the question so I could actually read and answer it properly. Please remove the feature or at least provide a way to turn it off without bricking the terminal (setting CLAUDE_CODE_DISABLE_MOUSE prevents the mouse clicks but also makes it so you can't scroll back using mouse wheel).

I think it could be useful, but having the entire line being the hotspot for clicking is the problem here. I would be happy if the click had to be over the actual characters. Fortunately, most of the time I accidentally click on "No" and then have to tell it to carry on.

The accidental-approve case deserves to be split out from the accidental-cancel case, because they're not the same severity. A misclicked "No" is annoying and recoverable; a misclicked "Yes" on rm -rf, a force-push, a git reset --hard, or a prod command can be irreversible. Several comments here mention accidentally approving — that's the one that can actually cost you work, not just tokens.
While the configurable on/off is the right fix, here's what you can do today, in rough order of leverage:

1. Put a deterministic guard at the tool boundary, so a misclick can't execute a destructive op. A PreToolUse hook that matches Bash and refuses the dangerous verbs (rm -rf, git reset --hard, git clean -fd, force-push, terraform destroy, prod commands) returns a non-zero/deny regardless of how the permission prompt was answered. This decouples "I accidentally clicked Yes" from "destruction happened" — the prompt approval no longer gets the last word on the irreversible cases. It's the highest-leverage mitigation because it targets the actual harm (irreversible execution), not the UI. Reads and normal commands still pass, so it's low-friction. This is worth doing even after the UI is fixed.
2. Disable mouse reporting in your terminal so clicks aren't captured as input at all. In Windows Terminal this is the mouse/selection behavior in settings; many terminals also have a mouse-mode toggle. If the clicks never reach the prompt, the blank-space hotspot problem disappears for keyboard-only workflows.
3. Check /config and your settings.json for a prompt/interaction toggle on your version (2.1.187) before assuming it's absent — the surface has been changing fast, and if it genuinely isn't there yet, that absence is exactly the signal this FR captures.

On the FR itself: the "entire line is the hotspot" point from @antonyscott-codurance is the cleanest narrow fix — restricting the click target to the actual Yes/No characters (not the trailing blank space) would kill most of the accidental-approval risk without removing the feature for people who like it. That's a smaller ask than a full on/off and might land faster.
(I'm going on the reports here; the tool-boundary guard in #1 is general and deterministic, but you'll want to scope the refused-command list to your own workflow so it doesn't block something you actually run.)

Agreed, dreadful user experience, making it easy to accidentally select the wrong option, which could lead to very bad outcomes. I could see the benefit of mouse-clicking these options if there was clear visual feedback that your mouse was hovering (e.g. a change to background color), but especially the fact that you can select by clicking into empty space.

Running v2.1.195 on Windows Terminal. The new CLAUDE_CODE_DISABLE_MOUSE_CLICKS env var partially addresses this, but it also disables clicking to expand/collapse tool output (e.g. "Ran 2 shell commands"), which is useful UX.

My specific pain point: clicking the terminal window to ensure focus before using arrow keys accidentally accepts or denies permission prompts, requiring me to re-prompt Claude to retry the action. A granular option to disable clicks only on interactive prompt elements (yes/no dialogs, menu selections) while preserving clicks on collapsible output would solve this cleanly.

Just adding my voice to the cacophony of voices. This one truly hurts. I definitely appreciate them trying but it is a failed implementation - if it looked more like a clickable region like a button I'd have no issue.

Agreed - I keep clicking responses by accident when trying to click to re-focus into the terminal. Even worse I can't see what I accidentally did or didn't approve.

Anthropic trying to implement a GUI in a CLI. Just stop.

THIS ! this is horribly annoying. it did not at first. This is newly added feature right ?
Every time i try go gain focus on the terminal i keep clicking something.
Not only that but if i'm typing in prompt queue, it also accepts keypresses (me typing words) as a "yes"...
Who make this !? We need to turn this stupid click support OFF

This is a particularly painful feature.

Very sad addition.

I see this also as a potential security risk. Accidentally approving some command in the _"Yes, and don't ask again"_ is not ideal when I now have to hunt for what was approved to hope it doesn't come back to bite me in the future.

Please consider reverting this, or provide a configuration option to disable/enable it.

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 agreed that it's a security risk, as @mkobit mentioned above

Definitely needs a disable flag.

most of us users would agree, either offer an option to disable clicks in to the approval dialogue or an option that disables this but still allows mouse for scrolling and text selection.

I am never using this feature on purpose.
It would be great to be able to disable it.

If I had a dollar for every time this resulted in a bad action taking place or needing to dive into the settings file to understand what I just auto-approved, I'd have several dollars and a few less gray hairs.

for the love of the users of claude PLEASE DISABLE THIS BY DEFAULT

This is configurable as of v2.1.195: set CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 and clicks are ignored (permission prompts, menus, tool output) while mouse-wheel scrolling keeps working. If you'd rather turn off all mouse handling, CLAUDE_CODE_DISABLE_MOUSE=1 does that.

Docs: https://code.claude.com/docs/en/env-vars
Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Closing as shipped; reopen if you still see accidental clicks after updating.

🤖 Generated with Claude Code

This is configurable as of v2.1.195: set CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 and clicks are ignored (permission prompts, menus, tool output) while mouse-wheel scrolling keeps working.

@bcherny have you tried using CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 yourself? This option also unfortunately disables clicks on links and selection. This option is unusable.

What do you think about defaulting to requiring <kbd>cmd/ctrl</kbd> when clicking on anything?

I think this would be much closer to expected native terminal UX.