Unified ChatGPT/Codex macOS app omits generated file attachments visible on the web

Open 💬 8 comments Opened Jul 10, 2026 by sichgeis

What version of the Codex App are you using (From “About Codex” dialog)?

Exact build not captured. This was reproduced in the newly released unified ChatGPT/Codex macOS app on July 10, 2026.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS. The exact OS build and Mac architecture were not captured.

What issue are you seeing?

The unified ChatGPT/Codex macOS application does not display generated downloadable file attachments in assistant responses.

The same conversation, opened through chatgpt.com with the same account, correctly displays all generated files and allows them to be downloaded. This appears to be a native-client attachment rendering or message-hydration bug, not a file-generation failure.

In the macOS app:

The assistant response text is visible.
The bullet labels describing the generated documents are visible.
The generated files themselves are not represented.
There is no Download file button.
There are no file-type icons.
The filenames are not clickable.
There is no indication that attachments exist.

In the web application:

The same assistant response contains a Download file button for the ZIP archive.
Generated Markdown and JSON documents appear with file icons.
The filenames are clickable and downloadable.

The affected response contained a ZIP archive, several Markdown documents, and a JSON manifest.

What steps can reproduce the bug?

Open a conversation in the unified ChatGPT/Codex macOS application.
Ask ChatGPT to create downloadable files, such as a ZIP archive, Markdown documents, and a JSON manifest.
Have the assistant present links to the generated files in its response.
Observe the response in the macOS application.
Open the same conversation on chatgpt.com using the same account.
Compare the same assistant message in both clients.

What is the expected behavior?

Generated file attachments associated with an assistant message should be displayed consistently across the web application and the unified macOS application.

The macOS application should show the same attachment cards, filenames, file-type icons, and download controls as the web application.

Actual behavior

The macOS application renders the surrounding assistant text but omits the generated-file controls and attachment links entirely. The files are visible and downloadable in the web application.

Evidence

Two screenshots of the same conversation provide an A/B comparison:

Unified ChatGPT/Codex macOS app: the bullet labels are visible, but there is no download button, file icon, clickable filename, or attachment card.
ChatGPT web app: the same response shows a Download file button and clickable Markdown and JSON file attachments.

The screenshots demonstrate that the artifacts exist on the backend and that only the macOS client fails to expose them.

Workaround

Open the same conversation on chatgpt.com and download the generated files through the web interface.

Suggested investigation

Please compare the message content blocks and attachment metadata received by the web client and the unified macOS client for the same assistant message. Possible areas to inspect include:

generated-file attachment content blocks being dropped during native-client message hydration;
file-link or artifact-card nodes being flattened into plain text;
unsupported handling of ChatGPT generated-file links by the unified desktop Markdown renderer;
attachment metadata being filtered when a normal ChatGPT conversation is displayed in the Codex-style conversation window.

Related issues

#27348 — local file references in assistant responses are not clickable in the macOS Codex app
#31862 — desktop UX regressions in the unified ChatGPT/Codex app
#25202 — linked artifacts do not render in another ChatGPT client

View original on GitHub ↗

8 Comments

derekste · 1 month ago

Additional sanitized confirmation of this behavior:

An assistant generated a PDF and returned an in-message Markdown link whose target used the sandbox:/mnt/data/... form.
In the unified macOS app, the link text was visible in the chat response but was not clickable, and no usable download control was presented.
The generated file had not failed or disappeared: opening the same conversation in the web interface exposed the file and allowed it to be downloaded.

Expected behavior: generated-file links and download controls should remain actionable in the macOS app whenever the same artifact is available from the web client.

No conversation link, screenshot, original filename, or document content is included because the source conversation contained private material.

nayulkoo · 1 month ago

I can reproduce this issue as well. In the integrated Codex + ChatGPT app, uploaded files and model-generated files are not rendered correctly in the ChatGPT conversation window.
I confirmed that both work as expected in the ChatGPT mobile app and web browser, where the files are rendered and downloadable.

GoodthingsHappenToMe · 1 month ago

Additional reproduction from another user, matching this issue.

Environment observed locally:

App: ChatGPT/Codex macOS app 26.707.41301 (CFBundleVersion 5103)
OS: macOS 26.4.1 (25E253), Apple Silicon (arm64)
Subscription visible in UI: Pro
Date observed: 2026-07-11 / 2026-07-12 Asia/Singapore

Observed behavior:

An assistant message says it generated a downloadable PDF and refers to a download link/file.
The macOS app renders only the surrounding text; no attachment card, file icon, clickable filename, or download control is visible.
A later assistant response reports the PDF exists in the runtime at a path similar to /path/to/generated_file.pdf and gives size/page info, but the client still exposes no usable download link.

Why this seems client-side:

The model/runtime appears to have produced the PDF successfully.
The failure is in presenting the generated file/attachment in the desktop UI, consistent with the issue title.

Expected:

Generated files should appear as attachment cards or links in the macOS app, or the app should provide a clear fallback/open/download action.

Workaround:

Open the same conversation in the web app and download from there, if the attachment is visible on web.

I am intentionally not attaching the user's screenshot here because it contains personal sidebar/account information. I have also generalized the runtime file path and filename to avoid exposing user-specific conversation details.

abcjhby2871 · 1 month ago

Additional reproduction: the problem is not limited to attachment rendering or downloading—the Codex agent also cannot access or read the affected chat attachments.

Environment:

App: Codex Desktop 26.715.31925
Platform: macOS, Apple Silicon (arm64)

Observed behavior:

A file is attached to, or generated inside, a ChatGPT conversation in the unified Codex app.
The desktop client does not expose a usable attachment card or download action.
When Codex is asked to inspect, summarize, or otherwise use that attachment in the same conversation, it cannot resolve or read the file either.

This means the attachment metadata/content appears unavailable not only to the desktop renderer but also to the Codex execution context. The issue therefore blocks both user workflows:

the user cannot download/open the attachment;
Codex cannot consume the attachment for follow-up work.

Expected behavior:

Chat attachments should be rendered with working open/download controls;
attachments associated with the current conversation should also be materialized or exposed as readable resources to Codex, with a clear error if access cannot be granted.

Please check whether attachment references are being dropped or left unresolved when ChatGPT conversations are hydrated into the unified Codex desktop app and agent context.

Jaylekehu · 1 month ago

I can reproduce the affected desktop behavior in the current unified app.

Environment:

App version: 26.715.72359
macOS 26.5.1 (build 25F80), Apple silicon (arm64)
Surface: Chat mode

Observed behavior: files generated by the assistant cannot be downloaded from the desktop app. The generated-file attachment/download flow is unavailable or nonfunctional, matching the user-facing result described in this issue.

This is still reproducible as of July 23, 2026. I am not attaching conversation contents or raw logs publicly for privacy.

cherryhhhhbcdg · 1 month ago

Windows confirmation (Codex Desktop MSIX OpenAI.Codex 26.721.4979.0): this reproduces with generated .docx, .xlsx, and .pdf files.

In desktop Chat, the response is flattened to ordinary text such as 下载 Word 文件：<name>.docx; no file card, icon, or clickable download control is rendered.
Opening the same conversation in ChatGPT Web with the same account shows the normal downloadable attachment card, so artifact creation/storage is successful.
The desktop app is already at the newest Microsoft Store version (winget upgrade reports no newer package). Its local OwlDownloads feature is enabled.
Desktop logs contain no serialized attachment/artifact payload for the affected message, so the useful next instrumentation point is message hydration immediately before the Markdown renderer: log message.attachments, message.files, message.artifacts, and message.metadata, then compare the web and desktop payloads for the same response.

This expands the issue beyond macOS and suggests a shared unified-desktop hydration/renderer regression. Proposed guardrail: normalize attachments from all four fields, infer MIME type from filename if necessary, and render attachment cards before Markdown fallback so file-link text cannot replace a valid file object.

prkbll · 1 month ago

Windows A/B reproduction with a generated Markdown file. This matches the issue, but the Windows client exposes a particularly misleading fallback: it renders the filename inside a plain text code block instead of an attachment card.

Environment

Windows 11
Unified ChatGPT/Codex desktop app, Microsoft Store package OpenAI.Codex 26.721.4979.0 / app release 26.721.41059
Same account and same conversation compared in desktop and at chatgpt.com

Reproduction

Ask ChatGPT to generate and attach a Markdown file.
Open the assistant response in the Windows desktop app.
Open the same conversation in ChatGPT Web.

Actual result

Windows desktop shows the filename FINAL-ocr-sqlite-accounting-document-system-handoff-2026-07-28.md only as text inside a code block.
There is no attachment card, clickable filename, preview, or download action.
The surrounding assistant text says the file is attached, making the desktop rendering look like a successful attachment even though it cannot be opened.

Control / expected result

The same message on chatgpt.com shows a file icon, clickable filename, document preview, and download control.
This confirms that artifact generation and backend storage succeeded; the failure is in Windows desktop message hydration/rendering.

The screenshots below are the same generated artifact: web first (working), Windows desktop second (broken).

ChatGPT Web (working):

Windows desktop (broken):

harryshawk · 25 days ago

Additional reproduction from the unified ChatGPT/Codex macOS app.

Reference: no-active-thread-019fc5cf-9f19-74e2-aafe-a4633e496e1b

Observed behavior

The assistant generated two files in the sandbox and repeatedly returned valid Markdown links using the sandbox:/mnt/data/... scheme. In the macOS app, the visible response showed only the link labels as plain text, for example:

Download the PDF
Download the editable PowerPoint

No hyperlink, attachment card, file icon, or download control appeared. The assistant incorrectly believed the links had rendered because the Markdown source was valid.

The exact generated paths were:

sandbox:/mnt/data/Sensei_Cloud_Apps_Master_Integrated_Campaign_Plan_8.5x11.pdf
sandbox:/mnt/data/Sensei_Cloud_Apps_Master_Integrated_Campaign_Plan_8.5x11.pptx

Opening the same conversation in the web browser caused the links to appear and work normally.

Expected behavior

The macOS app should render sandbox: file links and generated-file attachments the same way as the web client, with clickable filenames or download controls.

Actual behavior

The macOS renderer strips or suppresses the link target and displays only the anchor text. This makes valid generated files inaccessible from the native app even though they remain available in the same conversation on the web.

This looks consistent with the issue described here and provides a second concrete case involving PDF and PowerPoint artifacts.