Windows: resume by session name rejects existing threads with verbatim rollout paths (CLI 0.162.1) #54038

Disclosure: OpenAI Codex performed the local investigation and diagnostic tests described below, and drafted and submitted this report through my GitHub account at my request.

Summary

On Windows, codex resume "<session-name>" reports that no saved session exists even though the name is present in both session_index.jsonl and state_5.sqlite, and thread/list and thread/read return the correct named thread.

The affected thread has a Windows verbatim path (\\?\C:\...) stored in threads.rollout_path. Name lookup rejects that path when checking whether it starts with the non-verbatim sessions root. Resume by UUID succeeds.

Environment

• Codex CLI: 0.162.1, installed through npm
• OS: Windows Server 2025, build 26100, x64
• Shell: PowerShell
• Affected session originally created with CLI 0.153.4
• Session source: cli; not archived; model provider: openai
• API reported history mode: paginated

Steps to reproduce

1. On Windows, create a session and rename it using /rename kex.
2. Close and resume the session by UUID. In the tested environment, opening the session stores threads.rollout_path with a \\?\ prefix.
3. Exit and run codex resume kex from the saved project directory.
4. Observe:

   No saved session found with ID kex. Run `codex resume` without an ID to choose from existing sessions.
   

5. Run codex resume <SESSION_UUID>: the same conversation opens successfully.

The original reproduction used an existing session created on 0.153.4, rather than a clean new-session test on 0.162.1.

Expected behavior

Resume by the exact name saved through /rename should open the same session as resume by UUID. Equivalent Windows paths should pass the local sessions-root check.

Diagnostic evidence

• session_index.jsonl contains the expected thread_name.
• SQLite threads.name contains the same name; archived = 0.
• thread/list with active CLI/VSCode sources includes the affected thread and correct name.
• thread/read by UUID returns the same correct name and path.
• The rollout file exists and the session opens successfully by UUID.
• --all does not fix name lookup.
• --no-daemon does not fix name lookup.
• Temporarily removing only the \\?\ prefix from that thread's SQLite rollout_path makes codex resume kex succeed.
• Opening the session writes the prefixed path back, so that database edit is not a persistent workaround.

No conversation content or private project data is included in this report. Paths below use placeholders:

Stored rollout_path: \\?\C:\Users\<user>\.codex\sessions\...\rollout-<session>.jsonl
Expected root:       C:\Users\<user>\.codex\sessions

Suspected root cause

In codex-rs/tui/src/named_session_lookup.rs at tag rust-v0.162.1, local named-session lookup skips a candidate when:

!path.starts_with(expected_root)

The stored verbatim path and the non-verbatim sessions root represent the same location, but have different Windows path prefixes. The controlled SQLite-path test above points to this check as the cause.

Source: https://github.com/openai/codex/blob/rust-v0.162.1/codex-rs/tui/src/named_session_lookup.rs

Suggested fix

Normalize both paths to a consistent Windows representation before the containment check, while preserving the intended sessions-root containment restriction. Also keep persisted rollout paths consistent across resume operations.

A regression test should verify that the named-session lookup accepts a verbatim rollout path inside the equivalent non-verbatim sessions root, still rejects paths outside the root, and continues working after reopening the session.

Workaround

Use codex resume <SESSION_UUID>.

Related reports

• Windows: thread/archive fails with "os error 2" after thread/resume stores a \\?\ (verbatim) rollout_path — same file queued twice #39239: archive failure after resume persists a verbatim rollout path; a similar controlled prefix-removal test, but a different failing code path.
• [Windows] Cannot resume thread due to stale path mismatch between normal path and \\?\ verbatim path #26059: stale-path mismatch while resuming a running thread; a different error from the name-lookup failure reported here.