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:
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:
- discovers live Kitty/Codex tabs
- maps each live process back to its
.codex/sessions/**/*.jsonl
- flags live windows whose rollout ends in
task_complete as stale
- preserves raw JSONL, markdown export, and visible Kitty screen text
- launches
codex fork or codex resume in a new Kitty tab
- 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.
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:
event_msg/task_completeThis 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 resumetab.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:
A fresh revive-launched tab can be created with:
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:
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:
.codex/sessions/**/*.jsonltask_completeas stalecodex forkorcodex resumein a new Kitty tabI can provide more diagnostics if there is a preferred debug command or log source for TUI state.