[macOS][ChatGPT Desktop] ZIP attachments fail with generic “Upload failed” in ordinary Chat
What version of the Codex App are you using?
ChatGPT/Codex Desktop 26.814.41407.
What subscription do you have?
ChatGPT Pro.
What platform is your computer?
macOS on Apple Silicon.
What issue are you seeing?
In ordinary Chat in the ChatGPT desktop app, ZIP attachments are accepted by the file picker and appear as attachment cards, but then fail with the generic message “Upload failed.”
I reproduced this with two separate .zip files in the same desktop session.
This appears to corroborate the currently open issue #39203, which reports the same desktop ZIP-upload failure and records an application/zip finalization rejection with HTTP 415 unsupported_mime_type.
OpenAI’s current file-upload documentation lists common supported document, spreadsheet, presentation, and text formats, but does not clearly state whether .zip is supported in ordinary Chat.
What steps can reproduce the bug?
- Open an ordinary Chat in ChatGPT Desktop on macOS.
- Select a
.zipfile using the attachment picker. - The app accepts the file and creates an attachment card.
- Wait for upload processing.
- The card changes to “Upload failed.”
- Repeat with another
.zipfile; the same failure occurs.
What is the expected behavior?
If ZIP attachments are supported, the archive should upload successfully.
If ZIP attachments are intentionally unsupported, the desktop file picker should reject the file before upload begins and clearly explain that the format is unsupported instead of accepting it and later showing a generic upload failure.
Additional information
In-app feedback was submitted for this reproduction:
no-active-thread-01a01c6d-e27f-74d3-8e42-c93e5969d0c4
Related open issue: #39203.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can reproduce a similar issue on the Windows ChatGPT desktop app.
Environment:
Test results:
Working:
Failing:
Additional tests:
This suggests the issue may not be related to the file extension or archive contents, but possibly a problem with the desktop app's file type detection, MIME handling, or upload preprocessing for certain binary/archive/executable file types.
The previous desktop client was able to upload these files, so this appears to be a regression introduced in a newer desktop version.
Hope this additional information helps with debugging.