Bug report: Integrated browser download stops despite “Always allow”

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

26.901.31953

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Bug report: Integrated browser download stops despite “Always allow”

Status: Prepared locally; NOT submitted to OpenAI.

Environment

• Codex desktop app on macOS 26.6.2 (25G83).
• App version/build: not established; please attach from the app's About screen.
• Observed on 2026-09-05; final retest at 09:55 CEST (07:55 UTC).
• Integrated browser controlled through the provided browser automation interface.
• User enabled integrated-browser control.
• Download location: system Downloads folder (screenshot supplied).
• “Ask where downloads should be saved”: off (screenshot supplied).
• User reported changing file-download permission to “Always allow” before the final retest. The effective internal permission state was not independently inspected.

Summary

A normal attachment download from a controlled localhost HTTP server fails to save a file, including after the user selected “Always allow.” A prior attempt appears in the app's download history as “Gestoppt” (Stopped). The final retest closes the HTTP connection while the server writes the PDF response. No new file appears in the system Downloads folder.

Reproduction used in this session

1. Serve a public PDF using a loopback-only HTTP server at http://127.0.0.1:60689/.
2. The index page contains a normal link labeled “Download test PDF” pointing to /download.
3. The endpoint returns HTTP 200 with application/pdf and Content-Disposition: attachment; filename="codex-browser-download-test-20260905.pdf".
4. Open the index page in Codex's integrated browser and activate the link through the browser automation interface.
5. Inspect the download destination and server output.
6. Repeat after selecting “Always allow” for file downloads, keeping the same server, payload, URL, and browser interaction.

The test server was stopped after testing; the loopback URL is not a live public reproduction URL.

Expected

The permitted download completes into the configured system Downloads folder without a Save As prompt. If an additional restriction applies, the app and agent should receive an actionable reason explaining the restriction.

Actual and evidence

• Before the final permission change, the user's download-history screenshot showed “Gestoppt · 9:49,” without an actionable cause visible in the supplied screenshot.
• Both controlled attachment-download attempts ended with a server-side BrokenPipeError while writing the PDF.
• Final retest server output:

2026-09-05T07:55:04.140616+00:00 [DEBUG] DownloadProbe "GET /download HTTP/1.1" 200 -
2026-09-05T07:55:04.147197+00:00 [DEBUG] DownloadProbe.do_GET failed /download
BrokenPipeError: [Errno 32] Broken pipe

• After the final retest, stat and shasum reported that the expected output file did not exist. A separate check found no recently modified regular files at the top level of the Downloads folder during the preceding 15 minutes.
• The browser remained on the test index page, without an error in its exposed page accessibility state. This does not establish that no native dialog existed outside that page.
• The same PDF had loaded successfully through the server's inline-PDF route during the preceding test. This helps distinguish basic PDF delivery from attachment-download completion, but does not identify the root cause.
• Payload: public ST LIS2DW12 datasheet, 3,215,600 bytes.
• Payload SHA-256: 5208623aa91c63a33be0e930518c20f5210c4eb76932350f35369687ae1d0dd5.

Scope and uncertainty

This report does not prove which layer cancels the transfer. BrokenPipeError records the connection closing while the server sends data, not why it closes. Permission propagation, attachment handling, local-HTTP policy, and download-manager behavior remain unverified possibilities. The behavior after a full app restart and the same attachment test on an HTTPS origin have not been tested.

Native Codex-app automation is explicitly blocked for this agent. That restriction was respected; it prevents using native app controls to inspect or resolve a potentially separate dialog. It is not evidence that this restriction caused the transfer failure.

Impact and requested improvement

The agent can navigate to a PDF and trigger a download, but cannot reliably complete and verify the file download under the reported allowed configuration. Please investigate attachment-download cancellation and expose download completion, saved-file path, and actionable cancellation reasons to the browser automation interface.

What steps can reproduce the bug?

Feedback ID: 01a05e9b-c4e5-7110-8afb-8e1ae0b80afb

What is the expected behavior?

No response

Additional information

No response

No source files or tests are named. Start by reproducing the loopback attachment download, then compare behavior after a full app restart and on an HTTPS origin while examining permission propagation, attachment handling, and download-manager behavior. Done means permitted downloads complete in the configured Downloads folder and the automation interface exposes completion, the saved path, or an actionable cancellation reason.