tui: double-press Ctrl+C/Ctrl+D to quit

[joshka-oai]

Problem

Codex’s TUI quit behavior has historically been easy to trigger accidentally and hard to reason
about.

• Ctrl+C/Ctrl+D could terminate the UI immediately, which is a common key to press while trying
  to dismiss a modal, cancel a command, or recover from a stuck state.
• “Quit” and “shutdown” were not consistently separated, so some exit paths could bypass the
  shutdown/cleanup work that should run before the process terminates.

This PR makes quitting both safer (harder to do by accident) and more uniform across quit
gestures, while keeping the shutdown-first semantics explicit.

Mental model

After this change, the system treats quitting as a UI request that is coordinated by the app
layer.

• The UI requests exit via AppEvent::Exit(ExitMode).
• ExitMode::ShutdownFirst is the normal user path: the app triggers Op::Shutdown, continues
  rendering while shutdown runs, and only ends the UI loop once shutdown has completed.
• ExitMode::Immediate exists as an escape hatch (and as the post-shutdown “now actually exit”
  signal); it bypasses cleanup and should not be the default for user-triggered quits.

User-facing quit gestures are intentionally “two-step” for safety:

• Ctrl+C and Ctrl+D no longer exit immediately.
• The first press arms a 1-second window and shows a footer hint (“ctrl + again to quit”).
• Pressing the same key again within the window requests a shutdown-first quit; otherwise the
  hint expires and the next press starts a fresh window.

Key routing remains modal-first:

• A modal/popup gets first chance to consume Ctrl+C.
• If a modal handles Ctrl+C, any armed quit shortcut is cleared so dismissing a modal cannot
  prime a subsequent Ctrl+C to quit.
• Ctrl+D only participates in quitting when the composer is empty and no modal/popup is active.

The design doc docs/exit-confirmation-prompt-design.md captures the intended routing and the
invariants the UI should maintain.

Non-goals

• This does not attempt to redesign modal UX or make modals uniformly dismissible via Ctrl+C.
  It only ensures modals get priority and that quit arming does not leak across modal handling.
• This does not introduce a persistent confirmation prompt/menu for quitting; the goal is to keep
  the exit gesture lightweight and consistent.
• This does not change the semantics of core shutdown itself; it changes how the UI requests and
  sequences it.

Tradeoffs

• Quitting via Ctrl+C/Ctrl+D now requires a deliberate second keypress, which adds friction for
  users who relied on the old “instant quit” behavior.
• The UI now maintains a small time-bounded state machine for the armed shortcut, which increases
  complexity and introduces timing-dependent behavior.

This design was chosen over alternatives (a modal confirmation prompt or a long-lived “are you
sure” state) because it provides an explicit safety barrier while keeping the flow fast and
keyboard-native.

Architecture

• ChatWidget owns the quit-shortcut state machine and decides when a quit gesture is allowed
  (idle vs cancellable work, composer state, etc.).
• BottomPane owns rendering and local input routing for modals/popups. It is responsible for
  consuming cancellation keys when a view is active and for showing/expiring the footer hint.
• App owns shutdown sequencing: translating AppEvent::Exit(ShutdownFirst) into Op::Shutdown
  and only terminating the UI loop when exit is safe.

This keeps “what should happen” decisions (quit vs interrupt vs ignore) in the chat/widget layer,
while keeping “how it looks and which view gets the key” in the bottom-pane layer.

Observability

You can tell this is working by running the TUIs and exercising the quit gestures:

• While idle: pressing Ctrl+C (or Ctrl+D with an empty composer and no modal) shows a footer
  hint for ~1 second; pressing again within that window exits via shutdown-first.
• While streaming/tools/review are active: Ctrl+C interrupts work rather than quitting.
• With a modal/popup open: Ctrl+C dismisses/handles the modal (if it chooses to) and does not
  arm a quit shortcut; a subsequent quick Ctrl+C should not quit unless the user re-arms it.

Failure modes are visible as:

• Quits that happen immediately (no hint window) from Ctrl+C/Ctrl+D.
• Quits that occur while a modal is open and consuming Ctrl+C.
• UI termination before shutdown completes (cleanup skipped).

Tests

• Updated/added unit and snapshot coverage in codex-tui and codex-tui2 to validate:
  • The quit hint appears and expires on the expected key.
  • Double-press within the window triggers a shutdown-first quit request.
  • Modal-first routing prevents quit bypass and clears any armed shortcut when a modal consumes
    Ctrl+C.

These tests focus on the UI-level invariants and rendered output; they do not attempt to validate
real terminal key-repeat timing or end-to-end process shutdown behavior.

---

Screenshot:

[jif-oai]

@codex review

[jif-oai]

I think @nornagon-openai review would be good here

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 15ca2f5258

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joshka-oai]

Added a bit more docs and fixed something that that doc review caught.

modal/popup-handled Ctrl+C now clears any armed quit shortcut/hint instead of arming it; composer-clear Ctrl+C still arms as before.