›_ Codex Issues
Codex Issues / #28068

bug: Local sessions persist in filesystem but disappear completely from codex resume --all and Desktop Sidebar (SQLite index mismatch)

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

What issue are you seeing?

Historical conversation sessions have completely disappeared from both the Codex Desktop App sidebar and the codex resume --all command line utility.

However, our debugging reveals a critical synchronization contradiction based on the following verified facts:

  1. Data Assets Intact: Both the session-index.json and the sessions directory still physically exist with all historical session files intact under C:\Users\Administrator\.codex\.
  2. --all Discrepancy: Running codex resume --all returns empty or only displays newly created test sessions, completely failing to recognize the historical .jsonl files in the subdirectory.
  3. ID Passthrough Works: If I manually extract a 36-character UUID from the first line of any raw .jsonl file, running codex resume <Session_ID> works perfectly and successfully restores the conversation history.
  4. Index Regeneration Failure: If I delete session-index.json, state_5.sqlite, state_5.sqlite-shm, and state_5.sqlite-wal, and then relaunch Codex, the state_5.sqlite, state_5.sqlite-shm, and state_5.sqlite-wal files are regenerated, but session-index.json is NOT re-created. The application completely fails to back-scan the historical files, leaving the sidebar entirely empty (except for the active test session).

What steps can reproduce the bug?

We performed a series of rigorous test cases to isolate the bug. Here are the exact steps and results:

Test Case A: Direct Resume and Exit

  1. Extract a valid historical ID from ~/.codex/sessions/.
  2. Run codex resume <Session_ID> to enter the conversation successfully.
  3. Type /exit immediately to quit the session.
  4. Run codex resume --all.
  • Result: The session does not appear in the list. It is still hidden.

Test Case B: Content Injection via Placeholder (Short Text)

  1. Enter the session via codex resume <Session_ID>.
  2. Input a dot . as a placeholder message and press Enter.
  3. Type /exit to quit.
  4. Run codex resume --all.
  • Result: The session still does not appear in the list.

Test Case C: Content Injection via Real Conversation (Long Text)

  1. Enter the session via codex resume <Session_ID>.
  2. Input a long, realistic human conversational sentence (e.g., a multi-word prompt) to trigger a full model response, ensuring an active interaction event occurred.
  3. Type /exit to quit.
  4. Run codex resume --all.
  • Result: Even after a successful long-text interaction and graceful exit, the session still fails to register back into the --all list or the desktop sidebar. It remains completely invisible unless called explicitly by its absolute ID.

What is the expected behavior?

  1. When state_5.sqlite is missing or regenerated, the Codex background daemon should automatically deep-scan the ~/.codex/sessions/ directory, parse all existing local .jsonl files, and properly rebuild the global index database.
  2. Manually resuming an existing session via codex resume <Session_ID>—regardless of whether it's an immediate exit, a short placeholder input, or a long-text conversation—should instantly force the background database to register or update that session's metadata into the active index (state_5.sqlite) so that it becomes visible globally.

Additional information

  1. Environment: Windows 11 (Root path: C:\Users\Administrator\.codex)
  2. Core Discovery: This issue highlights a severe regression in the local database routing and event persistence layers. The SQLite indexing mechanism seems to actively ignore or filter out historical local files on startup and refuses to commit them back to the global state database even after explicit physical interaction and write events occur during a manual resume.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27363
  • #27843
  • #27408
  • #27159
  • #27847

Powered by Codex Action

Necmttn · 2 months ago

The recovery path should be able to rebuild a read-only session index from the JSONL files.

Each rebuilt row can carry session id, file path, parsed first/last timestamp, cwd/title if found, file mtime, parser version, and parse status. A malformed file should mark one row degraded, not prevent the sidebar/resume list from seeing the rest.

If direct resume by id works, the file set is still a valid source of truth.

---

_Generated with ax._

turismys · 2 months ago

I fixed it successfully

None of the suggested fixes in this issue worked for me (clearing caches, reinstalling the app, etc.).

My Codex installation had been configured to use a custom gateway (I was using a reseller’s server connected to OpenRouter).

My original ~/.codex/config.toml contained:

model_provider = "gateway"
model = "claude-opus-4.8"
[model_providers.gateway]
name = "Gateway"
base_url = "http://45.136.205.7:3188/v1"
wire_api = "responses"
env_key = "OPENAI_API_KEY"
requires_openai_auth = false
supports_websockets = false

I edited it by changing:

model_provider = "openai"
model = "gpt-5.5"

and commented out the entire [model_providers.gateway] section.

Additionally, I downloaded and installed the previous Codex Desktop build:

https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.602.71036.zip

After doing this:

  • all my chats reappeared;
  • the endless reconnect loop stopped;
  • Error 1006 disappeared;
  • Codex started working normally again.

I’m not sure which of these two changes actually fixed the issue (the configuration change, the older build, or the combination of both), but this is what worked in my case.

sunkhx · 1 month ago

Adding a current Windows data point from the post-merge ChatGPT/Codex desktop builds. This still reproduces on the latest update available to this machine.

Environment:

  • Windows 11 x64
  • Previously affected Desktop package: 26.707.12708.0
  • Still affected after updating to: 26.715.2305.0
  • Local Codex home contains 64 active session JSONL files and 39 archived session JSONL files

Observed behavior:

  • The project sidebar shows No chats for historical projects.
  • The app-level thread listing with limit: 49 returns only 2 recent threads, despite 64 active rollout files being present.
  • Historical rollout JSONL files are readable; extracting an old thread ID and navigating/resuming by that exact ID successfully opens the complete conversation.
  • Updating from 26.707 to 26.715 did not trigger a back-scan or rebuild of the historical thread index.

Backup-first workaround attempts that did not restore the sidebar on these builds:

  • Rebuilt .codex-global-state.json -> projectless-thread-ids to include all recoverable active IDs (95 IDs after preserving existing entries).
  • Added/pinned every active thread through the app API (64 pinned IDs currently persisted).
  • Fully quit and restarted the app.
  • Re-tested listing with limit: 49; it still returns only the same 2 recent threads.

This appears to be deeper than project grouping or the old limit >= 50 regression: even a 49-item request does not enumerate the existing active sessions, while direct lookup by exact ID works. The durable rollout files remain a valid source of truth, but the current app does not backfill/reconcile them into the live thread listing.

Please add a supported, non-destructive reindex/recovery path that scans sessions/**/*.jsonl, validates each session independently, and reconstructs the list/sidebar metadata without requiring users to edit SQLite or remember thread titles/IDs.

boombx403-byte · 9 days ago

Hi @Atletico1999, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

If you still have the affected local Codex directory, you can inspect it via:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.