[TUI] Double-Esc interrupt/rewind frequently freezes or terminates long sessions

What version of Codex CLI is running?

codex-cli 0.145.0 (the latest stable release at the time of filing)

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 25.3.0 arm64 arm (macOS 26.3.1)

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

Warp v0.2026.07.01.09.21.stable_01, with no tmux/zellij/screen multiplexer.

Codex doctor report

Privacy-redacted summary (the full report contains local paths and a rollout identifier):

{
  "overallStatus": "warning",
  "codexVersion": "0.145.0",
  "runtime": {
    "platform": "macos-aarch64",
    "installMethod": "npm"
  },
  "config": {
    "model": "gpt-5.6-sol",
    "modelProvider": "openai",
    "relevantEnabledFeatures": [
      "tui_app_server",
      "steer",
      "sqlite",
      "terminal_resize_reflow"
    ]
  },
  "state": {
    "activeRolloutFiles": 632,
    "activeRolloutBytes": 2570366383,
    "activeRolloutDbRows": 631,
    "missingActiveRows": 1,
    "databaseIntegrity": "ok"
  },
  "updates": {
    "installed": "0.145.0",
    "latest": "0.145.0"
  }
}

The only doctor warning is that one active rollout file is missing from the state DB. I am including that observation without asserting that it causes this bug.

What issue are you seeing?

Pressing Esc to interrupt an active turn and then pressing Esc again frequently sends the TUI into the rewind/backtrack path and leaves the session permanently frozen or terminated. This is especially damaging because the double press often happens while urgently trying to stop the agent from taking a destructive action; the user is not necessarily trying to rewind.

Observed frequency over repeated incidents:

• Approximately 70% of the time, the TUI never becomes usable again. It remains frozen indefinitely or the process/session appears to terminate and does not recover.
• Approximately 30% of the time, the TUI remains unresponsive for a very long time and eventually enters rewind.

There is usually no displayed error or backtrace because the full-screen TUI simply stops responding. The rollout may still exist on disk, but the working session is no longer accessible through the current TUI and the user has to search saved sessions and attempt recovery. In-progress state and confidence that the emergency interrupt actually stopped the agent are lost.

This has occurred across many Codex versions and still occurs on the current latest stable version, 0.145.0.

This is safety-critical behavior: the interrupt control must remain reliable precisely when the user believes the agent may be doing something destructive.

What steps can reproduce the bug?

1. Start or resume a long, tool-heavy Codex TUI session with substantial transcript history.
2. Let the agent begin an active turn or tool-heavy operation.
3. Press Esc to interrupt the active work.
4. Press Esc again quickly, either because the first interrupt has not visibly completed or because the user is urgently trying to ensure the operation stops.
5. Observe the interrupt/rewind transition.
6. The TUI frequently freezes indefinitely or terminates; less often, it remains frozen for a long period and eventually opens rewind.

The race appears most visible when the first Esc is still interrupting the active turn and the second Esc is interpreted as the double-Esc rewind gesture.

What is the expected behavior?

• The first Esc should acknowledge and complete the interrupt promptly.
• A second Esc received while interruption is still pending should be safely buffered, ignored, or handled only after the interrupt reaches a stable state.
• Rewind should open promptly and must never block the event loop or make the session inaccessible.
• The TUI should distinguish “interrupt is pending” from “open rewind” so an emergency double press cannot destroy the working session.
• If rewind fails, the original session should remain immediately resumable with no loss of persisted state.

Additional information

Recent local TUI logs contain repeated warnings such as:

app-server event consumer lagged; dropping ignored events skipped=1281
app-server event consumer lagged; dropping ignored events skipped=470
app-server event consumer lagged; dropping ignored events skipped=428

No panic or stack-overflow record corresponding to these incidents was captured. The event-consumer warnings may or may not be related, but they show the TUI event path falling behind during real sessions.

Issue #4977 (“Double Esc backtrack causes stack overflow”) looks related historically, but this is not the same reproduction: #4977 was a Windows stack overflow with no user messages to highlight. This report is current macOS, occurs during the active-turn interrupt-to-rewind transition in long sessions, and usually presents as an indefinite hang or inaccessible session rather than a visible stack-overflow error.