CLI prompts can steal in-progress typing and accidentally accept y/a/n or 1-3 selectors

What version of Codex CLI is running?

codex-cli 0.143.0

What subscription do you have?

ChatGPT Pro 20X

Which model were you using?

This appears to be a CLI/TUI input-handling issue rather than model-specific. Current local config reports gpt-5.5.

What platform is your computer?

Linux 7.0.10+deb14-amd64 x86_64 unknown

What terminal emulator and version are you using (if applicable)?

Observed in an interactive terminal session under GNU screen:

TERM=screen-256color-bce
STY=369965.codexpromptbug

Codex doctor report

codex doctor --json was run from the current Codex sandboxed session. It reports overallStatus: fail only because network checks are blocked by the sandboxed environment (Operation not permitted / DNS failure); auth, config, install, runtime, state DBs, and terminal metadata were otherwise readable. I can paste the full JSON if maintainers need it, but it is not relevant to the input-focus failure described below.

What issue are you seeing?

Codex CLI/TUI prompts can take over keyboard input while the user is actively typing a message in the composer. When this happens, ordinary characters intended for the draft message can be interpreted as answers to the prompt.

The most dangerous cases are prompt options with single-key shortcuts or numeric selectors, for example:

• file-write / patch / permission prompts that accept letter shortcuts such as y, a, or n;
• structured selector prompts that accept 1, 2, or 3;
• other approval/question surfaces that use ordinary printable typing characters as immediate answers.

If I am typing a follow-up message while Codex is working, and Codex suddenly renders one of these prompts, the input target effectively changes underneath me. A normal word containing y, a, or n, or a list I am typing with 1, 2, or 3, can accidentally approve, deny, or choose an option before I have seen the prompt.

This is especially risky for file-write prompts because an accidental y or a can approve a write or remember a broader approval path, while an accidental n can deny work that I did not intend to deny.

This is not only about the exact key bindings. The core problem is that Codex lets a modal prompt steal keyboard context from an in-progress text input.

What steps can reproduce the bug?

1. Start an interactive Codex CLI/TUI session.
2. Ask Codex to do work that may later require a file-write, patch, command approval, or structured question prompt.
3. While Codex is still working, start typing a follow-up message in the composer. Do not submit it yet.
4. Continue typing normal text that contains prompt shortcut characters, such as y, a, or n, or type numbered text with 1, 2, or 3.
5. Let Codex render an approval/question prompt before the draft is submitted.
6. Observe that a keypress intended for the draft can be consumed as the prompt answer.

Concrete examples:

• User is typing "yes, also adjust ..." when a prompt appears; the y can accept the prompt.
• User is typing "and then ..." when a prompt appears; an a shortcut can select an "always" or similar option if that prompt supports it.
• User is typing a numbered instruction list; 1, 2, or 3 can select a prompt option instead of entering text in the draft.

What is the expected behavior?

Codex should not allow prompts to steal active text-composition input.

Expected behavior could be implemented in several ways:

• If the user is actively typing in the composer, keep focus in the composer and queue the prompt.
• Show a non-destructive notice such as "Codex needs your input" while preserving the draft and continuing to route ordinary typing to the draft.
• Require an explicit focus/action to enter the prompt, such as Shift+Tab, Ctrl+Tab, or another deliberate prompt-focus shortcut.
• Once prompt focus is explicit, show the fixed-choice answers and allow keyboard selection there.
• Do not accept ordinary printable characters like y, a, n, or 1-3 as prompt answers while the composer owns focus.
• Preserve the user's draft exactly as typed if a prompt arrives mid-composition.

The important behavior is that an in-progress text input remains the keyboard context until the user deliberately switches to the prompt.

Additional information

I found related reports, but this issue is focused specifically on file-write/default approval prompts and other selectors accepting ordinary typing characters while the user is composing:

• #27374: Codex CLI approval prompts can steal input while user is typing
• #28551: Avoid interrupting a user actively typing
• #31037: Disable letter keys in tool permission asks to prevent conflicts with message enqueue

This report is compatible with those issues: the safer design is to separate "the user is writing a prompt" from "Codex is asking for a structured choice", instead of letting the structured choice take over the same keyboard stream unexpectedly.