Codex CLI approval prompts can steal input while user is typing

[ivnnv]

What version of Codex are you using?

Current Codex CLI as of June 10, 2026.

What platform is your computer?

macOS, terminal-agnostic. I see this inside the VS Code integrated terminal and in iTerm.

What issue are you seeing?

Codex CLI/TUI can render an approval/question prompt while I am still typing a message in the composer. When that happens, the next keypress or click can be consumed by the prompt instead of continuing my message, so I accidentally answer the approval/question while I was still writing.

This is a bad UX trap because the prompt appears in the same terminal surface where I am actively composing. The UI changes underneath me and the input target effectively changes from "continue typing my message" to "answer this permission prompt".

Claude Code doesnt suffer from this in the same way. I can keep typing while it is working without a mid-compose permission prompt stealing my next action.

Steps to reproduce

1. Start an interactive Codex CLI session in a terminal.
2. Have Codex run a task that may request approval or ask a structured question.
3. While Codex is still working, start typing a follow-up message in the composer.
4. Before submitting that message, let Codex render an approval/question prompt.
5. Continue typing or click, expecting to keep editing the message.
6. The action can instead select/confirm the prompt.

Expected behavior

Codex should not let approval/question prompts steal in-progress user input.

Safer behavior would be one of:

• If the user is actively composing text, keep focus in the composer and queue the approval prompt until the user submits or cancels the draft.
• Render the approval prompt in a way that cannot be answered by ordinary typing meant for the composer.
• Require an explicit focus change before prompt options accept keyboard/click input.
• Preserve the draft exactly as typed if a prompt appears.

Actual behavior

The approval/question prompt can appear while I am composing, and my next action can answer the prompt instead of continuing the message.

Why this matters

This makes Codex feel unsafe during normal interactive use. I should be able to type instructions while the agent is working without worrying that a sudden approval UI will hijack my input and make me approve/reject something by accident.

[rpelevin]

I would treat this as an approval-focus safety boundary, not just terminal UI polish.

The approval prompt becoming visible should not be the same event as making its options actionable. If the user already has an in-progress composer draft, ordinary typing should continue editing that draft until the user explicitly moves focus to the approval surface.

The behavior I would test:

1. user starts typing a draft while an agent action is still running;
2. an approval or question prompt appears before the draft is submitted;
3. the next normal character key is appended to the draft, not consumed as an approval choice;
4. approval choices become actionable only after an explicit focus transfer, dedicated shortcut, or draft submit/cancel boundary;
5. the draft is preserved exactly if the prompt appears mid-compose;
6. mouse clicks only answer the prompt when the click lands on the prompt controls, not when the user is still interacting with the composer.

The key invariant is that approval requires an intentional user action targeted at the approval surface. A prompt that appears under the user's cursor or keystream should not be able to convert ordinary composing into an approve, reject, or answer decision.

[etraut-openai]

The Codex TUI already has logic that prevents the approval/question prompt from appearing if the user is actively typing. The menu appearance is deferred until after 1 second after the last keystroke. This is the same approach used in other CLIs like CC.

[rpelevin]

That debounce is a useful guard. The remaining failure mode I would test is not whether the menu is delayed while keypresses arrive, but whether ownership of the next key is unambiguous once the delay expires.

A time-based delay can still fail if:

• the user pauses long enough for the prompt to appear but is still composing mentally;
• the prompt appears while focus or cursor state still belongs to the draft;
• the next printable key is treated as an approval shortcut;
• paste, IME input, or a multi-key sequence crosses the render boundary;
• input queued before prompt render is consumed by the menu.

I would separate two states:

• prompt_visible: the UI can render the pending approval;
• prompt_armed: approval choices are allowed to consume keys.

prompt_armed should require explicit focus transfer, a dedicated shortcut, or a draft submit/cancel boundary. If composer focus still owns input, printable keys and paste should continue to the draft even if the approval menu has become visible.

Tests I would add:

1. type, pause past the debounce, type the next printable character: draft changes, no approval fires.
2. type, pause, press the dedicated focus shortcut: menu arms, then the choice key works.
3. paste spanning prompt render stays in the draft.
4. mouse click in prompt controls answers; click in the composer keeps composer ownership.
5. prompt render never drains buffered input queued before render.

That keeps debounce as useful UX polish, but makes focus ownership the safety invariant.

[ivnnv]

Thanks, the debounce definitely helps when keys are arriving fast. The reason I keep hitting this is it can't actually tell whether I'm done typing. It only measures time since my last keystroke, so I only need a normal thinking pause between keystrokes, which happens constantly when I'm composing a sentence. If an approval is parked it gets promoted on the next tick after that gap; if it arrives during the gap it shows immediately. Either way the prompt lands over my draft and my next keystroke answers it. I don't even have to stop to read output.

In bottom_pane/mod.rs the parked approval gets promoted with push_view(ApprovalOverlay), and handle_key_event checks view_stack before the composer, so the instant the overlay shows it owns every key. Timing was never the right signal for "is the user still composing"; whether there's an unsent draft is.

I put the change up as a PR on my fork so the diff is easy to read: ivnnv#1 (couldn't open it against this repo directly, looks like PRs here are limited to collaborators). Single invariant: don't auto-show the approval modal while there's an unsent draft. It holds the request, shows a small "approval waiting" hint, and promotes it once the draft is submitted or cleared. The no-draft path is preserved, including the existing idle delay after recent composer activity. I haven't run it in a real session, it's mostly there to make the alternative concrete.

[rpelevin]

Thanks for making this concrete. I agree the important invariant is not just the idle delay; it is that an unsent draft still owns the keyboard.

The code path you pointed to explains the failure well: once a parked approval is promoted into the overlay, key handling checks the view stack before the composer. At that point "visible" and "armed" have become the same state. The debounce lowers the odds, but it does not prove the user is done composing.

The small fix I would preserve is:

• do not auto-promote an approval overlay while the composer has unsent text;
• show a non-actionable pending-approval hint so the wait is not silent;
• promote only after the draft is submitted, cleared, or the user explicitly transfers focus;
• keep the current immediate path when the composer is empty;
• keep queued approvals in FIFO order.

Tests I would want close to the change:

1. non-empty draft remains the keyboard owner after the idle delay expires.
2. incoming approval during a non-empty idle draft stays parked.
3. the next printable key after a parked approval appends to the draft.
4. paste or IME input crossing the promotion boundary stays in the draft.
5. submit draft, then the approval can arm after the existing delay.
6. clear draft, then the approval can arm after the existing delay.
7. multiple parked approvals promote in FIFO order.

That keeps the safety rule simple: an approval can be pending while the user is composing, but it should not become keyboard-authoritative until the draft has reached an explicit boundary.