`codex resume/resume --all` slow to load, no loading indicator

Hi @riordant thanks a lot for raising this bug, I'm not able to reproduce both commands are working fine on the 0.61.0 version for me. Could you try to look into your ~/.codex folder and check that the files / directories are not empty?

ls -l ~/.codex
ls -l ~/.codex/sessions

You should see something like:

> ls -l ~/.codex
total 56
-rw-------  1 lionel  staff  5265 Nov 19 09:02 auth.json
-rw-------  1 lionel  staff  1653 Nov 20 15:00 config.toml
-rw-------@ 1 lionel  staff  8233 Nov 20 14:55 history.jsonl
drwxr-xr-x  3 lionel  staff    96 Nov 19 09:01 log
drwxr-xr-x  3 lionel  staff    96 Nov 19 09:02 sessions
-rw-r--r--  1 lionel  staff   101 Nov 20 07:16 version.json
> ls -l ~/.codex/sessions
total 0
drwxr-xr-x  3 lionel  staff  96 Nov 19 09:02 2025

and could you also check that history.jsonl is not empty?

I ran into this too, but only when I was in a different directory and using --cd to set the working directory. The issue did not occur when I'm already in the directory that was previously used.

❯ ls -l ~/.codex
total 520
-rw------- 1 riordant riordant   4241 Nov 17 11:47 auth.json
-rw------- 1 riordant riordant   2017 Nov 20 16:51 config.toml
-rw------- 1 riordant riordant 502505 Nov 20 16:33 history.jsonl
drwxrwxr-x 2 riordant riordant   4096 Oct  7 13:41 log
drwxrwxr-x 3 riordant riordant   4096 Oct  7 13:43 sessions
-rw-rw-r-- 1 riordant riordant     79 Nov 20 14:01 version.json
❯ ls -l ~/.codex/sessions

total 4
drwxrwxr-x 4 riordant riordant 4096 Nov  6 09:56 2025

Ok so - it is resolving the session list now, the problem actually in fact seems to be that it's slow to load it. I think what was happening is that I was hitting ctrl-c while it was loading, and then it finally resolved the command after load, without showing the sessions.

• Did anything change in between versions to cause the session loading screen to be slowed?
• can i run it in debug mode to see how it loads?

if there's a potential for it to slowdown then a loading indicator would be a good idea. if it should be pretty much instant always then I guess there is a bug somewhere.

I think you history.jsonl is quite big compared to mine so it makes sense that you would take longer to load. How long approximately do you have to wait? Around 2-3 seconds?

Additional investigation:

Observed on codex-cli 0.65.0 (released) in a fresh directory with no prior sessions.

When codex resume or /resume is run from a directory with no prior sessions, the picker shows an empty list with no hint, even though sessions exist elsewhere. The picker filters to the current working directory by default:

• tui/src/resume_picker.rs:79-84 sets filter_cwd = current_dir unless --all is used.
• tui/src/resume_picker.rs:247-262 drops any session whose recorded cwd doesn’t match the current dir or whose meta lacks cwd.

Result: launching Codex in a fresh directory hides all sessions and looks broken; the empty state just says “No sessions yet.”

Suggested fix: if the filtered list is empty, fall back to showing all sessions or prompt to show all; at minimum change the empty-state hint to “No sessions for current directory. Press A or run codex resume --all to show all sessions.”

Repro:
1) Start Codex in a new directory (no previous sessions there).
2) Run /resume or codex resume.
3) Observe empty picker; run with --all to see sessions.

I took a look at the resume picker code and I think the initial “blank screen” + “no loading indicator” can happen even when things are just slow (e.g. larger ~/.codex/history.jsonl).

Proposed fix (small + test-covered):

• Subscribe to the TUI draw event stream before scheduling the initial background load, so the first requested draw can’t be dropped due to there being no draw-subscriber yet.
• Show an explicit loading message during the initial load (so users don’t assume it hung / hit Ctrl-C).

Patch (single commit, includes a regression unit test): https://gist.github.com/yinkev/d95f458b6408d4b0c72f8947b145dd63

Local checks I ran (per contributing docs):

• just fmt
• just fix -p codex-tui
• cargo test -p codex-tui

If this approach matches what you want, I’m happy to open a PR if invited (I saw the repo is invitation-only for PRs).

This should now be fixed. We've switched to a sqlite db to track sessions, eliminating the need to do a slow file system enumeration.