[BUG]
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?
제목: 권한 승인 프롬프트가 무관한 키 입력/마우스 클릭에도 "승인"으로 처리됨 (백그라운드 작업 중 포커스 탈취로 인한 오승인)
환경
Claude Code 실행 환경: (터미널 종류 - 예: iTerm2 / Windows Terminal / VS Code 통합 터미널 등)
OS: (예: macOS / Windows / Linux)
Claude Code 버전: claude --version 결과
증상
파일 수정 또는 명령어 실행 전 뜨는 권한 승인 프롬프트(1. Yes / 2. Yes, don't ask again / 3. No)에서:
방향키로 2번을 선택하거나 "2"를 타이핑한 적이 없는데도 "다시 묻지 않음"이 적용되어 이후 자동 승인됨
승인창과 무관한 위치를 마우스로 클릭만 해도 진행됨
1, 2, 3이 아닌 전혀 다른 키를 입력해도 프롬프트가 승인된 것으로 처리되어 넘어감
핵심 문제 상황 (재현 조건)
해당 터미널에서 Claude Code가 작업 중일 때, 사용자는 다른 터미널이나 다른 파일에서 별도 작업을 하고 있었고 당연히 그쪽에 타이핑을 하고 있었음. 그런데 그 순간 Claude Code 터미널이 승인 프롬프트를 띄우면서 갑자기 포커스를 가져갔고, 그 타이밍에 다른 곳에 입력 중이던 키 입력이 그대로 프롬프트에 꽂혀버려 1, 2, 3 중 아무것도 실제로 선택한 적이 없는데도 임의의 항목이 "선택된 것"으로 처리되어 진행돼버림. 즉 사용자는 아무 의사결정도 하지 않았는데 시스템이 멋대로 수용하고 진행한 셈이 되어, 사용자 경험이 매우 나빴음.
기대 동작
승인 프롬프트는 해당 창이 실제로 포커스를 가지고 있는 상태에서, 정확히 1/2/3에 대응하는 명시적인 키 입력 또는 클릭에만 반응해야 함. 프롬프트 표시 직전/도중에 다른 곳으로 전달되고 있던 입력이 버퍼링되어 프롬프트에 잘못 소비되는 일이 없어야 함
영향
사용자가 전혀 의도하지 않은 시점에 파일 수정/명령 실행이 승인 없이 진행됨. 특히 "다시 묻지 않음"이 잘못 적용되면 이후 세션에서도 계속 자동 승인되어 되돌리기 어려운 신뢰성 문제로 이어짐
재현 절차
(여기에 순서대로: 어떤 다른 작업을 하고 있었는지, 그 사이 Claude Code 터미널에서 무슨 프롬프트가 떴는지, 어떤 결과로 이어졌는지)
Claude Code's permission approval prompt (1. Yes / 2. Yes, don't ask again / 3. No) gets falsely resolved by input that has nothing to do with the prompt itself. Specifically:
"Don't ask again" gets applied even though I never selected option 2 via arrow keys or by typing "2"
Clicking anywhere in the terminal, even in a location unrelated to the prompt options, causes the prompt to proceed as if approved
Typing keys other than 1, 2, or 3 also causes the prompt to be treated as approved and the tool call proceeds
This happens specifically when I was working in a different terminal/window/file at the same time Claude Code was running a task. The Claude Code terminal's prompt appeared and stole focus mid-typing, and whatever keystrokes I was sending elsewhere got consumed by the prompt instead — as if I had answered it, when I never made any actual choice among 1/2/3.
What Should Happen?
The approval prompt should only be resolved by an explicit, unambiguous action: pressing 1, 2, or 3 (or clicking directly on one of those options) while that terminal window genuinely has keyboard focus. Any keystrokes that were in transit to a different window at the moment the prompt appeared should be discarded, not silently fed into and consumed by the prompt. A prompt with an irreversible effect (like "don't ask again," which persists auto-approval for the rest of the session/project) should never be triggered by ambiguous or unintended input.
Error Messages/Logs
Steps to Reproduce
Start a Claude Code session in a terminal and give it a task that will require file-edit or command-execution approval (e.g., "refactor this function").
While Claude Code is generating/working, switch focus to a different terminal window, editor, or file, and begin typing normally there (as part of unrelated work).
At some point during that typing, Claude Code reaches a point where it needs approval and displays the 1/2/3 permission prompt, stealing terminal focus.
Continue as normal — do not intentionally press 1, 2, 3, or click on the prompt.
Observe that the prompt resolves anyway: the action proceeds as if approved, and in some cases "don't ask again" is applied, even though no explicit 1/2/3 input or click on the prompt was ever made.
Note: Reproduction may depend on terminal emulator and OS (e.g. iTerm2, Windows Terminal, VS Code integrated terminal — please fill in your specific setup and Claude Code version, since that will help maintainers narrow down the exact input-handling path involved).
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.201
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
IntelliJ IDEA terminal
Additional Information
_No response_