Codex resume picker is slow on WSL2 with large rollout JSONL files despite state_5.sqlite index

What version of Codex CLI is running?

codex-cli 0.125.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

WSL2 / Ubuntu 22.04.5 LTS Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 WSL version: 2.5.10.0 Windows version: 10.0.19045.6466

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

codex-cli 0.125.0

What issue are you seeing?

codex resume has become noticeably slow to load old chats on WSL2 in recent versions. Older Codex CLI versions used to show previous sessions almost immediately.

The slowdown does not seem proportional to the number of sessions in the current repo. Some repos with very few sessions are still slow if their rollout JSONL files are large.

Local redacted evidence:

~/.codex/sessions: 6.1G
~/.codex/sessions rollout files: 473
~/.codex/state_5.sqlite thread rows: 473
~/.codex/log/codex-tui.log: 1.3G

Largest rollout files include:

328M repo A
282M repo B
244M repo B
234M repo C
228M repo B
182M repo C
136M repo D

Aggregated examples:

repo A: 1 session, 328M total rollout size
repo D: about 320M total rollout size across path casing variants
repo E: about 23M total rollout size
repo C: 76 sessions, 719M total rollout size

The important case is repo A: it has only one local Codex session, but codex resume is still slow because that session’s rollout file is very large.

What steps can reproduce the bug?

1. Use Codex CLI on WSL2 with repos stored under /mnt/c/Users/....
2. Accumulate several old Codex sessions, including some large rollout JSONL files under ~/.codex/sessions.
3. Run codex resume inside a repo that has previous sessions.
4. Observe that the old-chat picker takes a long time to load compared with older Codex versions.

### What is the expected behavior?

codex resume should show the previous session picker quickly, preferably using the existing state_5.sqlite index for metadata instead of doing expensive filesystem/rollout scans on large JSONL files.

At minimum, the picker should show a loading/progress state if it needs to scan or repair local session data.

What is the expected behavior?

codex resume should show the previous session picker quickly, preferably using the existing state_5.sqlite index for metadata instead of doing expensive filesystem/rollout scans on large JSONL files.

At minimum, the picker should show a loading/progress state if it needs to scan or repair local session data.

### What happens instead?

The picker is slow to load old chats. The delay is especially noticeable when ~/.codex/sessions contains large rollout JSONL files, even if the current repo itself has very few sessions.

### Possible cause

From inspecting the current source, the TUI resume picker appears to call thread/list with:

use_state_db_only: false
sort_key: ThreadSortKey::UpdatedAt

Because of that, even when state_5.sqlite already contains all thread rows, the listing path can still scan/read rollout JSONL files for filesystem validation / repair / updated_at ordering.

This may explain why performance depends on total rollout file size and global session storage, not only on the number of sessions in the current repo.

Additional information

This looks related to, but not exactly the same as:

• #7007 (codex resume/resume --all slow to load, no loading indicator) - older issue, closed, reported on 0.61.0
• #16280 (resume picker/name-based resume and split state between state_5.sqlite and session_index.jsonl)
• #16624 (local sessions exist in storage but picker/listing behavior is inconsistent)
• #17814 (old session resume issues around compaction)

### Additional notes

A direct resume by session ID is faster because it bypasses the picker, but it is not a good replacement for the normal codex resume workflow.