[BUG] Mouse click to refocus terminal triggers permission prompt unintentionally
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
When a permission prompt is displayed (Yes / Yes all / No) in the new fullscreen
TUI mode, clicking with the mouse to refocus the terminal window inadvertently
triggers one of the choices.
The scenario: another window is partially overlapping the terminal. The terminal
is still visible on the side or edge. Clicking the visible part of the terminal
to bring it back to focus lands on (or near) one of the permission options and
triggers it — without the user seeing or intending the selection.
The user's intent is only to restore focus, not to make a permission choice.
This can silently grant or deny a tool use the user never consciously confirmed.
Expected: the first click on an unfocused terminal should only restore focus,
not trigger any interactive element inside the TUI.
Suggested fix: ignore mouse input on the first click that restores focus to the
terminal window, or require keyboard confirmation for permission prompts.
Related issue (similar but distinct): #70178 — choices become unresponsive after
refocus (macOS). This bug is the opposite: the click triggers a choice
unintentionally on refocus (Linux, Warp terminal).
What Should Happen?
The first click on an unfocused terminal window should only restore focus,
not trigger any interactive element inside the TUI.
Error Messages/Logs
No errorsSteps to Reproduce
- Open Claude Code in fullscreen TUI mode.
- Wait for a permission prompt to appear (Yes / Yes all / No).
- Switch to another window so it partially overlaps the terminal.
- The terminal (and the prompt) is still partially visible on the side or edge.
- Click on the visible part of the terminal to bring it back to focus.
- Observe that the click inadvertently triggers one of the permission options.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.191 (Claude Code)
Platform
Anthropic API
Operating System
Other Linux
Terminal/Shell
Warp
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
12 Comments
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
I'm on macOS Tahoe, iTerm2, same problem. I was about to open this same issue as a feature request for a toggle on clicking permissions prompts. I switch between screens and terminal windows constantly and need to refocus the right terminal window, and hit the wrong prompt (or don't get to read the prompt I just accepted or rejected) since this was introduced.
To make it worse, when I accidentally do this (third time today) I have no idea which option I ended up clicking on.
Loving the TUI (particularly copy-paste), but really don't like this very dangerous behaviour. Seems if I want to disable this behaviour I would have to either not use TUI, or configure my terminal not to report mouse events (Gnome Terminal doesn't support that)
I'm having the same experience. when I click on the window (to gain focus) then it is entirely unclear which option was just selected. I really only need to click in the general area of the option list.
I just flat out don't want clicks to be registered as selecting an option in terminal based programs even if I click directly on yes/no. I don't use any other terminal based programs where clicking is the norm for interacting with the program. This seems like an anti pattern and should be removed or at least be able to be disabled.
Having CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 in your env when running claude seems to disable this successfully (but leaves mouse scrolling functionality intact).
Thanks for this. It's ok to wait a good solution.
But I actually like mouse clicks can be use to expand/collapse content. That seems like a useful feature.
It's single clicks that perform destructive actions (and the UI then hiding both the original security prompt and the option chosen(!)) that I feel are the real bug here.
Permission prompts need a focus activation epoch. A pointer event that began while the terminal was unfocused should only activate the window and must not be eligible to choose an option. The first actionable click should require a complete down/up sequence after focus is restored and after the prompt is visible. Please test overlapping windows, focus changes between mouse-down and mouse-up, trackpad taps, and terminal multiplexers. High-impact approvals could additionally require keyboard confirmation.
Also an issue on Windows 11 Command Prompt CLI.
Also affects the .vscode integrated terminal. My agent invented various settings to circumvent this issue but so far only the CLAUDE_CODE_DISABLE_MOUSE_CLICKS is working. However, it is less than ideal because it also means I cannot click on links or use the mouse to select text.
The suggestion to click in an empty space that's not near an option does not work, because my terminal is wide, I click in the blank space that's several inches from any text, but somehow the TUI considers that click to have been on one of the choices.
They got token usage goals to hit, they aint gone fix this.