codex - 💡(How to fix) Fix Typing is unsafe: auth/approval popups steal focus and consume composer keystrokes; persisted rules do not reliably prevent prompts [1 comments, 2 participants]

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4

What platform is your computer?

Rocky-8 Linux

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

tmux - ssh - windows terminal

What issue are you seeing?

At high typing speed, even a brief focus flip is enough to misroute multiple keystrokes before the user notices.

While typing continuously in Codex at high speed, spontaneous auth/approval popups can appear and steal focus from the normal message composer. Keystrokes intended for the prompt are then consumed by the popup as auth/approval input instead of remaining in the composer.

This makes the interface feel unsafe to type in, because ordinary prompt text can accidentally answer a privileged request.

Separately, persisted permissions/rules do not seem sufficient to prevent later prompts in cases where I expected previously accepted permissions or ~/.codex/rules/default.rules coverage to suppress them.

Why this is a problem

Focus-management/input-routing bug:

• ordinary composer input is reinterpreted as dialog input
• auth/approval prompts can consume buffered keystrokes
• prompt text gets corrupted or lost
• the user cannot safely keep typing through background events
• the user cannot trust that typing freeform text will remain in the composer

Annoying AND an input-integrity failure with approval/auth implications.

Severity

High UX severity and possible safety issue, because privileged popups can consume ordinary composer keystrokes.

Suggested fixes

• Make approval/auth dialogs hard-modal with explicit focus handling.
• Never redirect composer keystrokes into newly appearing popups.
• Buffer and restore composer input if an overlay appears mid-typing.
• Add a visible “pending approval request” indicator.
• When re-prompting despite an existing rule, show an explicit “not covered because …” explanation with the rule mismatch.

What steps can reproduce the bug?

1. Open Codex in interactive mode.
2. Begin typing continuously in the normal composer at speed.
3. Trigger or wait for an auth/approval request to appear during typing.
4. Observe that the popup takes focus and consumes keystrokes that were intended for the composer.

A second issue:

1. Allow or persist a rule / “don’t ask again” decision for an action.
2. Continue using Codex in later interactions.
3. Observe that Codex may still prompt again in situations where the existing rule/decision appears like it should have covered the request.

What is the expected behavior?

• Auth/approval popups must not capture ordinary composer input unless explicitly focused.
• If a popup appears while typing, pending keystrokes should remain in the composer.
• Composer text should be preserved exactly across popup appearance/dismissal.
• Approval/auth UI should be strongly modal and visually distinct so accidental typing cannot answer it.
• If an existing persisted rule matches, Codex should not re-prompt.
• If Codex does re-prompt, it should explain exactly why the request was not covered by the existing rule.

Actual behavior

• Random auth/approval popups appear during typing.
• Focus shifts implicitly.
• Keystrokes are eaten by the popup.
• I can no longer trust that typing is safe.
• Existing persisted rules/permissions are not always sufficient to prevent later prompts.

Additional information

• Variant: CLI
• Codex version: codex-cli 0.121.0
• OS: Linux rocky-8
• Sandbox mode / approval policy:

profile = "yolo"
[profiles.yolo]
approval_policy = "never"
sandbox_mode = "danger-full-access"

also many default.rules expressly allowing common commands

• Smart approvals enabled?: yes w/ guardian_subagent