codex resume <name> can fail after a fresh thread is auto-named, and unsaved name entries can shadow older saved sessions

What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

Unknown / not relevant to this bug

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.3.0 arm64 arm

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

Zed terminal (TERM=xterm-256color)

What issue are you seeing?

A fresh interactive Codex CLI session can print a resumable thread name before any resumable session data actually exists.

Example observed behavior:

1. Start codex in a directory named smarty-pants
2. Codex prints:

Thread renamed to smarty-pants, to resume this thread run codex resume smarty-pants

1. Exit before sending the first user message
2. Run:

codex resume smarty-pants

1. Codex fails with:

ERROR: No saved session found with ID smarty-pants. Run \codex resume\ without an ID to choose from existing sessions.

Underlying local state shows the thread name was indexed even though no resumable session exists yet:

• ~/.codex/session_index.jsonl contains a thread_name entry for the new thread id
• there is no rollout file for that thread under ~/.codex/sessions/...
• there may also be no corresponding persisted thread row yet

This means the CLI can advertise a name-based resume command for a thread that is not actually resumable.

It also has a worse side effect: if there is an older saved thread with the same name, the newer unsaved name entry can win name lookup and block access to the older saved thread.

What steps can reproduce the bug?

Minimal repro:

1. Create or enter a directory named smarty-pants
2. Run codex
3. Observe that Codex prints a resume hint using the thread name smarty-pants
4. Exit before sending the first user message
5. Run codex resume smarty-pants
6. Observe that resume fails even though Codex just suggested that exact command

Shadowing repro:

1. Have an older saved thread already named smarty-pants
2. Start a new fresh CLI session in a directory that causes the new thread to also be named smarty-pants
3. Exit before the first user message is persisted
4. Run codex resume smarty-pants
5. Observe that Codex resolves the newest unsaved name entry first instead of resuming the older saved thread

What is the expected behavior?

One of these should happen:

• Codex should not suggest codex resume <name> until a resumable rollout actually exists
• name-based resume should skip unresolved / unsaved name entries and fall back to the newest saved session with that name
• ideally both

A fresh unsaved thread name should not block name-based access to an older saved session.

Additional information

This appears to come from thread names being appended to session_index.jsonl before rollout persistence exists, while name-based resume trusts the newest matching name entry.

A high-level fix direction would be either:

• do not index thread names until the session has persisted resumable state
• or make name-based lookup skip entries that do not resolve to a saved rollout path

A UI follow-up would be to stop printing a resume command in the rename confirmation until the session is actually resumable.

This seems related in spirit to #15870, but it is a different repro:

• #15870 is about early transport failure after a session id is printed
• this repro happens on a normal fresh interactive session with no transport failure required

I have a tested local patch and regression tests for this if the Codex team wants a PR by invitation.