Codex Desktop Sources attachment becomes unpreviewable when original local file path disappears

What version of the Codex App are you using?

26.707.91948 (build 5440), bundle identifier com.openai.codex

Subscription

ChatGPT Pro

Platform

macOS 26.5.2 (25F84), arm64, Mac14,3

What happened?

A PDF added to a conversation appears in the right-hand Sources panel with a PDF icon, its filename, the original absolute Desktop path, and the text “Attached to the conversation.”

Later, clicking that same source opens a blank viewer with:

Couldn't load this preview

The PDF itself is valid and renders normally in macOS and Poppler. The original Desktop copy no longer existed, but byte-identical/related copies were still available elsewhere.

Local inspection of the durable rollout record found that the user message contained only one input_text item with a “Files mentioned by the user” absolute path. There was no durable attachment object, internal file ID, copied binary, or attachment event associated with the message.

This makes the UI promise misleading: it says the file is “Attached to the conversation,” but the source behaves like a fragile link to the original filesystem location.

No contract contents or confidential PDF have been uploaded to this issue.

Reproduction

1. In Codex Desktop, attach/reference a local PDF from /Users/<user>/Desktop/contract.pdf.
2. Send the prompt and confirm the PDF appears under Sources as “Attached to the conversation.”
3. Move or delete the original Desktop file after the turn is stored.
4. Open the Sources panel and click the PDF.
5. Observe the blank viewer and “Couldn't load this preview.”

Actual behavior

• The Sources card remains visible and claims the file is attached.
• Preview fails after the original absolute path disappears.
• The durable conversation record contains the path as text but no durable attachment reference.
• The UI provides no “Locate file,” “Open containing folder,” “Replace source,” or useful explanation that the original local file is missing.

Expected behavior

One of these models should be implemented consistently:

1. Persisted attachment: copy/import the attachment into a conversation-owned immutable store and preview it independently of the original path; or
2. Linked local file: label it explicitly as a filesystem link, detect missing paths, and provide Locate/Relink/Open-original-location controls.

If a source is represented as “Attached to the conversation,” moving/deleting the original should not silently make it unusable.

Local evidence / workaround

• The original source path was confirmed missing.
• A known exact unsigned original was recovered from the local mail attachment store and restored to the same Desktop pathname.
• SHA-256 matched before/after restoration.
• The recovered PDF is six pages, PDF 1.7, unencrypted, and renders correctly.
• Restoring the path is a workaround, but it should not be required for a conversation attachment.

The frontend did not emit a useful preview/ENOENT diagnostic into the local Codex core log during the failed preview, which also makes diagnosis harder.

Related

• #20552 reported stale floating-panel entries becoming unclickable when files are moved/deleted and intermittent PDF/DOC/PPT preview failures. That issue is closed and primarily tracked file-tree toggle behavior; this report isolates attachment persistence and misleading Sources semantics.