Codex CLI approval prompts can steal input while user is typing

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.

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.

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.

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: https://github.com/ivnnv/codex/pull/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.

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.