Typing next message activates approval shortcuts

I'm also running into this regularly

I think "No" is also triggered by "n" (?)

I like the proposal of making the shortcuts less easy to type (e.g. keyboard combination)

another way could be identifying that the user is typing a prompt (e.g. prompt field non-empty)

that doesn't fully solve the problem though because the user might also want to start typing a prompt at any time even if prompt field is currently empty.

I appreciate the hotkeys, always a fan of that, but when it interrupts another action, this is not good.
It's like a pop-up stealing focus while you are writing something. It's not a good experience at all!

If no better way is found, when typing, shortcuts should only work after a debounce timer (500ms??) and the terminal bell should ring for every character you type while debounce is active. This should greatly reduce risk without changing the flow too much.

EDIT More detailed description of the desired behavior for easier consumption by an agent:

When the overlay opens (or advances to the next queued request), start
a 500 ms sliding arming window during which:
- every key event is swallowed without affecting selection,
- the terminal bell rings for each suppressed Press/Repeat key,
- the timer resets on each suppressed keystroke (so continuous typing
  keeps the overlay disarmed), and
- the selected row is rendered without the cyan+bold highlight so the
  UI visibly communicates "not armed yet".

After 500 ms of no input, shortcuts and Enter work normally and the
selected row gets the usual highlight. Ctrl-C continues to cancel
immediately because it flows through a separate trait method.

If no better way is found, when typing, shortcuts should only work after a debounce timer (500ms??) and the terminal bell should ring for every character you type while debounce is active. This should greatly reduce risk without changing the flow too much.

That's a decent stopgap. I honestly don't know what the perfect terminal-only UI would look like but it seems a C- prefix for confirms if there's been text entry in the last X sec would also be easy to implement and far preferable for me - bad if keystrokes are stolen and I have to stop touch-typing.

Claude Code behaves similarly to what @nielsole suggested. If there's an approval dialog coming up and the user is typing it, it delays showing the dialog until the user has fully stopped typing for at least one second.

Please fix this bug. It's super annoying.

I am also running into this failure mode.

This appears to be the same class of bug as #5080, which was closed on 2026-01-10 with the comment "Closing old issue." The behavior still matters because it is not just a visual focus issue: the approval prompt can consume keystrokes that were intended for the next chat message.

Observed behavior:

1. Codex CLI is still processing a turn.
2. I begin typing the next message in the composer/REPL.
3. A permission or approval prompt appears while I am typing.
4. Characters already being typed are interpreted as approval-menu shortcuts, such as y, a, or possibly n.
5. This can approve, permanently approve for a command, or deny a request before I have a chance to read the prompt.

Expected behavior:

The approval prompt should require intentional input after it appears. Keystrokes that were already part of typing a chat message should not activate approval actions. A short arming delay/debounce, requiring a modifier shortcut for approvals, or delaying the prompt until typing has been idle would all be safer than immediately accepting single-letter shortcuts.

Impact:

This is a permission/safety issue as well as a TUI issue, because the user can accidentally grant command execution or persist an approval rule without meaning to.

I hit this too. I wanted to suggest a different UX from #19513:

┌ Pending approval ─────────────────────────────────────────────────────┐
│ $ echo ok                                                             │
│ [Alt+E expand] [Alt+Y approve] [Alt+N deny]                           │
└───────────────────────────────────────────────────────────────────────┘
> Ask Codex to do anything

Proposal:

• If an approval arrives while the composer is active, show a compact pending-approval bar instead of focusing the full approval view.
• Keep keyboard input routed to the composer.
• Only enable single-key approval shortcuts after explicit expansion/focus.
• Preserve the current approval UI as the expanded state.

If this direction fits the TUI model, I’m happy to prepare a targeted PR if invited.

Thanks for the bug report. I've added a delay as suggested, so the approval overlay is deferred until 1 sec after typing stops. This will be addressed in the next release.

Thanks for fixing this! My understanding of the PR on cursory review is that this does not address the case where someone is about to start typing and the approval prompt pops up right under their fingers. This is a much smaller issue, but the same class of inadvertent user authorization nonetheless. This would be resolved if you switched to an "arming" period as proposed above.

I ran into this today. Drafted a message while the agent was working, shortly reviewed it for ~ <1s and hit enter just as the review prompt popped up, thus approving a command I had not been able to see. So this is not as unlikely as I thought yesterday

Yeah 1 seconds is not a lot of time.
Hard to say what's a foolproof solution.

A worse and less likely key-combination could be good, but also bothersome?
A longer delay could be frustrating if you are just waiting for the input.
A second confirmation (Are you sure?) would also always be frustrating.

A different duration is not gonna address the categorical issue.

As I mentioned previously, a brief arming period where the dialog is visible but doesn't accept key inputs would solve this. It would only have to be as long as the slowest reasonable human reacts, so probably somewhere > 100ms and <= 1s.