`codex resume <unique-session-name>` fails whenever session lookup spans multiple pages

What version of Codex CLI is running?

codex-cli 0.154.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

Not applicable. The failure occurs during session-name resolution, before a model turn starts.

What platform is your computer?

Linux 7.0.0-29-generic x86_64 x86_64 (Ubuntu 24.04)

What terminal emulator and version are you using?

GNOME Terminal; no terminal multiplexer involved in the reproduction.

What issue are you seeing?

In Codex CLI 0.154.0, codex resume <session-name> rejects a unique exact-name match whenever the relevant session listing requires more than one page:

Cannot verify a unique session label across server pages; matching session UUID: <uuid>. Use it only if this is the session you want.

In the affected installation:

• the lookup covers 131 active interactive CLI/VS Code sessions for the OpenAI provider, so the hard-coded 100-session page size causes pagination;
• the requested label occurs exactly once in both session_index.jsonl and state_5.sqlite;
• there is no hidden whitespace or alternate spelling; and
• codex resume <uuid> successfully resumes that same session.

This makes name-based resume depend on inventory size: it works while the relevant lookup fits on one page and stops working once the lookup is paginated. The documented SESSION_ID syntax nevertheless remains uuid | session name.

What steps can reproduce the bug?

1. Use Codex CLI 0.154.0 with more than 100 active interactive sessions matching the resume lookup's collection, source, and provider filters.

2. Use /rename <unique-session-name> in one session, ensuring that no other eligible session has that exact name.

3. Run:

   codex resume <unique-session-name>
   

4. Observe the pagination/UUID error above.

5. Run codex resume <uuid> for the UUID printed in the error and observe that the intended session resumes successfully.

The existing test rejects_duplicate_labels_across_server_pages demonstrates the same threshold behavior. After constructing 102 sessions, it intentionally expects lookup of the unique label other-1 to fail solely because the listing was paginated.

What is the expected behavior?

An exact session name should remain usable independently of how many sessions the user has:

• zero exact matches: report that the session was not found;
• one exact match: resume it;
• multiple exact matches: do not act automatically; show enough candidate metadata—UUID, update time, working directory/project, and a short preview—to let the user select the intended session by UUID.

For destructive commands that share this resolver, such as archive or delete, the selected candidate can additionally require confirmation. A duplicate name should lead to explicit disambiguation rather than disabling name lookup for every paginated inventory.

Additional information

The behavior was introduced by PR #43315, Resolve session labels uniquely before acting on them. Its safety objective is valid: selecting the first duplicate label could resume, archive, or delete the wrong session, and an older timestamp-only server cursor could skip sessions sharing a timestamp at a page boundary.

The implementation applies that compatibility concern too broadly:

1. named_session_lookup::lookup requests pages with limit: Some(100).
2. It sets one global paginated flag if any response has a next_cursor.
3. It traverses the returned pages and validates matching candidates with thread/read.
4. Even if exactly one validated match remains, it returns AmbiguousSessionName::Paginated whenever paginated is true.

Pagination is therefore treated as ambiguity even when no ambiguity was observed. The rejection also applies to the current embedded/local app server, where Codex controls both ends of the protocol and the RecencyAt cursor includes the thread UUID as a tie-breaker. It is not limited to an older remote server with the cursor behavior that motivated the safeguard.

A narrower solution could preserve the safety goal without disabling name lookup for larger histories:

• use stable composite pagination, such as (timestamp, UUID), and accept a unique exact match after exhaustive traversal;
• resolve exact names directly in the local state database or through a server-side exact-name query;
• present verified duplicates as selectable candidates; and
• retain the UUID-only fallback only for a remote server version/capability whose pagination genuinely cannot enumerate all candidates reliably.

Relevant references:

• Documentation: https://developers.openai.com/codex/cli/reference#codex-resume
• Introducing PR: https://github.com/openai/codex/pull/43315
• 0.154.0 lookup implementation: https://github.com/openai/codex/blob/rust-v0.154.0/codex-rs/tui/src/named_session_lookup.rs#L60-L90 and https://github.com/openai/codex/blob/rust-v0.154.0/codex-rs/tui/src/named_session_lookup.rs#L166-L170
• 0.154.0 pagination test: https://github.com/openai/codex/blob/rust-v0.154.0/codex-rs/tui/src/named_session_lookup_tests.rs#L276-L347
• Stable local RecencyAt cursor: https://github.com/openai/codex/blob/rust-v0.154.0/codex-rs/rollout/src/list.rs#L762-L783

Start with codex-rs/tui/src/named_session_lookup.rs and its named_session_lookup_tests.rs, especially rejects_duplicate_labels_across_server_pages; then inspect the RecencyAt cursor handling in codex-rs/rollout/src/list.rs. Confirm that exhaustive pagination resumes one exact match, reports zero matches, and presents verified duplicates for disambiguation without weakening safety checks.