codex - 💡(How to fix) Fix CLI resume has no recoverable continuation for side terminal resumed from an active session [2 comments, 3 participants]

What version of Codex CLI is running?

codex-cli 0.131.0

Platform

macOS 15.5 (Darwin arm64)

What issue are you seeing?

When I resume the same long-running session from a second terminal to reuse its context, the discussion in that second terminal does not get its own recoverable continuation / branch handle.

This makes the side continuation effectively disappear from normal UX after that terminal is closed, especially if the original/main terminal keeps advancing the same session.

The data may still be buried in ~/.codex/sessions/**/*.jsonl, but there is no practical codex resume / codex fork entry that returns to the side terminal's last message or checkpoint.

This is different from simply wanting to restore an arbitrary old message. The workflow is:

• Terminal A owns a long main session and keeps doing the main task.
• Terminal B temporarily resumes that same session to reuse its context and discuss a side plan.
• Terminal B is closed partway through.
• Later, the user wants to return to Terminal B's side continuation, not Terminal A's latest head.

Today, the CLI/TUI appears to treat the session as a single moving head. Resuming by session id returns to the latest state of the long main session, so the side continuation cannot be selected or resumed from the picker.

Steps to reproduce

1. Start a long interactive Codex TUI session in Terminal A.
2. Keep Terminal A alive and allow it to continue working in that session.
3. Open Terminal B in the same workspace.
4. Resume the same session in Terminal B, e.g. with codex resume <SESSION_ID> or the resume picker.
5. In Terminal B, discuss a different side topic and get a useful output/checkpoint, such as a proposal plan.
6. Close Terminal B.
7. Continue Terminal A so the original session head advances past the side discussion.
8. Later run codex resume <SESSION_ID> or codex fork <SESSION_ID> and try to return to the Terminal B side discussion.

Expected behavior

Codex should make the second terminal's continuation recoverable. Any of these would solve the problem:

• Resuming an already-active session from another terminal automatically creates a distinct continuation/fork id.
• The resume/fork picker shows multiple continuations/checkpoints for the same base session.
• codex resume / codex fork can target a recorded rollout/message/checkpoint from that side continuation.
• Closing Terminal B preserves a named or timestamped continuation entry that can be reopened later.

The important property: a user who intentionally resumes a session in another terminal to reuse context should not lose the ability to return to that side continuation after closing the terminal.

Actual behavior

codex resume <SESSION_ID> and codex fork <SESSION_ID> resume/fork from the session's latest head, which may now be the main Terminal A timeline.

The Terminal B side discussion has no obvious selectable identity in the normal TUI resume/fork flow. Recovering it requires manually searching JSONL session logs and extracting the relevant assistant/user messages.

Why this matters

This is a natural workflow for large codebase tasks:

• Keep one main Codex session doing a long implementation.
• Open a second terminal and resume that same context to ask a related design/research question.
• Close the second terminal when interrupted.
• Come back later and continue that side plan.

At the moment, this workflow is brittle because the side terminal does not become a first-class resumable branch. The result feels like the context was reused successfully while the terminal was open, but the continuation was not durable in a way the user can navigate back to.

Related but not the same

I saw some existing Desktop side-chat/session issues, but this repro is for the CLI/TUI multi-terminal resume workflow. The core problem is not Desktop side-chat UI; it is session/continuation identity when the same recorded session is resumed concurrently from another terminal.