Codex Desktop thread disappears from project list when initial user request is stored in pasted-text attachment

Summary

In Codex Desktop on Windows, a project conversation can disappear from the project conversation list after the local thread index is rebuilt if the first substantive user request was stored in a pasted-text.txt attachment and the visible first user message body contains little or no actual request text.

The raw session JSONL and attachment files still exist on disk, so this appears to be a local indexing/listing bug rather than real data deletion. From the user's point of view, however, it looks like conversation history vanished.

Environment

• Product: Codex Desktop
• OS: Windows
• Observed Codex version in session metadata: 0.140.0-alpha.2
• Local storage involved:
• %USERPROFILE%\.codex\sessions\YYYY\MM\DD\rollout-<thread-id>.jsonl
• %USERPROFILE%\.codex\attachments\<attachment-id>\pasted-text.txt
• %USERPROFILE%\.codex\state_5.sqlite

Reproduction Pattern

1. Open a local project in Codex Desktop on Windows.
2. Start a new conversation where the substantive user request is supplied as pasted text / attachment, producing a pasted-text.txt file.
3. The visible first user message body contains only a file mention / wrapper text and does not contain the real request.
4. Let Codex complete the work.
5. Restart Codex Desktop or otherwise cause the local thread index to rebuild.
6. Open the same project conversation list.

Expected Behavior

The conversation should remain visible and searchable in the project conversation list.

If the indexer needs a first_user_message or preview, it should derive one from the pasted-text attachment, from the thread title, or from another stable fallback instead of treating the thread as empty.

Actual Behavior

The conversation disappears from the project conversation list even though the raw session JSONL still exists on disk.

Local inspection showed the affected thread row in state_5.sqlite had an empty first_user_message and an empty or unstable preview. A manual local patch made the thread visible temporarily, but after another index rebuild the issue returned, which suggests the indexer recomputed the metadata from the JSONL and again failed to account for the attachment content.

Impact

This creates a serious trust problem. Users can reasonably believe that Codex deleted project conversation history, even though the underlying raw session file may still exist.

It is especially concerning for longer project-building conversations where the conversation itself is part of the user's work record.

Sanitized Evidence From Local Investigation

• The original session file remained present under %USERPROFILE%\.codex\sessions\....
• The actual first request was present in %USERPROFILE%\.codex\attachments\<attachment-id>\pasted-text.txt.
• The thread title was present, but the original non-English title is omitted here for privacy.
• The project files created during the conversation still existed.
• The affected database row was unarchived, but first_user_message length was 0.
• A fork/recovery attempt briefly made duplicate threads appear, but one disappeared again after indexing state changed.

Suggested Fix

When indexing or rebuilding thread metadata:

• Treat first-turn pasted-text attachments as candidate user message content.
• Avoid hiding unarchived threads solely because first_user_message is empty.
• Add a fallback preview derived from the thread title, attachment filename/content summary, or first assistant response.
• Add a regression test for attachment-only first user requests.