Repository navigation
codex resume --all does not list existing local sessions, while resume <session-id> can open them #20165
Description
What version of Codex CLI is running?
0.125.0
What subscription do you have?
ChatGPT Plus
Which model were you using?
gpt-5.4-mini, gpt-5.4, gpt-5.4, gpt-5.5, etc
What platform is your computer?
Darwin 25.4.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Terminal.app and VSCode integrated terminal
What issue are you seeing?
Existing local sessions still exist under ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl.
However:
codex resume --all
shows "No sessions yet".
Direct resume by session id works:
codex resume
Example:
codex resume 019dd81b-cdcd-7da1-8b5a-ee131f2f004a
This suggests the local session files still exist and are readable, but the session picker/index is stale, corrupted, or not rebuilt.
The issue started after switching authentication/config from API key custom provider to ChatGPT account login.
The same local-state issue also appears to affect the VSCode Codex extension because it uses the same ~/.codex directory.
What steps can reproduce the bug?
-
Use Codex CLI with existing local sessions stored in ~/.codex/sessions.
-
Confirm rollout files exist, for example:
~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
-
Change authentication/configuration (in my case: switched from API key custom provider to ChatGPT login).
-
Run:
codex resume --all
-
Observe the picker shows "No sessions yet".
-
Run:
codex resume
- Observe the session can still be opened or partially resumed.
Expected:
resume --all should list all valid local sessions.
Actual:
resume --all shows no sessions even though valid local sessions exist.
What is the expected behavior?
codex resume --all should detect and list all valid local sessions stored under ~/.codex/sessions.
If local index files are stale or missing, Codex should automatically rebuild the session picker from existing rollout session files.
Sessions that can be opened with:
codex resume
should also appear in the resume --all picker.
The VSCode extension should show the same local sessions when it uses the same ~/.codex state directory.
Additional information
Relevant local files existed during the issue:
~/.codex/sessions/**/*.jsonl
~/.codex/history.jsonl
~/.codex/session_index.jsonl
~/.codex/state_5.sqlite
~/.codex/logs_2.sqlite
The problem began after switching authentication/configuration from API key custom provider to ChatGPT login.
Direct resume by session id still works, which suggests the sessions themselves are not lost.
This looks like a local session index / picker synchronization problem rather than missing session data.
Activity
github-actions commentedon Apr 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
minsing-jin commentedon May 20, 2026
Short summary for maintainers:
I found a likely root cause and prepared a tested patch, but I cannot open a PR because the upstream repo rejects
CreatePullRequestfrom my fork.Issue:
Filtered
thread/listcan reconcile SQLite DB hits but still return the filesystem scan page. This can omit valid indexed sessions from resume/fork pickers even though directcodex resume <thread-id>works.Patch:
Return the repaired SQLite indexed page after reconciliation, while preserving the existing filesystem fallback on DB failure.
Branch:
https://github.com/minsing-jin/codex/tree/fix/resume-picker-indexed-filter-results
Compare:
main...minsing-jin:codex:fix/resume-picker-indexed-filter-results
Validated with:
just fmtjust fix -p codex-rolloutcargo test -p codex-rollout --manifest-path codex-rs/Cargo.tomlIf this direction matches the maintainers' expectations, would you be open to inviting a PR from my fork or advising the preferred next step? I'm happy to help with additional QA and regression coverage for resume/listing reliability.
minsing-jin commentedon May 21, 2026
I have a proposed fix available in my fork, but PR creation is restricted to collaborators on this repository.\n\nBranch: https://github.com/minsing-jin/codex/tree/fix/resume-picker-indexed-filter-results\nCommit: minsing-jin@a45684b
Necmttn commentedon Jun 21, 2026
The picker/index path should probably treat the filesystem scan as the recovery source of truth.
If
codex resume <id>can open a rollout butresume --allomits it, the list path can rebuild a degraded row from the JSONL: session id, file path, first/last timestamps, cwd if parseable, parser version, and parse status. SQLite hits and filesystem hits should be reconciled before filtering.Generated with ax.
stanevo commentedon Aug 31, 2026
I can reproduce a closely related issue after switching from ChatGPT authentication to a custom OpenAI-compatible provider through CLIProxyAPI.
Environment:
codex-cli 0.147.0cliproxycliproxyapiObserved behavior:
Existing rollout files remained under
~/.codex/sessions.The old sessions disappeared from the
codex resumepicker.Direct resume initially failed with:
failed to load configuration: Model provider 'cliproxy' not foundI added a backward-compatible
[model_providers.cliproxy]entry with the same configuration as[model_providers.cliproxyapi].After adding that provider alias, direct resume by session ID worked:
codex resume <session-id>Sessions originally created while signed in with ChatGPT can also be resumed successfully through the current custom provider.
However, those sessions still do not appear in the
codex resumepicker.This confirms that the rollout data is intact and resumable. The remaining problem appears to be session discovery/indexing or provider-based filtering in the resume picker.