Summary
On Windows, Codex/ChatGPT Desktop can lose visibility of existing conversations even though the underlying local session files still exist on disk as JSONL files under ~/.codex/sessions.
This has happened more than once on the same machine. The conversations appear to be lost from the UI/sidebar, but the JSONL session files are still present locally. In other words, this looks like a local indexing/state/sidebar hydration failure rather than actual data deletion.
Because this failure mode is recurring and highly disruptive, the Desktop app should provide a first-party conversation recovery / reindex capability that can scan the persisted JSONL session files and rebuild the UI-visible conversation index/state.
Environment
- Platform: Windows x64
- Codex Desktop package observed during the latest incident:
OpenAI.Codex 26.820.7780.0
- ChatGPT Desktop also installed on the same machine
- Local session storage:
%USERPROFILE%\.codex\sessions
- User has previously observed conversations disappear from the Desktop UI while the corresponding
.jsonl files remain on disk
What issue are you seeing?
After an app update/startup failure/recovery cycle, conversations that previously existed no longer appear in the Desktop sidebar/history.
The important part is that the underlying files are still present under the local Codex session directory. The data is therefore not necessarily deleted; the Desktop UI simply stops loading/indexing it.
This is especially concerning because the UI gives the impression that the conversations have been permanently lost.
This is not the first time this has happened on this machine.
Expected behavior
If valid local session JSONL files exist, the Desktop app should be able to discover and restore them into the conversation list automatically.
At minimum, the app should provide an explicit recovery action such as:
- Recover conversations
- Rebuild conversation index
- Rescan local sessions
The recovery flow should:
- Scan
%USERPROFILE%\.codex\sessions and archived_sessions.
- Validate readable rollout/session JSONL files.
- Reconstruct missing thread metadata where possible.
- Rebuild or repair
session_index.jsonl / local SQLite/index state used by Desktop.
- Restore valid non-archived conversations to the sidebar/history.
- Report how many conversations were found, recovered, skipped, or corrupted.
- Never overwrite or delete the original JSONL files during recovery.
Why this matters
For long-running software projects, conversations contain implementation context, architectural decisions, debugging history, commands, and reasoning that may span weeks or months.
When the Desktop sidebar suddenly becomes empty or incomplete, users naturally assume their work history has been deleted. If the JSONL source files are still intact, the application should not require users to manually inspect SQLite, edit local state files, identify thread IDs, or reverse engineer internal indexes to recover their own conversations.
A supported recovery function would make the app significantly more resilient to:
- failed migrations
- app updates
- stale/corrupt local indexes
- sidebar/index desynchronization
- local database rebuilds
- reinstall/recovery scenarios
Suggested UX
A recovery option could be exposed under something like:
Settings -> Data / Troubleshooting -> Recover local conversations
Before making changes, it could create a backup of local metadata/index databases, then rebuild derived state from the persisted session JSONL files.
It would also be useful to expose a CLI equivalent, for example conceptually:
codex sessions repair
codex sessions reindex
Related issues
This appears related to an existing family of reports where threads remain on disk but disappear from Desktop/sidebar/search, including:
Those issues mainly describe visibility/indexing failures. This report specifically asks for a supported, user-facing recovery/reindex mechanism so users can restore conversations from the authoritative local JSONL session files when this class of failure occurs again.
Additional information
The same Windows machine recently experienced a separate startup regression in 26.820.7780.0 where the app could not locate/execute the bundled Codex CLI. After recovering the application, the broader concern remains that local conversation history can become detached from the UI even though the JSONL files still exist.
The session JSONL files can contain private source code, prompts, local paths, and other sensitive project information, so a recovery mechanism should operate locally and should not require uploading the raw session files to support or GitHub.
Summary
On Windows, Codex/ChatGPT Desktop can lose visibility of existing conversations even though the underlying local session files still exist on disk as JSONL files under
~/.codex/sessions.This has happened more than once on the same machine. The conversations appear to be lost from the UI/sidebar, but the JSONL session files are still present locally. In other words, this looks like a local indexing/state/sidebar hydration failure rather than actual data deletion.
Because this failure mode is recurring and highly disruptive, the Desktop app should provide a first-party conversation recovery / reindex capability that can scan the persisted JSONL session files and rebuild the UI-visible conversation index/state.
Environment
OpenAI.Codex 26.820.7780.0%USERPROFILE%\.codex\sessions.jsonlfiles remain on diskWhat issue are you seeing?
After an app update/startup failure/recovery cycle, conversations that previously existed no longer appear in the Desktop sidebar/history.
The important part is that the underlying files are still present under the local Codex session directory. The data is therefore not necessarily deleted; the Desktop UI simply stops loading/indexing it.
This is especially concerning because the UI gives the impression that the conversations have been permanently lost.
This is not the first time this has happened on this machine.
Expected behavior
If valid local session JSONL files exist, the Desktop app should be able to discover and restore them into the conversation list automatically.
At minimum, the app should provide an explicit recovery action such as:
The recovery flow should:
%USERPROFILE%\.codex\sessionsandarchived_sessions.session_index.jsonl/ local SQLite/index state used by Desktop.Why this matters
For long-running software projects, conversations contain implementation context, architectural decisions, debugging history, commands, and reasoning that may span weeks or months.
When the Desktop sidebar suddenly becomes empty or incomplete, users naturally assume their work history has been deleted. If the JSONL source files are still intact, the application should not require users to manually inspect SQLite, edit local state files, identify thread IDs, or reverse engineer internal indexes to recover their own conversations.
A supported recovery function would make the app significantly more resilient to:
Suggested UX
A recovery option could be exposed under something like:
Settings -> Data / Troubleshooting -> Recover local conversationsBefore making changes, it could create a backup of local metadata/index databases, then rebuild derived state from the persisted session JSONL files.
It would also be useful to expose a CLI equivalent, for example conceptually:
Related issues
This appears related to an existing family of reports where threads remain on disk but disappear from Desktop/sidebar/search, including:
Those issues mainly describe visibility/indexing failures. This report specifically asks for a supported, user-facing recovery/reindex mechanism so users can restore conversations from the authoritative local JSONL session files when this class of failure occurs again.
Additional information
The same Windows machine recently experienced a separate startup regression in
26.820.7780.0where the app could not locate/execute the bundled Codex CLI. After recovering the application, the broader concern remains that local conversation history can become detached from the UI even though the JSONL files still exist.The session JSONL files can contain private source code, prompts, local paths, and other sensitive project information, so a recovery mechanism should operate locally and should not require uploading the raw session files to support or GitHub.