CLI: resume can get stuck on Working after unclean disconnect/shutdown of an active turn

What version of Codex CLI is running?

codex-cli 0.104.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

Primarily gpt-5.3-codex

What platform is your computer?

Linux x86_64 (Ubuntu 25.10, kernel 6.17.0-14-generic)

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

zsh terminal on Linux

What issue are you seeing?

codex resume <thread-id> can get stuck on Working for long-lived threads after an unclean disconnect/shutdown (for example interrupt while a tool call is still running, then close/kill session and later resume).

This is thread-specific. Fresh/new sessions usually work.

MCPs do not seem to be the root cause:

• Repro still occurs with MCPs disabled.
• Re-enabling/disabling MCP does not eliminate recurrence.

What steps can reproduce the bug?

1. Start a long-running turn in Codex (for example a command that requires repeated polling / write_stdin updates).
2. Interrupt / terminate the Codex process uncleanly while that turn is still active (Ctrl+C / shutdown / disconnect).
3. Run codex resume <same-thread-id>.
4. Observe resume opening but staying stuck on Working with no progress.

What is the expected behavior?

Resume should recover cleanly from interrupted turns (or mark them aborted) and allow normal interaction, rather than remaining in a stale in-progress state.

What is the actual behavior?

The resumed thread often appears stuck in a stale in-progress state (Working) until manual JSONL repair.

Evidence (from local logs/session state)

Observed on 2026-02-20:

• Thread file:
• stored under ~/.codex/sessions/.../rollout-*.jsonl
• size: ~300 MB
• lines: ~73k

• Tail boundary indicates incomplete turn:
• last_task_started=2026-02-20T22:29:02.373Z
• last_task_complete=2026-02-20T21:35:53.389Z

• Log sequence shows unclean interruption/shutdown followed by resume + fallback warnings:
• 2026-02-20T22:28:29Z interrupt received
• 2026-02-20T22:28:30Z shutting down Codex instance
• 2026-02-20T22:28:54Z resumed rollout successfully
• repeated warnings: state db record_discrepancy: find_thread_path_by_id_str_in_subdir, falling_back

Workaround

I can recover by trimming session JSONL to the last event_msg task_complete boundary (with backup), then resume works again.

That workaround strongly suggests the resume path is not robust to interrupted in-flight turns.

Related issues

Possibly related to:

• #11852 (stale Working after reconnect)
• #11685 (unable to resume large conversations)

Request

Could Codex automatically harden resume against this pattern by detecting/recovering incomplete tails (e.g., task_started newer than task_complete) after unclean shutdown/disconnect?