›_ Codex Issues
Codex Issues / #37127

[Web] Generated file downloads fail at /backend-api/estuary/content with ERR_INVALID_RESPONSE

Open 💬 4 comments Opened Aug 5, 2026 by styx-000

What product/version are you using?

ChatGPT Work in the web client at chatgpt.com. Exact frontend build is not exposed.

Subscription

ChatGPT Prolite.

Platform

  • macOS
  • Chrome 150
  • Web client, not the native desktop app

What issue are you seeing?

Generated files are created successfully and rendered as clickable sandbox: links in the assistant response, but clicking the link fails to download or open the file.

Chrome navigates to a URL under:

https://chatgpt.com/backend-api/estuary/content?...

and returns:

This site can’t be reached
ERR_INVALID_RESPONSE

The complete signed URL is intentionally omitted because it contains temporary query parameters.

This reproduced multiple times after the assistant recreated the file with a new filename. The artifact itself was successfully generated and validated in the Work workspace, so the failure appears to be in generated-file delivery through the estuary content endpoint rather than file creation.

Steps to reproduce

  1. Open ChatGPT Work in Chrome on macOS.
  2. Ask ChatGPT to create a downloadable code file, such as a JavaScript file.
  3. Click the generated file link in the assistant response.
  4. Observe that the browser navigates to /backend-api/estuary/content.
  5. The request fails with ERR_INVALID_RESPONSE; the file cannot be opened or downloaded.
  6. Ask the assistant to recreate the file under another filename and repeat. The same error occurs.

Expected behavior

The generated file should download or open successfully when its link is clicked.

Actual behavior

The estuary content request returns an invalid response and Chrome displays ERR_INVALID_RESPONSE.

Additional information

  • Reproduced with more than one newly generated file link in the same conversation.
  • Packaging the artifact as a ZIP is being tested as a workaround.
  • A screenshot of the Chrome error page is available if maintainers need it.
  • No user code or signed download URL is included in this report.

Possibly related, but different surfaces:

  • #34801 — Codex Desktop estuary downloads fail because authentication is not attached.
  • #36933 — Generated file links are missing in the Windows desktop app.

View original on GitHub ↗

4 Comments

ded-furby · 22 days ago

Thanks for the detailed repro. This looks like the generated-file delivery path is not receiving a valid backend session when opening the estuary content URL. Could this also be reproduced in another browser or device, and do the failing responses include a non-200 status plus request id headers in DevTools? If it is web-only, the most likely regression is in URL signing or credential forwarding after work-message link rendering.

styx-000 · 22 days ago

So far, this issue has occurred only with .js files generated by Codex on the web. I reproduced the download failure in Chrome and Safari on macOS, as well as in the ChatGPT desktop and mobile apps. Chrome DevTools shows the request returning 415 Unsupported Media Type.

x-oai-request-id: d57990c0-26ac-42c8-975a-1cad5d813e98

ded-furby · 22 days ago

Got it, thanks for the added repro detail. The 415 plus x-oai-request-id is a strong signal this is likely a backend/content endpoint request-type mismatch rather than broken signing alone. Could you include the response status and request ids for both: (a) the link-generation call that returns the estuary URL and (b) the /backend-api/estuary/content request? If estuary/content is returning 415, this helps confirm whether content-type media-type or credential forwarding is being rejected in this path, especially for .js artifacts. I can then suggest a tight regression check for that window.

styx-000 · 22 days ago

I found both requests in the same HAR capture:

(a) Link-generation request

GET /backend-api/conversation/[redacted]/interpreter/download

  • Status: 200
  • x-oai-request-id: 232d35da-c1ac-4a4d-a282-67befa1bff97
  • Time: 2026-08-05 21:37:12 UTC

The JSON response returned status: "success" and a download_url pointing to /backend-api/estuary/content. It identified the file as codex-js-download-test.js, but both mime_type and file_size_bytes were null.

(b) Content request

GET /backend-api/estuary/content?[redacted]

  • Status: 415 Unsupported Media Type
  • x-oai-request-id: 39c74265-3d5b-4bd2-8299-c7aa8b3d0fd3
  • Time: 2026-08-05 21:37:13 UTC
  • Response body: Unsupported Media Type

The URL requested in (b) exactly matched the download_url returned in (a). The response included the correct Content-Disposition filename, but no Content-Type response header.

Reproduction: In ChatGPT Work on chatgpt.com, using GPT-5.6 Sol with Ultra reasoning and Fast mode, submit:

Create a downloadable JavaScript file named codex-js-download-test.js containing:

console.log("Hello, world!");

Then click the generated file link; the download fails with 415 Unsupported Media Type.