›_ Codex Issues
Codex Issues / #20165

codex resume --all does not list existing local sessions, while resume <session-id> can open them

Open 💬 5 comments Opened Apr 29, 2026 by Torchbearer127
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 <session-id>

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?

  1. Use Codex CLI with existing local sessions stored in ~/.codex/sessions.
  1. Confirm rollout files exist, for example:

~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

  1. Change authentication/configuration (in my case: switched from API key custom provider to ChatGPT login).
  1. Run:

codex resume --all

  1. Observe the picker shows "No sessions yet".
  1. Run:

codex resume <existing-session-id>

  1. 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 <session-id>

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #19318
  • #19822
  • #20004
  • #19362

Powered by Codex Action

minsing-jin · 3 months ago

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 CreatePullRequest from my fork.

Issue:

Filtered thread/list can reconcile SQLite DB hits but still return the filesystem scan page. This can omit valid indexed sessions from resume/fork pickers even though direct codex 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:

https://github.com/openai/codex/compare/main...minsing-jin:codex:fix/resume-picker-indexed-filter-results

Validated with:

  • just fmt
  • just fix -p codex-rollout
  • cargo test -p codex-rollout --manifest-path codex-rs/Cargo.toml

If 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 · 3 months ago

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: https://github.com/minsing-jin/codex/commit/a45684b388280879b6b995ccf0e2d46eb3bbda2b

Necmttn · 2 months ago

The picker/index path should probably treat the filesystem scan as the recovery source of truth.

If codex resume <id> can open a rollout but resume --all omits 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._

shleder · 14 days ago

I’m testing Codex Rescue 0.1.0a3 against local session-discovery failures. Your case is a strong fit because codex resume --all loses the sessions while direct resume by ID can still reach them and the rollout files remain on disk.

Rescue discovers local rollout sessions independently of the normal picker/index and does not modify Codex SQLite/index files.

If the state still reproduces, would you be willing to try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

I’d be especially interested in whether sessions finds entries that codex resume --all misses. Sanitized output only; please don’t post raw rollouts, prompts, DBs, credentials, or private paths.

https://github.com/shleder/codex-rescue