Codex history thread disappears when initial prompt is stored only as pasted-text attachment

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

• #28263
• #28423
• #28559
• #28664

Powered by Codex Action

I hit what appears to be the same bug on Codex Desktop in a project thread.

Broken thread ID: 019ef53f-ecff-7111-93dc-e58102afbdc3
Debug/recovery thread ID: 019ef5cb-f94f-7f70-9fdd-748b7680cac4

This was normal usage, not an intentional attachment-only workflow. I pasted a large kickoff prompt, and Codex automatically transformed it into a pasted-text attachment. The thread then disappeared from normal project history/search even though the raw session JSONL and attachment were still present locally.

Local evidence:

• rollout JSONL existed under ~/.codex/sessions/...
• actual prompt existed under ~/.codex/attachments/.../pasted-text.txt
• state_5.sqlite row existed, archived = 0
• first_user_message was empty
• preview was empty/invalid initially
• read/list APIs could not find it by title or thread ID

Recovery:

• backed up state_5.sqlite
• populated preview for the affected thread
• pinned the thread ID through app metadata
• the thread appeared in pinned
• after unpinning, it correctly moved back into the original project

This seems to confirm that attachment-only first prompts can leave thread display/index metadata empty, making valid local threads disappear from project history.

I can confirm a very similar reproduction on Windows Codex Desktop.

Environment:

• OS: Windows
• Codex Desktop build observed in local config: 26.623.70822
• Codex CLI: 0.142.4
• Local state involved: state_5.sqlite, session_index.jsonl, sessions/**/*.jsonl, attachments/*/pasted-text.txt

Observed behavior:

• Local threads created from large pasted prompts were visible while the app was running.
• After restarting Codex Desktop, affected threads disappeared from the sidebar, thread search, and codex resume picker.
• The rollout JSONL files still existed under ~/.codex/sessions.
• session_index.jsonl still had entries for the affected thread IDs.
• state_5.sqlite still had rows for the affected thread IDs with archived = 0.
• Direct thread reads by ID still worked, so the transcripts were not deleted.

Root-cause evidence from local state:

• Affected JSONL first user messages looked like:

# Files mentioned by the user:

## <large pasted prompt title>: ~/.codex/attachments/<id>/pasted-text.txt

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

## My request for Codex:

• The actual request content existed only in pasted-text.txt.
• ## My request for Codex: was empty.
• The threads table in state_5.sqlite had empty preview and/or first_user_message for affected active threads.
• Codex Desktop appears to filter visible threads through indexes equivalent to WHERE preview <> '', so active unarchived threads with empty preview disappear from normal history surfaces.

Local recovery that made the threads visible again:

• Backed up state_5.sqlite, session_index.jsonl, and affected rollout-*.jsonl files.
• Added a short text summary after ## My request for Codex: in both first-user-message records inside each affected JSONL:
• response_item with payload.type = "message" and role = "user"
• event_msg with payload.type = "user_message"
• Filled title, preview, and first_user_message in state_5.sqlite for those thread IDs.
• After that, codex doctor --summary reported healthy state and thread inventory agreement, and the threads reappeared in the app/search.

Expected behavior:

• Attachment-only / pasted-text-backed prompts should always produce a durable visible history entry.
• Startup reindexing should not clear title/preview to empty when the first user message points to pasted-text.txt.
• If preview is empty, the app should recover a fallback preview/title from attachment metadata, session_index.jsonl, rollout path metadata, or the first attached text file.
• Active unarchived threads should not become unreachable from sidebar/search solely because display metadata is empty.

This affected multiple active local threads, not just one corrupted session.

Confirmed another occurrence, this time while the thread was still actively running in Codex Desktop.

Environment:

• Codex thread cli_version: 0.144.6
• Platform: Linux-hosted local workspace
• Thread source: vscode
• Affected thread ID (redacted): 019f8137…ca3b

Trigger:

1. The initial request was supplied only through a generated pasted-text.txt attachment.
2. The composer body after ## My request for Codex: was blank.
3. The thread initially appeared in the project sidebar while live.
4. After the sidebar refreshed, it disappeared even though the task continued executing.

Sanitized local evidence from state_5.sqlite:

archived = 0
title = "/goal Complete the …"
first_user_message = ""
preview = ""
history_mode = "legacy"
rollout_path = <existing session JSONL>

Additional observations:

• The thread still had a valid row in threads.
• It was present in session_index.jsonl.
• Its rollout JSONL continued growing while the thread was absent from the Desktop sidebar, so this can affect an active thread rather than only completed threads after restart.
• A direct codex://threads/<thread-id> deep link could still open the conversation.
• Neighboring visible project chats had non-empty first_user_message and preview values.

This supports the original diagnosis: attachment-only initial prompts can leave display/index metadata empty, and the sidebar can subsequently omit an otherwise valid, unarchived, active thread. A fallback preview derived from the attached pasted text, or at least its attachment label, would prevent the thread from becoming undiscoverable.

Follow-up on this reproduction:

• Codex Desktop global chat search does not find the affected thread.
• Clicking a rendered Markdown codex://threads/<thread-id> link does not open it; the Desktop renderer displays the link with a generic globe/web treatment instead of routing it to the local thread.
• At the same time, the hidden rollout is still actively appending tool and reasoning events.

This leaves no working in-app discovery path for an active attachment-only thread. The user can confirm that the task is alive from the rollout and external GoalBuddy board, but cannot reopen the conversation from the Desktop sidebar, search, or a rendered deep link.

Confirmed reproduction in the VS Code extension

I can confirm that this defect remains reproducible in the Codex VS Code extension with threads reporting:

cli_version = 0.146.0-alpha.3.1

Controlled test results

I ran three controlled tests in the same workspace.

1. Ordinary inline-text request

• first_user_message length: 454
• preview length: 454
• Result: metadata populated correctly and the thread remained visible

2. Long paste automatically converted to pasted-text.txt

The automatically created attachment was submitted without any accompanying inline text.

• first_user_message length: 0
• preview length: 0
• Result: the thread was created successfully, but its sidebar metadata was empty

3. The same attachment with a typed companion message

Before submitting the attachment, I manually added this inline message:

Run the attached sidebar canary. This typed message is intentionally included to preserve sidebar metadata.

The resulting metadata was:

• first_user_message length: 107
• preview length: 107
• Result: metadata populated correctly and the thread remained visible

---

Attachment-only thread details

The attachment-only thread had the following properties immediately after completing, before VS Code was disconnected or restarted:

source = vscode
thread_source = user
cli_version = 0.146.0-alpha.3.1
first_user_message length = 0
preview length = 0
archived = 0
rollout file = present

The task completed successfully and received a generated title. Its rollout transcript was also present and contained the conversation.

This indicates that the failure occurs while creating the thread’s display or indexing metadata. It is not caused by VS Code closing or reconnecting.

---

VS Code restart test

I separately tested an ordinary inline-text thread using the following sequence:

1. Created and completed the thread.
2. Confirmed that both metadata fields contained 454 characters.
3. Disconnected the VS Code remote session.
4. Closed VS Code completely.
5. Reopened VS Code.
6. Reconnected to the same remote workspace.
7. Inspected the database record again.

The thread remained visible, and both metadata fields still contained their original 454 characters.

This rules out ordinary VS Code closure, remote disconnection, and workspace reconnection as the trigger in this environment.

---

Reproducible workaround

The following workaround prevents the empty-metadata condition:

1. Paste a sufficiently long request so Codex automatically converts it to pasted-text.txt.
2. Before submitting, type a short inline message alongside the attachment.
3. Submit the request normally.

For example:

Please read and complete the attached task. Preserve this message as the task description.

The manually typed companion message is then stored in both first_user_message and preview, preventing the affected thread from being omitted from the sidebar.

---

Recovery test

I also recovered a previously hidden thread without modifying its rollout transcript.

After first backing up state_5.sqlite, I populated only the thread’s empty first_user_message and preview fields using its existing generated title.

The result was:

• The thread immediately returned to the VS Code Codex sidebar.
• The complete conversation remained available.
• The rollout transcript was unchanged.
• SQLite database integrity remained ok.

This demonstrates that the conversation itself had not been deleted. Only the metadata used to display or index the thread was missing.

---

Findings

The controlled tests confirm that:

• The conversation and rollout transcript are not deleted.
• The defect occurs immediately when the initial request contains only an automatically generated pasted-text.txt attachment.
• first_user_message and preview are left empty.
• The affected thread is still active with archived = 0.
• A subsequent sidebar refresh or rebuild can omit the otherwise valid thread.
• Adding ordinary inline companion text prevents the defect.
• Populating the two missing metadata fields restores sidebar visibility.
• Closing and reopening VS Code does not clear correctly populated metadata.

I have observed the same empty-field condition in affected threads created with:

• 0.145.0-alpha.27
• 0.146.0-alpha.3
• 0.146.0-alpha.3.1

The problem therefore appears to span multiple builds and remains reproducible in 0.146.0-alpha.3.1.

---

Privacy note

For privacy and security reasons, I am not uploading:

• The complete state_5.sqlite database
• Production rollout JSONL files
• Original infrastructure-related prompts
• Screenshots containing unrelated infrastructure or session details

The controlled canary contained only harmless inert padding and reproduced the issue reliably.

Additional VS Code occurrence: hidden but directly resumable thread

I can confirm this issue on another VS Code-originated local thread. It is absent from All chats and from an exact-title search, although its rollout remains intact and a direct codex resume <session-id> succeeds.

Environment rechecked on 2026-07-31

• VS Code: 1.130.0 (x64)
• Codex extension: openai.chatgpt 26.727.40816
• Current bundled CLI: codex-cli 0.146.0-alpha.9.2
• Affected thread’s recorded CLI: codex-cli 0.146.0-alpha.3.1
• OS: Ubuntu 26.04 LTS; Linux 7.0.0-28-generic (x86_64)
• Originator/source: codex_vscode / vscode
• Affected local session ID: 019fb3ed-be2c-7053-8d28-3a36952576d3

Observed behavior

• The extension’s All chats view omits the thread.
• Searching for its exact generated title returns no result. The title value is withheld, but it remains non-empty in SQLite.
• Developer: Reload Window did not restore it.
• Direct CLI resume by ID worked, but did not backfill the missing display metadata or make the thread visible.
• The underlying task completed successfully and its durable output remains intact.

Read-only local evidence

The corresponding threads row was inspected using an immutable, read-only SQLite connection; no repair or mutation was performed:

source = vscode
thread_source = user
archived = 0
archived_at = NULL
title_length = 32
first_user_message_length = 0
preview_length = 0
has_user_event = 0
history_mode = legacy
rollout_path = present

The referenced rollout file still exists. All 1,294 JSONL records parse successfully, a structural task_complete event is present, and the rollout contains one user-message event despite the SQLite row reporting has_user_event = 0.

During the first second of thread creation, the extension log emitted this warning 33 times:

codex_rollout::list: state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back

Likely trigger and reproduction

The trigger is likely attachment-only first-message handling, although I have not reduced the /goal variant to a fully deterministic minimal reproduction:

1. Start a local thread in the VS Code extension.
2. Submit a substantive /goal request through an automatically generated pasted-text attachment, without meaningful inline companion text.
3. Allow the thread to receive a generated title and complete normally.
4. Refresh All chats or reload the VS Code window.
5. Search for the exact generated title.
6. Resume the thread directly by ID from the CLI, then check the extension again.

In this occurrence, the initial user event is only an attachment placeholder; the substantive request was attachment-backed.

Expected behavior

An active, unarchived thread with a valid rollout and generated title should remain discoverable regardless of whether its first substantive request was inline or stored in a pasted-text attachment. Thread creation or later reindexing should derive safe display metadata from the attachment metadata or generated title, and direct resume should repair missing index metadata where possible.

Actual behavior

The rollout and completed conversation remain usable by direct ID, but the extension excludes the thread from both history and exact-title search because preview and first_user_message remain empty.

Related reports

• #14812 covers broader VS Code history restoration failures with intact rollout files.
• #20624 covers CLI-resumable sessions that the extension fails to open; this occurrence differs because the thread is omitted entirely.
• #29083 covers another rollout/SQLite projection discrepancy involving a different field and product surface.
• #30640 was closed as completed for a very similar VS Code attachment-wrapper omission, making this useful regression or repair-gap evidence.
• #28263 is relevant to the /goal-first, empty-preview aspect.

Privacy

I am not uploading the database, rollout JSONL, pasted prompt, transcript, full logs, home paths, or screenshots. The evidence above contains only structural counts, redacted metadata, and one minimal diagnostic message.

Corroborating Desktop / Remote reproduction

I independently reproduced this attachment-only initial prompt failure in Codex Desktop on Windows. The task history remained recoverable, but empty first-message metadata caused the active task to disappear from the Desktop project/pinned views and from Remote on mobile.

Because the existing task was not visible on the phone, the same work was started again remotely. That created overlapping agent runs against a week-long project and nearly caused damage. This makes the defect a safety issue, not only a history/sidebar issue: Remote should not omit an active task because its initial prompt was stored only in pasted-text.txt, and Codex should warn before starting a duplicate run for the same project when another run may already exist.

Full sanitized corroborating report and proposed safeguards: https://github.com/openai/codex/issues/34446#issuecomment-5142560117

No private transcript, task identifiers, local paths, database data, or repository details are included here.

I can independently confirm this failure mode on Codex Desktop.

A large initial prompt was automatically converted to pasted-text.txt with no additional inline text. The active, unarchived thread retained its conversation history, but its first_user_message and preview metadata were empty. After restarting Codex Desktop, the thread disappeared from the project and pinned views and was also absent from Remote on mobile, even though it could still be opened through its direct thread reference.

The practical risk is more serious than lost discoverability: because Remote/mobile made the active task appear absent, the same job was started again against the same repository and linked development environment. This created overlapping agent runs and nearly damaged a week-long project.

This makes the defect a safety issue, not only a history/sidebar issue. Attachment-only tasks should always receive a durable fallback title/preview (for example, from pasted-text.txt metadata), and Remote/mobile should not omit an active task solely because inline first-message metadata is empty. It would also be valuable to warn before starting a likely duplicate run for the same project while another run may already be active.

Full sanitized corroborating report and proposed safeguards: #34446, especially https://github.com/openai/codex/issues/34446#issuecomment-5142560117

No private transcript, thread IDs, local paths, SQLite contents, or repository-specific details are included here.

I’m testing Codex Rescue 0.1.0a3 against cases where the local rollout still exists but normal history discovery fails. Your attachment-only first prompt is a useful boundary because the session is physically present while the history/index projection effectively hides it.

Rescue does not mutate session_index.jsonl or SQLite, and it will not fabricate attachment text that is not present in the rollout. I’d like to see whether it can still discover the session and report the missing/ambiguous boundary safely.

If you still have a backup from before the manual repair, would you be willing to try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output only is enough. Please don’t post the raw pasted prompt, attachment, rollout, DBs, credentials, or private paths.

https://github.com/shleder/codex-rescue