Repository navigation
Windows Desktop: conversations disappear from UI even though JSONL sessions still exist; add first-party recovery/reindex tool #40779
Description
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
.jsonlfiles 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\sessionsandarchived_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:
- Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540 - Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk
- Codex Desktop project sidebar hides older workspace conversations despite existing local thread data #20833 - Desktop project sidebar hides older workspace conversations despite existing local thread data
- Codex Desktop silently hides project conversations outside the global recent-50 window #21128 - Desktop silently hides project conversations outside the recent window
- Codex Desktop 26.519.22136: local project conversation history missing after update, threads still exist in state_5.sqlite #23979 - local project conversation history missing after update while local data still exists
- Chat history disappeared from sidebar after app update #26236 - chat history disappeared from sidebar after app update
- Codex Desktop hides active local threads from sidebar/search while state_5.sqlite still marks them unarchived #27159 - active local threads hidden from sidebar/search while local state remains intact
- Codex Desktop: recent local project threads are missing from sidebar/search although session_index and read_thread can load them #30385 - local project threads missing from sidebar/search although session index and direct reads work
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.
Activity
github-actions commentedon Aug 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
shita0809 commentedon Aug 27, 2026
Additional Windows repro / diagnostic evidence (2026-08-27):
This is recurring on my machine and the underlying conversation data is still present, but Desktop stops surfacing part of it.
Observed state during the latest occurrence:
%USERPROFILE%\.codex\sessions: 178 session/rollout files found%USERPROFILE%\.codex\session_index.jsonl: only 95 entriessession_index.jsonllast write time: 09:41 local timerollout-*.jsonlfiles continued to be created/updated after 11:00–12:00, so session persistence continued while the index stopped advancing.codex-global-state.jsoncontinued updating later (15:13 local time)CODEX_HOMEis unset (default location)CODEX_CLI_PATHpoints to the bundled official Codex Desktop executable under%LOCALAPPDATA%\OpenAI\Codex\bin\...\codex.exeRecovery test:
sessions,archived_sessions,session_index.jsonl,.codex-global-state.json, and the SQLite state files.session_index.jsonland restart Codex Desktop.session_index.jsonlfrom the existing 178 local session JSONL files;Test-Pathremains false.This strongly suggests
session_index.jsonl/ Desktop thread-list state can stop updating independently of the durable session files, and there is currently no automatic recovery path.The issue is highly disruptive for long-running coding projects because the conversation still exists and can retain context, but users repeatedly lose the ability to find it from the normal project/sidebar history.
A first-party local repair/reindex action would be very valuable. Ideally it should rescan
sessions/archived_sessions, reconcile thread metadata with SQLite/global state, and restore sidebar/project visibility without requiring manual state-file edits.I have not attached raw JSONL/SQLite files because they contain private code, prompts, project paths, and conversation content. I can provide sanitized counts/schema/log excerpts if useful.
SenlerBot commentedon Aug 30, 2026
Reproduction update — still occurring on a newer Windows build
This issue reproduced again on 2026-08-30 during active project work.
Environment:
26.825.5331.0codex-cli 0.130.0-alpha.5Microsoft Windows NT 10.0.26200.0, x64Observed behavior:
Expected behavior:
No conversation content, project paths, account identifiers, or session/thread IDs are included in this public report. Redacted diagnostics can be provided if maintainers specify what is useful.
Kenawanewan commentedon Aug 30, 2026
Additional Windows reproduction from ChatGPT Work (2026-08-30):
Expected: a recent, non-archived Work conversation should remain discoverable. If local session data still exists, Desktop should automatically rebuild the index or expose a supported “Recover/reindex conversations” action.
This recurrence has a high productivity impact and makes the app appear to have deleted work even when the likely failure is index/sidebar hydration.
SeruousMax commentedon Aug 31, 2026
I can confirm that this is still reproducible on a newer Windows build, and in this occurrence it affected the currently active long-running task rather than only old sidebar entries.
Environment:
26.825.6671.00.146.0Observed behavior:
Sanitized local evidence collected immediately after the incident:
rollout-*.jsonlstill existed under%USERPROFILE%\.codex\sessions\....missing_candidate=0andpending_observed_title=0; its recency/update metadata continued to advance.This narrows the failure mode to Desktop hydration/rendering/index reconciliation for a live, long/compacted thread. The persisted transcript and catalog entry can both be healthy while the UI makes the conversation appear lost.
Expected behavior:
No transcript contents, private project paths, account identifiers, or raw logs are attached. Sanitized diagnostics can be provided if maintainers specify the exact fields needed.
SenlerBot commentedon Sep 1, 2026
Reproduction update — 2026-09-01
This occurred again on the same Windows machine, this time during an active long-running WSL project task.
Environment:
26.825.6671.00.130.0-alpha.510.0.26200.9168Observed behavior:
Sanitized local evidence collected after the incident:
rollout-*.jsonlstill exists under%USERPROFILE%\.codex\sessions\....session_index.jsonlhad not been modified since 2026-08-31 15:45 local time, while the active rollout continued updating on 2026-09-01.This is consistent with a Desktop sidebar/index hydration failure rather than transcript loss. An active task should remain visible, and Desktop should reconcile or rebuild its derived index from the intact rollout data automatically.
No conversation contents, project paths, account identifiers, thread IDs, tokens, or raw logs are included.
Divinicus1st commentedon Sep 3, 2026
I just hit what looks like the same failure on Windows, with a newer build.
Environment:
26.901.20858Symptom:
Read-only local evidence from
%USERPROFILE%\.codex:sessions: 28 JSONL filesarchived_sessions: 8 JSONL filessession_index.jsonl: 6,189 bytesstate_5.sqlite: 573,440 bytes, with a ~4.17 MB WALthread_history_1.sqlite: 164,982,784 bytes, with a ~602 KB WAL.codex-global-state.json: 1,109,550 bytes, with an equally sized.bakI have not attempted to reset/rebuild/delete any
.codexstate after noticing the problem; the inspection above was read-only.This strongly looks like the conversation/sidebar index or hydration becoming detached from the persisted local sessions rather than actual transcript deletion. A first-party “reindex/recover local conversations” path would be extremely useful here, especially because the UI currently makes this look like complete history loss.