What
Confirmation dialogs and selection lists now refuse keys, including Enter, Escape, digits and typed characters, that land within a short window anchored to the moment the dialog renders. A stray Enter typed a beat before a permission prompt appears no longer answers it; the dialog remounts instead of acting on the key. This is unconditional in this build, with no flag, setting or environment variable around it.
Details
- The default refusal window is 150ms, measured from the dialog's own anchor time rather than from when the key arrives.
- The yes/no confirm prompt and the interactive select lists take three new props,
refuseInputto turn the guard on,windowAnchorMsto set the moment the window starts from, andwindowMsto set its length, threaded through at each call site. - A new hook pairs a general refusal check with a typed-character check, and returns both whether the key was refused and whether a typed character was swallowed, so callers can react.
- Digit keypresses in select lists return early when
refuseInputreports a refusal, and the confirm and cancel handlers stop if the select's change or confirm guard returns false. - The "Claude proposes a goal" dialog mounts its numeric select with all three props and hidden option numbers, remounting between a settled and a held state.
- Also applied to the PowerShell permission dialog, the Chrome extension prompt, the macOS Computer Use permission dialog and the iTerm2 install dialog, among others.
windowAnchorMsdoes not exist in the previous build, so the guard is new rather than a retuning of something already shipped.
Evidence
refuseCharacter, refuseInput, refusedWithin
Strings lifted out of the shipped bundle, so the claim above can be checked against them.