claude-code - 💡(How to fix) Fix [BUG] Permission prompt immediately steals focus while typing (regression in 2.1.139+)

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Permission prompts now immediately steal keyboard focus while the user is actively typing in the CLI input. In 2.1.138, the CLI detected active input and deferred the permission prompt -- it displayed a "waiting for permission" indicator at the bottom and only presented the interactive approve/deny dialog after the user stopped typing (with an approximately 1.5-second buffer). This deferral behavior is completely gone in 2.1.139+.

The result: if Claude triggers a permission prompt (e.g., code edit confirmation) while you're mid-keystroke composing your next message, the dialog appears instantly and captures your keystrokes. You get locked into the approve/deny prompt with no way to finish what you were typing. Characters you were in the middle of typing get swallowed or interpreted as dialog actions.

Root cause (from binary analysis):

In 2.1.138, permission prompts were rendered via setToolJSX -- React JSX injected into the existing Ink component tree. Because the prompt lived inside the same React render tree as the text input, Ink's focus management naturally deferred focus to the active text input. The permission prompt rendered passively until focus shifted away from the input.

In 2.1.139+, a new requestDialog abstraction was introduced (the IdK() dialog coordinator). This is an imperative pub/sub event emitter:

1. Tool needs permission -> calls coordinator.request({kind, payload})
2. Request is emitted synchronously via coordinator.emit(...) with no input-activity check
3. Dialog subscriber renders the prompt component with Focus: true (autoFocus), which immediately steals keyboard focus from the text input

The old setToolJSX path was a React state update that integrated with Ink's focus system. The new requestDialog is an imperative emitter that bypasses it entirely. There is no input detection, no debounce, and no queuing in the new code path.

The requestDialog abstraction does not exist at all in 2.1.138's bundle (confirmed via binary string analysis -- zero occurrences of requestDialog in the .138 binary, 23 occurrences in .145). The IdK() factory and its request()/emit() pattern are entirely new.

What Should Happen?

The behavior from 2.1.138 should be restored: when the user is actively typing, permission prompts should be deferred and show a passive "waiting for permission" indicator. The interactive dialog should only appear after:

• The user stops typing for a reasonable buffer period (~1-1.5s), OR
• The user explicitly submits their message

The requestDialog coordinator's request() method should check input activity state before emitting, or the dialog rendering component should debounce focus acquisition when the text input has active content.

Error Messages/Logs

N/A -- this is a UX regression, not a crash.

Steps to Reproduce

1. Start a Claude Code CLI session (terminal, not IDE)
2. Give Claude a task that will trigger a permission prompt (e.g., a code edit)
3. While Claude is working, start typing your next message in the input
4. When the permission prompt appears, observe that it immediately steals focus mid-keystroke
5. Your typed characters are lost or interpreted as dialog actions

Compare with 2.1.138: Same steps, but the permission prompt waits at the bottom ("waiting for permission") until you finish typing.

Claude Model

Not model-specific

Is this a regression?

Yes

Last Working Version

2.1.138

Claude Code Version

2.1.145 (confirmed broken); likely broken since 2.1.139 when requestDialog was introduced

Platform

Anthropic Console (Pro)

Operating System

macOS

Terminal/Shell

iTerm2 / tmux / zsh

Additional Information

Related but distinct issues (none identify this specific regression):

• #10971 -- Feature request from 2025 predating the working behavior
• #23643 / #33988 -- IDE plugin variants (JetBrains / VS Code), not CLI
• #28722 -- AskUserQuestion focus steal, not permission prompt

The 2.1.141 changelog entry "Fixed pressing Enter while a permission/dialog prompt is open also submitting text in the input box" confirms active work on the dialog input system in this version range, and is likely when the requestDialog refactor landed.