Previously lost attachment-only conversations remain unrecovered after latest update; needs reindex/recovery path

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

Codex app version

26.601.20914 — released Jun 2, 2026

Platform

  • macOS Tahoe 26.5
  • Apple Silicon MacBook Pro
  • Pro plan

Related issue

This is a follow-up/severity escalation for the attachment-only paste / failed-title / disappearing-thread problem reported in:

  • #25332

Summary

After updating to the latest Codex Desktop version, the conversations that were previously lost because of the large-paste/attached-document title-generation bug have not been automatically restored to the sidebar or accessible conversation history.

The original bug pattern was:

  1. The user pastes a large prompt/document into Codex Desktop.
  2. Codex converts it into an attached document, such as Pasted text.txt.
  3. If the user does not type additional text into the message box, the conversation may fail to get a normal generated summary title.
  4. The conversation remains in a fallback/failed title state such as New chat / New content.
  5. Later, the conversation can disappear from the visible sidebar/history and become unreachable from the UI.

The latest update may have changed some behavior going forward, but it did not restore the conversations that were already affected.

Current behavior after update

After updating to 26.601.20914, my previously lost conversations are still missing. They did not reappear in the project sidebar, the general history list, or any visible recovery location.

I have multiple Codex conversations that became unreachable because of this bug. Updating the app did not recover them.

Expected behavior

Codex should not only fix the bug for future conversations. It also needs a recovery/migration path for users who already lost access to affected conversations.

At minimum, a new version should attempt to:

  • re-index local/backend conversations that failed title generation,
  • restore attachment-only prompt conversations to the sidebar/history,
  • show a stable fallback title such as Untitled chat, New chat, timestamp-based title, or thread ID,
  • expose a recovery page or diagnostic tool for orphaned/unlisted conversations,
  • make conversations discoverable even if title generation failed.

Actual behavior

The previously affected conversations remain inaccessible after the latest update. The user still has no obvious UI path to find or resume those lost threads.

Why this is urgent

This is a serious recoverability issue. Codex conversations often contain development history, debugging context, implementation decisions, and completed work. If a title-generation/indexing bug causes finished conversations to disappear from the UI, users may lose access to important project context.

Fixing only the future behavior is not enough. Users who already encountered the bug need a way to recover their missing conversations. Otherwise, the historical work remains effectively lost.

Request

Please prioritize a recovery/reindex mechanism for conversations affected by the attachment-only paste / failed-title / disappearing-history bug. Existing affected conversations should be restored to the sidebar/history automatically where possible, or Codex should provide a user-facing recovery tool to locate and reopen them.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25332
  • #25463
  • #25574
  • #25084

Powered by Codex Action

PatrickChen-Canton · 1 month ago

Confirmed on current Codex Desktop for Windows.

Environment

  • Codex Desktop: 26.715.4045.0
  • Windows: 10.0.26200.0 (x64)

Deterministic trigger observed in 3 separate user tasks

  1. Start a new project task with a large pasted prompt that Codex converts to an attached pasted-text.txt.
  2. Leave the actual message body under “My request for Codex” empty.
  3. The task runs normally and its rollout/session data remains present and readable, but the project sidebar shows no task and sidebar search may not find it.

Read-only local metadata evidence

  • Affected tasks were user tasks, unarchived, and had intact rollout JSONL files.
  • The affected rows had empty first_user_message and preview values (and has_user_event=0).
  • This was not database corruption: SQLite quick_check returned ok.
  • Sending a normal no-op follow-up through the Codex task API populated the missing summary/preview metadata and immediately restored the task to the recent/sidebar list. Pinning or merely opening the task did not repair discoverability.
  • has_user_event=0 alone does not appear sufficient to hide a task: a visible task can still have that flag while having populated first_user_message/preview. The empty summary/preview fields appear to be the stronger discriminator in this reproduction.

This suggests the attachment-only first-turn ingestion path is not populating the metadata used by Desktop task discovery. Please add a stable fallback summary/title for attachment-only prompts and a startup/update reindex path for existing unlisted tasks with intact rollouts. Until then, typing any non-empty text such as “Please read and execute the attached prompt” alongside the attachment appears to avoid the trigger.

boombx403-byte · 9 days ago

Hi @GGBondBlueWhale, 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.