### What variant of Codex are you using? CLI ### What feature would you like to see? Currently, when Codex asks for permissions to use a tool, and offers the option to always approve, it always presents letters: * option 1 can be selected with y * 2 can be selected with p However, also number presses are enough to trigger the corresponding option. That's why I'd be happy if we could remove the letters again. Problem is, when writing a message to enqueue, you already need to be careful not to

Disable letter keys in tool permission asks to prevent conflicts with message enqueue

Open 💬 2 comments Opened Jul 3, 2026 by fcnjd

What variant of Codex are you using?

CLI

What feature would you like to see?

Currently, when Codex asks for permissions to use a tool, and offers the option to always approve, it always presents letters:

option 1 can be selected with y
2 can be selected with p

However, also number presses are enough to trigger the corresponding option. That's why I'd be happy if we could remove the letters again. Problem is, when writing a message to enqueue, you already need to be careful not to contain y or p in them, as it could be that right in this moment a tool use popup is appearing which you might not want to accept right away.

Additional information

I'd be happy to do that myself if I get an invite.

View original on GitHub ↗

2 Comments

rpelevin · 1 month ago

One safety invariant I would preserve here is that a permission prompt should only consume an approval key from an input scope explicitly bound to that prompt.

If the user is typing an enqueued message, those bytes should not be eligible to approve a tool call. I would test this as:

prompt visible plus message composer has buffered text containing y or p: no approval;
approval keys only accepted after prompt focus or selection is explicit;
numeric shortcuts and letter shortcuts use the same focus gate;
timeout or dismissed prompt produces no tool execution;
accidental keypress leaves an auditable no-effect result.

That makes always approve a deliberate UI action rather than ambient keyboard state.

BGMLAI · 1 month ago

This is an input freshness problem as much as a keybinding problem. Permission dialogs should discard characters queued before the dialog activation epoch, and acceptance should require a fresh event after the prompt is visible. Removing letter accelerators reduces accidental approvals, but buffered digits can still collide. A safer pattern is arrows plus Enter, with high-impact actions requiring a distinct confirmation gesture. Please test message enqueue racing with prompt creation, key repeat, paste, and focus changes.