Codex App renders ChatGPT-generated Markdown download links as non-clickable text

Open 💬 6 comments Opened Jul 29, 2026 by 497429018
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.721.81911 (5973)

What subscription do you have?

Not provided

What platform is your computer?

macOS 26.5.2 (Build 25F84), Darwin 25.5.0, arm64

What issue are you seeing?

A Markdown file generated in a ChatGPT conversation is downloadable in the ChatGPT web client, but the same conversation does not expose a working file download in the Codex App.

In the web client, the generated .md file is rendered as an interactive file attachment/download component. In the Codex App, the filename or download text is rendered as ordinary text with no link styling and no click behavior. A raw fallback reference such as:

sandbox:/mnt/data/authentik-docker-to-kubernetes-migration-runbook.md

is not resolved into a clickable attachment or download target by the Codex App.

This appears to be a client-side message/attachment rendering regression rather than a file-generation or storage failure, because the same file remains accessible from the web client.

This affects Markdown documents as well as potentially other generated deliverables such as configuration files, scripts, reports, and architecture documents.

Related broader report: #34832 (Issue 2). This report is intentionally focused on the cross-client rendering mismatch and the sandbox:/mnt/data/ attachment reference behavior.

What steps can reproduce the bug?

  1. In ChatGPT, ask the model to generate a downloadable Markdown file.
  2. Wait for the response containing the generated file attachment/download link.
  3. Open the conversation in the ChatGPT web client.
  4. Confirm that the file is displayed as an interactive attachment and can be downloaded.
  5. Open the same conversation in the Codex App.
  6. Observe that the generated filename or sandbox:/mnt/data/... reference is rendered as plain text.
  7. Click the displayed filename/text.
  8. Nothing happens; the file cannot be opened or downloaded from the Codex App.

What is the expected behavior?

Codex App should match the web client behavior:

  • Render generated files as interactive attachment/download components.
  • Resolve sandbox:/mnt/data/... references used by ChatGPT-generated files.
  • Allow users to click and download the generated file directly.
  • Preserve access to file attachments when a conversation is opened across clients.

Additional information

Two comparison screenshots are available and will be attached: one showing the working interactive file attachment in the web client, and one showing the non-clickable plain-text rendering in the Codex App.

Observed on 2026-07-29 (Asia/Shanghai).

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 29 days ago

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

  • #35819
  • #34832

Powered by Codex Action

497429018 · 29 days ago

Thanks — I reviewed both suggested issues.

  • #35819 appears closely related, but it reproduces on Windows 11 in Work mode.
  • #34832 includes the same generated-file download symptom on macOS, but it combines several separate regressions in one report.

This issue provides a focused reproduction on macOS with Codex App 26.721.81911 (5973), specifically for a generated Markdown file and the unresolved sandbox:/mnt/data/... attachment reference. The exact same conversation renders a working interactive file attachment in the web client, while the Codex App renders non-clickable text.

I am keeping this issue open for now so the maintainers can decide whether to consolidate it with #35819 or track the macOS rendering path separately.

497429018 · 29 days ago

Comparison screenshots: the web client renders an interactive file attachment, while the Codex App renders the same generated Markdown file as non-clickable text.

<img width="935" height="470" alt="Image" src="https://github.com/user-attachments/assets/bcd2963f-f661-44c2-a05b-d20072175258" />
<img width="817" height="409" alt="Image" src="https://github.com/user-attachments/assets/b7f4316b-57c8-4781-98f2-1f03e9b22be4" />

JokerNg · 29 days ago

Confirmed on Codex Quick Chat with the same app version, 26.721.81911 (5973), on macOS 15.7.8 / Apple Silicon.

Minimal reproduction: ask Quick Chat to create test.txt containing hello. Codex Quick Chat renders only plain text such as 下载 test.txt, with no clickable attachment or download action. Opening the same cloud conversation in ChatGPT Web shows a working downloadable attachment.

I filed #36064 before the duplicate bot surfaced this report; I am closing it as a duplicate of this issue.

497429018 · 29 days ago

Retested on macOS on 2026-07-30. The generated Markdown file link is now rendered as a clickable link in the ChatGPT/Codex app, and the file opens successfully. Reporter verification passed, so I’m closing this issue as resolved/no longer reproducible.

497429018 · 29 days ago

Correction: the previous verification was invalid because it tested a local filesystem link, not a ChatGPT-generated remote attachment in the macOS app's Chat mode. The issue is still reproducible and this report has been reopened.

The mode distinction is important:

  • In Codex/workspace-oriented modes, generated text files can generally be written directly to the local filesystem, so a local file link can work.
  • In the macOS ChatGPT/Codex app's Chat mode, the model cannot write the generated Markdown file directly into the user's local workspace.
  • Chat mode therefore depends on the remote generated-file attachment/download mechanism.
  • The web client renders that .md output as a clickable attachment card/download link.
  • The macOS app's Chat mode renders only download text/the filename, with no working hyperlink or attachment card, so the user has neither a locally written file nor a usable remote download.

Fresh cross-client screenshots from 2026-07-30 confirm the mismatch. Apologies for the premature closure.