Typing next message activates approval shortcuts

What version of Codex is running?

codex-cli 0.65.0

What subscription do you have?

Business

Which model were you using?

gpt-5.1-codex-max

What platform is your computer?

Linux 6.17.7-200.fc42.x86_64 x86_64 unknown

What issue are you seeing?

When typing the next command while the agent is working, and an approval request pops up, it will be instantly approved (potentially forever) if the text contained letters "y" or "a".

› 1. Yes, proceed (y)
2. Yes, and don't ask again for this command (a)
3. No, and tell Codex what to do differently (esc)

What steps can reproduce the bug?

As in description

What is the expected behavior?

Maybe have approval shortcuts on harder-to-accidentally-trigger combinations or disable them completely.

Additional information

No response

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.

@nielsole

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:

Codex CLI is still processing a turn.
I begin typing the next message in the composer/REPL.
A permission or approval prompt appears while I am typing.
Characters already being typed are interpreted as approval-menu shortcuts, such as y, a, or possibly n.
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.

Delay approval prompts while typing (#19513)

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.

Delay approval prompts while typing (openai#19513)

Navigation Menu

Repository navigation

Typing next message activates approval shortcuts #7744

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Typing next message activates approval shortcuts #7744

Description

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

tosh commented on Feb 1, 2026

MNeMoNiCuZ commented on Feb 5, 2026

nielsole commented on Apr 17, 2026

2 remaining items

themreza commented on Apr 23, 2026

LevSky22 commented on Apr 25, 2026

Game4Move78 commented on Apr 26, 2026

etraut-openai commented on Apr 27, 2026

nielsole commented on May 5, 2026

nielsole commented on May 6, 2026

MNeMoNiCuZ commented on May 6, 2026

nielsole commented on May 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions