[Bug] Terminal focus-in event consumed as prompt denial in permission dialog

[dwalend]

Bug Description
On the focus bug — yes, that's a Claude Code (Anthropic) bug, not your project or config. What's happening: when the terminal regains focus, it emits an event
(a focus-in escape sequence or the mouse-click itself) that the TUI's permission-prompt input handler consumes as an answer — and the default it lands on is
"deny." Clicking to refocus should never count as answering a prompt.

Environment Info

• Platform: darwin
• Terminal: intellij
• Version: 2.1.195
• Feedback ID: af2c6e41-7804-454f-853d-d88c47570698

Errors

[]

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Mouse click to refocus terminal triggers permission prompt unintentionally #71539
2. [BUG] Why when I click in your window when you are waiting for an answer seem to initiate as if I have made a selection. This was not happening before. #70894
3. [Windows] Buffered keypress auto-approves plan/permission prompts after window switch or login #68526

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

[umputun]

confirming a related variant on macOS with a libghostty-based terminal (not just the intellij terminal in the report), Claude Code 2.1.195.

repro: while a selection/permission prompt is open, switch to another app and switch back. After refocus the prompt stops responding to key presses, arrow navigation is dead and Enter does nothing. It does not auto-answer in my case, it just goes unresponsive (a different manifestation from the deny in the report, but the same focus-event trigger). The normal REPL prompt is unaffected, so this is specific to the dialog input handler.

the trigger is the focus-in escape (ESC[I, DEC mode 1004), not the mouse click. It happens when you return via cmd-tab with no click at all, and on a terminal that is already macOS focus-first (the refocus click only focuses the window, never reaches the pty). So it is the focus report itself that wedges the dialog input.

I instrumented the terminal side to rule it out: across many app-switch cycles it emits perfectly paired focus-in/focus-out (ESC[I / ESC[O), with no dropped or stray bytes. So the terminal is correct, the dialog handler mishandles the focus report. Treating ESC[I/ESC[O as focus state only (never feeding them into the prompt key handling) should cover both the deny and the freeze.

related: #72273 looks like the mouse-click sibling of the same root cause.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.