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

Activity

1. riordant

   added

   bugSomething isn't workingSomething isn't working

   on Nov 20, 2025
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayIssues related to the terminal user interface: text input, menus and dialogs, and terminal display

   on Nov 20, 2025
3. lionel-oai commented on Nov 20, 2025

   

   lionel-oai

   on Nov 20, 2025

   Contributor

   More actions

   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?
4. chaichontat commented on Nov 20, 2025

   

   chaichontat

   on Nov 20, 2025

   More actions

   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.
5. riordant

   changed the title [-]`codex resume/resume --all` results in empty screen[/-] [+]`codex resume/resume --all` slow to load, no loading indicator[/+] on Nov 21, 2025
6. riordant commented on Nov 21, 2025

   

   riordant

   on Nov 21, 2025

   Author

   More actions

   ❯ 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.
7. lionel-oai commented on Nov 21, 2025

   

   lionel-oai

   on Nov 21, 2025

   Contributor

   More actions

   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?
8. whizzrd commented on Dec 8, 2025

   

   whizzrd

   on Dec 8, 2025

   Last edited by whizzrd

   More actions

   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.
9. yinkev commented on Feb 3, 2026

   

   yinkev

   on Feb 3, 2026

   More actions

   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).
10. etraut-openai

    removed

    CLIIssues related to the Codex CLIIssues related to the Codex CLI

    on Apr 5, 2026
11. etraut-openai commented on Apr 5, 2026

    

    etraut-openai

    on Apr 5, 2026

    Contributor

    More actions

    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.
12. etraut-openai

    closed this as completedon Apr 5, 2026