codex - 💡(How to fix) Fix macOS/Kitty: TUI can remain non-reactive after task_complete while process stays busy [1 comments, 2 participants]

What version of Codex CLI is running?

0.124.0

What platform is your computer?

macOS 26.4.1 arm64

What terminal emulator and version are you using?

Kitty 0.46.1

What issue are you seeing?

I observed multiple Codex CLI TUI sessions where the terminal UI became non-reactive while the session transcript had already recorded completion.

The important state mismatch:

• the live Kitty tab still contained a running Codex process
• Kitty reported the window as not at a shell prompt, so the tab looked busy
• the corresponding Codex JSONL rollout's last event was event_msg / task_complete
• the UI did not accept useful interaction in the original tab
• this happened in more than one live Kitty tab on the same machine

This made the session look stuck even though the recorded task had completed. I had to preserve the JSONL transcript and visible Kitty screen, then launch a fresh codex fork/codex resume tab.

Local diagnosis method

I correlated the live Kitty window with the Codex session JSONL using kitty @ ls, lsof -p <codex-pid>, and the latest event in the rollout file.

The stale condition was:

source: live Kitty window with Codex process
kitty state: busy / not shell prompt
jsonl last event: event_msg.task_complete
diagnosis: stale-ui

A fresh revive-launched tab can be created with:

codex fork --no-alt-screen <session-id>
# or
codex resume --no-alt-screen <session-id>

Expected behavior

After task_complete, the TUI should return to a reactive input state, or at least expose a recoverable error state. The original tab should not remain in a busy/non-reactive state after completion is recorded.

Actual behavior

The original Kitty tab stayed alive but non-reactive. The transcript was complete on disk, but the TUI did not recover.

Related issues

This appears related to stale TUI/busy-state reports such as:

• #16904
• #12645
• #14314

but this report is specifically macOS + Kitty + Codex CLI 0.124.0, with the observed mismatch between live Kitty state and JSONL task_complete.

Workaround

I built a local recovery script that:

1. discovers live Kitty/Codex tabs
2. maps each live process back to its .codex/sessions/**/*.jsonl
3. flags live windows whose rollout ends in task_complete as stale
4. preserves raw JSONL, markdown export, and visible Kitty screen text
5. launches codex fork or codex resume in a new Kitty tab
6. only closes the old stale Kitty tab after the replacement tab is confirmed alive

I can provide more diagnostics if there is a preferred debug command or log source for TUI state.