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

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.