[Shared Codex → ChatGPT] Unreadable source is replaced with unrelated Library files and misattributed

What issue are you seeing?

In a persisted ChatGPT conversation, I asked the assistant to analyze only a specific Shared Codex thread. The requested transcript was not retrieved or quoted. Instead, the assistant searched both the current conversation and the account-level Library, opened historical images from an unrelated earlier task, and treated those images as evidence from the requested Codex thread.

The Files search query already contained a detailed travel-product hypothesis before any matching Library image was opened. The returned file metadata identified the images as surface: library. The final answer then attributed that unrelated travel material to the Shared Codex source.

I subsequently revalidated the actual Codex source using the desktop app's thread reader and its canonical local session log:

• the thread contained the requested Modore work;
• the source transcript contained no travel-product content;
• the unrelated images were not part of that source.

This report is about provenance substitution after source retrieval failed. It does not claim cross-account access.

What steps can reproduce the bug?

The persisted incident followed this sequence:

1. Create a Codex thread whose subject is unrelated to travel and share it.
2. In a new ChatGPT conversation, provide the Shared Codex URL and ask the assistant to analyze that thread.
3. Check whether the assistant can quote or otherwise verify text from the requested source.
4. Inspect the visible Files search trace and the provenance metadata of any returned files.
5. Compare the answer's cited material with the actual Codex transcript.

Observed in this incident:

• the requested transcript was not quoted;
• Files search broadened to the account Library without the user requesting that fallback;
• the search query contained an unrelated travel-product premise before image inspection;
• returned images were marked surface: library and came from a prior task;
• the final answer described those files as material from the requested Codex thread;
• direct validation of the actual source confirmed that the attributed travel content was absent.

This was observed once in a persisted conversation. I have not established that it reproduces deterministically, so this report does not present an unexecuted synthetic procedure as a confirmed reproduction.

What is the expected behavior?

• Retrieve and quote the requested Shared Codex transcript with verifiable provenance.
• If the requested source cannot be retrieved, fail closed and report that limitation.
• Do not silently broaden retrieval to unrelated account Library files.
• Do not attribute a file to the requested source unless its provenance is verified.
• Clearly identify any fallback source and ask before substituting a different source scope.

Additional information

• Date observed and source revalidated: 2026-09-04 KST
• Desktop app: 26.901.20858 (build 7658)
• Desktop OS: Darwin 27.0.0 arm64
• The origin of the travel premise in the pre-image search query remains unknown.
• Private share URLs, conversation IDs, local paths, account identifiers, and raw Library metadata are omitted from this public report.
• #41606 is not the same reproduction: that report concerns Codex Desktop scanning ~/.codex/generated_images; this incident occurred in ChatGPT Files/Library retrieval after a Shared Codex source could not be read.

No implementation file or test is identified. Start by reproducing the Shared Codex URL flow in ChatGPT and inspect the Files/Library search trace and provenance metadata, then compare the result with the desktop thread reader and canonical local session log. Done means the requested source is quoted with verified provenance, or retrieval fails closed without substituting unrelated Library files.