[Bug] Codex Desktop in-app Browser stalls at 100% for several attachment extensions on Windows

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

Codex Desktop 26.721.4979.0

What subscription do you have?

ChatGPT Pro (5x)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop's built-in Browser receives the complete HTTP response body but never finalizes downloads for several filename extensions. The download panel reaches 100% and remains at almost finished indefinitely.

A minimal extension probe produced this matrix:

| Extension | Result in Codex built-in Browser |
|---|---|
| .json | Completed |
| .midi | Completed |
| .mid | Stuck at 100% / almost finished |
| .foo | Stuck at 100% / almost finished |
| .xml | Stuck at 100% / almost finished |
| .musicxml | Stuck at 100% / almost finished |
| .zip | Stuck at 100% / almost finished |
| .mxl | Stuck at 100% / almost finished |

The .json, .midi, .mid, .foo, .xml, and .musicxml probes all use the identical one-byte body x, with Content-Type: application/octet-stream and exact Content-Length: 1. The .zip and .mxl probes use the same valid 101-byte ZIP body.

The local test server logs completion for every request with matching sent and declared byte counts. The same endpoint and attachments complete normally in Microsoft Edge. This isolates the behavior to the Codex built-in Browser download finalization path.

What steps can reproduce the bug?

1. Start a local HTTP server and expose links under /download-probe/{extension}.
2. For json, midi, mid, foo, xml, and musicxml, return exactly:

``text
Body: x
Content-Type: application/octet-stream
Content-Length: 1
Content-Disposition: attachment; filename="probe.{extension}"
Cache-Control: no-store
Connection: close
``

1. For zip and mxl, return the same minimal valid ZIP body with the corresponding final filename.
2. Open the probe page in Codex Desktop's built-in Browser on Windows.
3. Click each download link and inspect the download panel.
4. Observe that .json and .midi complete. The other listed extensions receive all bytes but remain at "almost finished" indefinitely.
5. Open the same probe page in Microsoft Edge and repeat. All downloads complete normally.

What is the expected behavior?

After the response body has been fully received, each safe attachment should transition to completed and be renamed to its final filename. If a safety scan, content check, or final rename fails, the download should transition to an explicit canceled/interrupted state with a visible error.

A download must not remain permanently in progress after receivedBytes == totalBytes. The .mid alias should follow the same completion path as .midi.

Additional information

Codex Desktop package: 26.721.4979.0
Browser plugin/runtime observed locally: 26.721.41059
Bundled Codex CLI observed locally: 0.146.0-alpha.3

Browser automation observed a download event for .midi after about 1.87 seconds. Equivalent waits for .musicxml and .mid did not resolve after 15 and 12 seconds respectively, while the server had already logged complete 1/1-byte responses.

Full CDP access was enabled in Settings, but the available public browser-control surface did not expose Browser.downloadProgress terminal events. Host-side inspection should check the DownloadItem state, danger/safety verdict, target determination, final rename result, and whether every asynchronous completion callback is invoked.

Likely areas include extension classification, content/archive scanning, or a finalization callback path. The probe only establishes the browser-specific extension-dependent behavior; it does not identify which internal callback is missing.