›_ Codex Issues
Codex Issues / #27734

Possible local transcript data loss after Codex Desktop update on Windows

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

Summary

A user on Windows reports that after a recent Codex Desktop update, historical local Codex conversations disappeared from the app. This appears more severe than a sidebar/index visibility issue: old thread metadata remained in local SQLite state, but most corresponding rollout-*.jsonl transcript files were no longer present under ~/.codex/sessions or ~/.codex/archived_sessions when inspected.

This resulted in the user being unable to recover original conversation history. Only partial log fragments remained in logs_2.sqlite, which are not sufficient to reconstruct complete conversations.

Environment

  • Product: Codex Desktop App
  • OS: Windows
  • Codex app version observed from process path: 26.609.3341.0
  • Timezone: Asia/Shanghai
  • Approximate date observed: 2026-06-12

Observed behavior

After the update/restart:

  • Codex Desktop only showed the current/recent thread(s).
  • ~/.codex/session_index.jsonl initially contained only one entry.
  • ~/.codex/state_5.sqlite still contained some older thread metadata rows.
  • Those older rows pointed to historical rollout-*.jsonl paths, but the files were missing (exists=False).
  • ~/.codex/sessions only contained the current session transcript at the time of inspection.
  • ~/.codex/archived_sessions was absent/empty at the time of initial inspection.
  • logs_2.sqlite contained some partial traces/user-input fragments, but not full transcripts.

Expected behavior

Codex Desktop updates should not delete, migrate away without recovery, or orphan local conversation transcript files. If local history indexing changes, the app should preserve original rollout-*.jsonl transcripts and provide a supported repair/reindex path.

Actual behavior

Historical conversations disappeared from the UI, and the underlying transcript files for older sessions appeared to be missing locally. Existing SQLite metadata alone was insufficient to restore the original conversation history.

Impact

This is data-loss severity for users who rely on Codex history as working memory. It causes unrecoverable loss of project context and prior agent work unless the user has external backups.

Related existing issues

This may be related to existing local-history/sidebar/index issues, but the important distinction here is that the original transcript JSONL files were not found locally during inspection, not merely hidden from the UI.

Related examples found:

  • #15349
  • #20340
  • #20506
  • #23193
  • #23979
  • #24364
  • #26886

Notes

No private logs or conversation contents are attached here. The user can be asked through support/feedback flow for sanitized diagnostics if needed. A built-in safe diagnostic/repair command that checks session_index.jsonl, state_5.sqlite, sessions/**/rollout-*.jsonl, archived_sessions, and reports whether transcripts are missing versus merely hidden would help prevent destructive manual recovery attempts.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27340
  • #27545

Powered by Codex Action

bnb0830 · 8 hours ago

I encountered a more severe instance of this issue on Codex Desktop for Windows on 2026-08-28.

A completed presentation-preparation task suddenly disappeared from Codex history. The generated files remain intact, but the entire associated conversation—including its provenance, decisions, and discussion—is gone.

Diagnostics performed:

  • The task is absent from both active and archived task lists.
  • No corresponding task entry survives in the session index, state database, raw session directories, or thread-history database.
  • Logs contain no deliberate thread/archive or deletion event for the missing task. Other legitimately archived tasks do have explicit thread/archive records.
  • Logs contain rollout-reconstruction warnings including “ignored world-state patch without a full snapshot.”
  • Logs also contain thread-history warnings about “dropping turn-scoped item for unknown turn id.”
  • Database migration/backfill state reports completion and no skipped rollouts.
  • The generated filesystem outputs survived because they are stored separately from the task conversation.

Environment:

  • Codex Desktop on Windows
  • Bundled Codex CLI approximately 0.150.0-alpha.8
  • Workspace stored on a UNC-mounted location

This appears to be a task-history persistence, rollout-reconstruction, or indexing failure—not a normal archive operation. Unlike several related reports, the underlying transcript itself cannot be found, so reindexing cannot restore it.

Requested improvements:

  1. Atomic and recoverable task-history persistence.
  2. Automatic reconstruction/reindexing from available rollout data.
  3. Clear warnings when history persistence fails.
  4. A built-in history backup/export and repair command.
  5. Separation of deliberate deletion from corruption, with a recoverable trash or retention period.

This caused permanent loss of important working provenance even though the produced files survived. Please investigate this as potential data loss, not merely a sidebar display problem.