`codex resume` picker is slow with many local sessions because thread/list scans rollout files

What version of Codex CLI is running?

codex-cli 0.125.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

-

What platform is your computer?

Linux 6.17.0-22-generic x86_64

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

-

What issue are you seeing?

Running codex resume can take several seconds before the resume picker becomes usable when the local ~/.codex/sessions directory contains many rollout files.

Source inspection suggests the picker requests thread/list sorted by updatedAt. The local rollout listing path must stat all rollout files to sort by mtime, then read rollout heads for matching rows. This happens even when the SQLite state DB exists because the picker sends useStateDbOnly: false, and the backend uses a filesystem-first scan-and-repair path for filtered listings.

On one local profile there are about 574 rollout files across 141 day directories, and codex resume can appear to hang/thinking for around 10 seconds.

What steps can reproduce the bug?

1. Accumulate many local sessions under ~/.codex/sessions/YYYY/MM/DD/.
2. Run codex resume with no session id.
3. Observe the delay before the resume picker is populated.

What is the expected behavior?

The resume picker should open quickly, ideally using the SQLite state DB or another lightweight index for updatedAt ordering, and only scan rollout JSONL files as a fallback or background repair path.

Additional information

Relevant code paths:

• codex-rs/tui/src/resume_picker.rs sends thread/list with sortKey: updatedAt and useStateDbOnly: false.
• codex-rs/rollout/src/list.rs documents that updatedAt ordering must scan all files up to the scan cap because updated time is not encoded in filenames.
• codex-rs/rollout/src/recorder.rs performs filesystem-first listing before querying SQLite in the scan-and-repair path.