Codex Desktop hides attachment-only prompt threads after restart when message body is empty

Summary

Codex Desktop on Windows can create a conversation that is still present on disk and in state_5.sqlite, but disappears from the sidebar/search after restarting the app.

The reproducible trigger appears to be:

1. Paste a large prompt into Codex Desktop.
2. Codex converts the pasted content into an attached pasted-text.txt file.
3. Send the message without typing any additional text in the composer.
4. Let the task complete.
5. Restart Codex Desktop.
6. The conversation no longer appears in the sidebar / recent threads / search, even though its rollout JSONL and threads DB row still exist.

This is a data-loss-class UX issue, but the data is not actually deleted. The local thread is recoverable by ID / rollout file.

Environment

• App: Codex Desktop on Windows
• OS: Windows 11 Pro, version 10.0.26200, x64
• Codex Desktop package observed: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
• Thread cli_version: 0.136.0-alpha.2
• Model: gpt-5.5
• Thread type: projectless threads

Reproduced twice

Two affected local thread IDs reproduced the same pattern:

019e9244-3ff0-71b2-b4e3-109435c9993a
019e924f-8d28-7a63-9276-d762944056fb

Both rollout files exist locally under:

C:\Users\<USER>\.codex\sessions\2026\06\04\rollout-...-<thread-id>.jsonl

Both state_5.sqlite rows exist and are not archived.

Important local evidence

For the clean repro thread 019e924f-8d28-7a63-9276-d762944056fb, state_5.sqlite contains the thread, but all display/index fields are empty:

{
  "id": "019e924f-8d28-7a63-9276-d762944056fb",
  "rollout_path": "C:\\Users\\<USER>\\.codex\\sessions\\2026\\06\\04\\rollout-2026-06-04T19-05-47-019e924f-8d28-7a63-9276-d762944056fb.jsonl",
  "cwd": "\\\\?\\C:\\Users\\<USER>\\Documents\\Codex\\2026-06-04\\files-mentioned-by-the-user-txt-2",
  "title": "",
  "first_user_message": "",
  "preview": "",
  "archived": 0,
  "source": "vscode",
  "thread_source": "user",
  "cli_version": "0.136.0-alpha.2",
  "model": "gpt-5.5",
  "reasoning_effort": "xhigh"
}

session_index.jsonl did not contain the affected clean repro thread ID (019e924f...), while normal text-message threads do appear there.

The first real user message in the rollout file has this shape:

# Files mentioned by the user:

## 已粘贴的文本.txt: C:\Users\<USER>\.codex\attachments\...\pasted-text.txt

The attached pasted text file(s) contain the user's request. Read and act on that content.

## My request for Codex:

There is no text after ## My request for Codex:. The prompt content exists only in the attached text file.

A normal comparison thread created with typed text has non-empty fields:

{
  "title": "怎么codex重启后019e9244-...的对话丢失了",
  "first_user_message": "怎么codex重启后019e9244-...的对话丢失了",
  "preview": "怎么codex重启后019e9244-...的对话丢失了"
}

Actual behavior

• After restart, the affected conversation is missing from the sidebar/recent list/search.
• The rollout JSONL file still exists and is readable.
• The threads row still exists in state_5.sqlite and archived = 0.
• The thread can be read directly by ID, but it is not discoverable through the normal UI list.
• The clean repro thread has empty title, first_user_message, and preview, and no session_index.jsonl entry.

Expected behavior

Attachment-only first messages should still produce a discoverable thread.

At minimum, Codex Desktop should:

1. Generate a fallback title/preview from the attachment metadata, e.g. 已粘贴的文本.txt / pasted-text.txt, when the composer text is empty.
2. Insert the thread into session_index.jsonl even if first_user_message is empty.
3. Allow sidebar/search to discover active, unarchived threads whose rollout file exists, even if title/preview are empty.
4. Rebuild missing display/index metadata from rollout files during startup or via a repair command.

Workaround that partially confirms the diagnosis

Manually updating the affected thread's threads.title, threads.preview, and threads.first_user_message, plus adding a matching session_index.jsonl entry, makes the thread readable again by ID with a proper title. However, the running sidebar/list appears to keep an in-memory cache and may not immediately refresh until restart.

This suggests the missing UI entry is caused by empty display/index metadata, not missing conversation data.

Related issues

This seems related to, but more specific than:

• #24178
• #25084

Those cover broader history/sidebar discovery failures. This report is the narrower attachment-only / empty composer body case with two local reproductions.

Privacy note

I am intentionally not attaching raw rollout files, logs_2.sqlite, or the pasted prompt content because they may contain private data. The paths above are redacted and the included snippets only show the generic attachment-wrapper message shape.