AskUserQuestion dialog auto-submits on mouse click without confirmation

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/71468
2. https://github.com/anthropics/claude-code/issues/71539
3. https://github.com/anthropics/claude-code/issues/45374

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

Yes since claude fullscreen TUI captures mouse clicks I accept or decline requests on accident ALL THE TIME.
I just want to focus the terminal -> accept/denied
just click between panes -> accept/denied

its very annoying.
I wish i could switch off mouse capture for thsoe descision or maybe it should need a double click, or something. its not awesome right now anyway.

BTW this has nothing todo with jetbrains. Wezterm terminal has the same issue, iterm2 as well

Having CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 in your env when running claude seems to disable this successfully (but leaves mouse scrolling functionality intact).

Adding to @Seldaek's tip — you can also set this in ~/.claude/settings.json instead of the shell env:

{
  "env": {
    "CLAUDE_CODE_DISABLE_MOUSE_CLICKS": "true"
  }
}

Nice thing is it stays scoped to Claude Code (doesn't touch the rest of your shell env), it's version-controllable, and the same file works on both macOS and Linux.

I'm hitting this issue - I've accidently stopped several important actions, and allowed several I didn't want to have happen. This is a SERIOUS issue - having to disable mouse clicks is a work around, but that stops people who like to use the click to PICK the option, rather than using arrow keys. Clicking on an option should NOT submit.

@drememynd don't get me wrong I was also frustrated by the accidental clicks I did - which is why I turned it off now. But at the same time I can see that if any other GUI application would ask me "are you sure?" on every click I do, it would drive me absolutely nuts. The problem I think is that we're simply not used to the fact that clicking anywhere on the terminal can have consequences, so we click it randomly to focus. I would never click randomly on my email client tho for the fear of hitting a button.

If anything, what could improve the situation is having a clearly visually delimited zone where the clickable options are when there is a multi-choice callout. That would highlight the fact that this is a zone you don't want to click in. Right now it is all just a bunch of text except some of the text is a minefield. Also great would be to disallow clicks if the click was also focusing the terminal app, but I somehow doubt this is a distinction you can make.

@Seldaek I was considering, after I wrote my comment, requiring either two clicks or a double click.

A) Single click highlights the option, then if you click on it again, it's submitted. Doesn't stop single clicks submitting, necessarily, though, if there is a default highlighted option.

B) Requiring a double click to submit, which wouldn't require hitting enter, and bypasses the "i accidently hit it with my mouse" issue.

Having a highly visible zone where the question was might help, although honestly I'm not sure I'd even notice it in my workflow. I'm usually looking somewhere else and clicking on the terminal based on peripheral vision, before turning my attention to it fully.

One other thing, with mouse turned off, I can't copy from my terminal, because I can't highlight a section. Oddly, right mouse click on the typing area still pastes. :-S

That bug is crazy annoying. When will this be fixed?
On macOS it happens, too.

Investigated on 2.1.233 (Linux). This is intended behavior rather than a bug: since v2.1.187, Claude Code's fullscreen rendering handles mouse clicks, and a single click on a select-menu option chooses it — the same as pressing that option's number key or Enter. This applies to permission prompts, /model, /config, and multiple-choice questions like the one you hit. It's documented here: https://code.claude.com/docs/en/fullscreen ("Use the mouse").

If you'd rather clicks never activate anything:

• CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 (v2.1.195+) ignores clicks/drag/hover but keeps mouse-wheel scrolling.
• CLAUDE_CODE_DISABLE_MOUSE=1 releases the mouse entirely (native terminal selection returns; PgUp/PgDn still scroll).

That said, we agree the expectation is reasonable — a click meant to focus the terminal window (JetBrains forwards that click to the app) shouldn't irreversibly answer a question. We're treating this as a usability suggestion: options under consideration include click-to-focus-then-confirm for consequential dialogs, or ignoring the click that focuses the window. Leaving this open to track that improvement.

🤖 Generated with Claude Code

click-to-focus-then-confirm for consequential dialogs, or ignoring the click that focuses the window.

Both sounds great, and both also sound kinda the same, but whatever, would be a great useability improvement.

Generally excluding mouse just for permission requests would be good as well. I like to be able to click to expand, click to open links, etc.

Adding a data point from a heavy mouse user: neither documented workaround is actually usable if you rely on both scroll and copy.

• CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 keeps scroll but kills text selection/highlight-to-copy.
• CLAUDE_CODE_DISABLE_MOUSE=1 restores copy but kills in-app mouse-wheel scroll (PgUp/PgDn isn't an equivalent — it's much slower for skimming long output).

I use scrolling and copy-paste constantly, so both of these cost me more than the original problem. In the end the accidental clicks are the lesser of three evils, which means there's effectively no good setting today... You just pick which thing to break.

That's why I'd strongly support the click-to-focus-then-confirm direction mentioned above; or the simplest version: require a double-click to activate a menu option. A single click focuses/selects, a double-click submits. That kills the "I clicked to focus the window and accidentally answered" problem without taking away scroll or copy, which the env-var switches both do. Please don't make the fix "turn the mouse off" that's throwing out two features to patch one.

Thanks!

Two things:

@irisvdz83 has a brilliant idea making it a double click. I think that's the best suggestion so far.

I'd like whomever is reading this to know: This is such a problem for me that I use Claude less and other agents more, because the workarounds are, as @irisvdz83 said, give us a choice between 3 unacceptable options. If this gets fixed, I'll stop avoiding Claude, because it's still my favorite agent, if it weren't for this.

I still am having trouble imagining how anyone who knows anything about UX thought making this a single click without confirmation was a good idea, and that this was actually deliberate and not a bug, and it got through some design discussion and everyone in the room thought it was a good idea. But I get it, not every decision made about how software works is a good one, despite our best efforts.