[macOS] Unable to download images generated in Chat mode

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

• #35945

Powered by Codex Action

Root cause analysis: image downloads are actively cancelled by the main process

Detailed technical investigation of the download failure — Codex App for Windows, version 26.727.6591.0

Environment
App version: 26.727.6591.0 (Microsoft Store MSIX package, latest)
Platform: Windows 10/11, x64
App package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
Analysis method: extracted the app bundle (resources/app.asar, ~222 MB) and inspected the main-process JavaScript bundle (.vite/build/main-C1YkadXg.js)
Summary
This is not a UI/positioning bug. The download button works fine — the Electron main process actively cancels downloads initiated by the user in the ChatGPT tab. Only downloads performed by the agent through the internal "browser-use" system are allowed to complete.

The code
The download flow is handled by the will-download event of the browser session. The relevant handler (hH) does this:

function hH({ browserSessionRegistry, downloadStore, event, findPageStateForWebContentsId, item, productDownloadsEnabled, webContents }) {
let s = webContents?.id ?? null;
let c = s == null ? null : findPageStateForWebContentsId(s); // internal browser-tab state
let l = item.getURL();
let u = item.getURLChain();
let d = s == null ? null : browserSessionRegistry.consumeAllowedBrowserUseDownload({ url: l, urlChain: u, webContentsId: s });
let f = c?.threadState.isAgentControllingBrowser === true; // is the AGENT controlling this tab?

// RULE 1 — hard cancel:
// Not an agent download AND (no registered browser tab OR agent is controlling the tab)
if (d == null && (c == null || f)) {
event.preventDefault();
item.cancel();
return;
}

// RULE 2 — silent drop:
// Not an agent download AND the product-downloads feature flag is off
if (d == null && !a / productDownloadsEnabled /) return;

// ... otherwise, actually start the download
let p = t.start({ ... }); // saved to getDownloadDirectory() → settings or app.getPath('downloads')
}
What happens when you click "Download" on an image in the ChatGPT tab
The web renderer fetches the image and triggers a browser download on the webContents of the chat window.
The main process receives the will-download event.
consumeAllowedBrowserUseDownload(...) returns null — this allowance is only set up for downloads initiated by the agent via the internal browser tool. A user-initiated click does not produce one.
findPageStateForWebContentsId(...) returns null for the ChatGPT tab (it is not registered as an "internal browser tab" in browserSessionRegistry), so c == null.
RULE 1 hits: event.preventDefault(); item.cancel(); return; — the download is silently cancelled. Nothing appears to happen to the user.
Secondary finding (RULE 2)
Even if RULE 1 did not trigger, the download store defaults to:

this.productDownloadsEnabled = e.productDownloadsEnabled ?? !1 // default: false
The productDownloadsEnabled value is wired from a feature flag (r.bt(r.Ft) at construction). With it off, RULE 2 silently returns without starting the download.

Why images still appear in the browser cache
The image itself is transferred over the network (and thus lands in the Chromium disk cache at %APPDATA%\Codex\web\Codex\Default\Cache\Cache_Data\f_*.png), but the download transaction is cancelled by the main process before it can be saved to disk. This is why the images exist on disk in cache form but the user cannot "download" them.

Suggested fix (for the maintainers)
The cancellation in RULE 1 should only apply when the download is agent-initiated and the agent is not actively controlling the tab. A user-initiated download from a chat webContents should be allowed (or at minimum should fall through to productDownloadsEnabled instead of being hard-cancelled):

// Current (breaks user-initiated downloads from chat tabs):
if (d == null && (c == null || f)) { event.preventDefault(); item.cancel(); return; }

// Suggested:
if (d == null && f) { event.preventDefault(); item.cancel(); return; } // only cancel when the AGENT is in control
This preserves agent-download gating while allowing user-initiated downloads from the ChatGPT tab to proceed to the normal save flow (getDownloadDirectory() → app.getPath('downloads') by default).

Affected surface
Any image / file download initiated by the user from the ChatGPT tab inside the desktop app.
Downloads performed by the agent via browser-use are not affected (they carry the allowedBrowserUseDownload allowance).

Also reproducible on Windows 11 x64 in the unified ChatGPT/Codex desktop app.

Environment

• Microsoft Store package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
• App version: 26.803.5235.0
• Platform: Windows 11 x64

Behavior
Generated images render and open correctly in Chat mode, but clicking the Download button produces no visible response and no file is saved.

Diagnostics

• The Windows Downloads folder is writable by the current user.
• Windows Controlled Folder Access is disabled.
• Restarting the desktop app does not resolve the issue.
• The issue still reproduces after enabling full-device TUN networking in addition to the Windows system proxy.
• App logs contain repeated entries:

``
warning [electron-message-handler] Failed to download image
errorMessage="Failed to fetch ()"
``

• The same log entry was observed repeatedly on 2026-08-02, 08-04, 08-05, 08-07, and 08-09. On 2026-08-09 it occurred repeatedly around 02:55:54–02:56:20Z immediately after Download attempts.

Expected
Clicking Download should save the generated image, or surface an actionable error message.

This indicates the problem is not macOS-only and affects a current Windows build as well. Usernames, local paths, conversation IDs, image content, and raw logs are intentionally omitted.

Same issue on Windows in the current unified ChatGPT/Codex desktop app.

Environment

• App version: 26.814.41407
• Release date shown in app: 2026-08-17
• Platform: Windows
• Subscription: ChatGPT Pro

Behavior
User-initiated downloads from Chat mode silently do nothing. This is not limited to generated images: assistant-generated non-image attachments (for example a .ps1 PowerShell script) also render as downloadable links, but clicking the link produces no visible response and no file is written to the Windows Downloads folder.

This appears to confirm that the affected surface is broader than image generation and includes general Chat-mode file downloads. It also reproduces on a newer Windows build than the prior 26.803.5235.0 report.

Expected
Clicking a generated attachment/download link should save the file, or at minimum surface an actionable error instead of silently cancelling the download.

I no longer have this issue on macOS.

I do have this issue on Windows, and it continues to be an issue: no-active-thread-01a0348d-ae03-7371-98d8-c52491379891

Powered by Codex & OWL
Version 26.803.41515
Released Aug 6, 2026

This button is not allowing anything to be downloaded in the application.

<img width="1126" height="519" alt="Image" src="https://github.com/user-attachments/assets/11f89912-0b91-4db2-a2c2-1aa2686cd11f" />