Permission dialog: number key selection unreliable (~40% failure rate) while Enter works consistently

Summary

When a permission dialog appears, pressing a number key (1/2/3) to select an option fails roughly 40% of the time. Enter key works reliably in the same situation.

Failure modes

Two distinct behaviors observed:

Mode 1 — Key ignored: First keypress has no effect; a second press is required to select the option.

Mode 2 — Key routed to text input: The number character is typed into the bottom prompt input field (at cursor position) instead of being handled by the dialog.

Expected behavior

Number key pressed while permission dialog is visible → selects the corresponding option immediately and reliably.

Actual behavior

~40% of the time, either the keypress is lost or it is received by the underlying text input field rather than the dialog.

Why Enter works but number keys don't

Enter appears to have a global intercept that checks for an active dialog before routing the event. Number keys (1/2/3) are bound specifically to the dialog component and depend on keyboard focus having been transferred — which does not always happen in time.

This suggests two related root causes:

1. Race condition: focus transfer to the dialog lags behind visual render; keypresses during this window are lost or mis-routed
2. Focus not transferred at all: the text input retains focus, so number keys go there instead of the dialog

Reproduction

• No specific trigger; occurs randomly across normal usage
• More likely when responding quickly after the dialog appears
• Observed consistently across multiple sessions

Environment

• macOS 26.2 (Apple M2)
• Claude Code (CLI)