I am experiencing a severe breakdown in the file-handling pipeline on ChatGPT today. The platform is completely refusing to process multiple file attachments or compressed archives.
The Symptoms:
Multi-file Upload Failure: I am completely unable to upload more than one file as an attachment in a single message.
Upload Timeouts: Attempting to upload even a single standalone file takes an extremely long time to process, or fails entirely without an explicit error code.
ZIP Files Not Parsing: As a workaround, I bundled my files into a single .zip archive. While the archive attaches to the prompt, ChatGPT is entirely unable to read, unzip, or parse the contents inside the sandbox environment today.
Troubleshooting Already Attempted:
Checked account usage panel: I still have 100% of my 5-hour and weekly limits available, so this is completely unrelated to standard rate-limiting.
Attempted hard cache refreshes (Ctrl + F5) and tested in Incognito/Private browsing windows, but the bug persists across sessions.
Is anyone else experiencing this file-processing degradation today? It looks like a backend sandbox cluster or file-handler infrastructure pipeline issue.
Hoping an engineer or mod can escalate this to the system status page! Thank you.
If in project it should work outside current work around for project is upload manually to library in storage and then attach it in project via add from library
in project … keeps repeating the same (The sandbox mount advertised for the four ZIPs is not actually present in the execution runtime right now, so I’m using the file service’s raw-byte materialization as the fallback instead of claiming they’re unavailable. Once the bytes land, I’ll extract and inspect all four archives directly.) …i’ll give library upload a try
Same issue. Zip files content are not readable any longer if uploaded in a chat within a Project. Outside Projects, that still works but not within Projects.
what i got word . for . word as a response → I tried every supported path to open all four ZIPs directly, and the platform is blocking access to their contents, not just their filenames.
Thanks for confirming! I am working inside a project chat, so I will try your workaround right now.
I’ll head over to the project storage settings, upload the files manually into the library, and then pull them into the chat using “add from library.” Hopefully, that gets around this upload bug! Thanks for the save.
Keep in mind it’s quite buggy slow might need a few refreshes/upload attempts but eventually it gets uploaded. If it’s file being given to you from AI to DOWNLOAD then it automatically goes to library so no need download upload just refresh page, so upload anything on your pc not given as download by AI
Thanks for the help, Slavax! I actually just tried the library trick and it worked for a zip file, but for some reason, it’s completely stuck on standard text files right now. It won’t let me upload them in the chat or the library.
I’ll just stick to zipping everything up from my PC for now and keep refreshing until it finally goes through.
That’s a huge lifesaver about the AI downloads automatically going to the library, too. That saves me a lot of time.
Personally image and text uploads go fine directly into project chat, is just zips I am forced to use library but most of time zip comes from AI itself so I just reupload from library. Hope it gets fixed soon probably connected to Work issues right now
The attachment appears normally in the ChatGPT UI.
ChatGPT receives a file reference/path under /mnt/data/....
Ask ChatGPT to inspect or extract the archive.
When the execution environment attempts to access that path, the uploaded archive is not actually present/accessible.
I reproduced the same behavior with multiple independent archives, including both .zip and .tar.gz.
Expected behavior
The uploaded archive should be available to the execution environment at the supplied file path.
Actual behavior
The attachment is visible in the ChatGPT UI, but the corresponding file is missing from the sandbox when ChatGPT tries to access it.
Individual non-archive files remain readable/searchable, so this appears to be an archive attachment → sandbox mounting/handoff issue rather than corrupted source files.
Reproducibility: consistent across multiple attempts.
Guys if this is still happening after a while and still not acknowledged on the status page I wouldn’t keep my hopes up and expect a quick fix, gpt 5.5 mini took about a week to even notice and it’s still happening to some users. If the library workaround works for you just keep using it until it’s eventually fixed even if it takes a few weeks
My workaround is to upload the ZIP to Google Drive, then share the link with ChatGPT or ask it to find the file through the Google Drive app/plugin. It can extract and read it that way. At least it works for me as a temporary solution.
Hello, I can confirn the issue: archives (such as .zip, .7z, .gz, etc.) seem to upload fine, but they are not properly saved to mnt/data/ mount point. So ChatGPT cannot access these files in any way.
This is a big trouble for me, since I work with tens of hierarchically organized files and it’s not possible to upload them in other way.
Hopefully OpenAI gives this bug a TOP prio.
P.S. uploading an archive to a chat outside of Project seems to work…sure, it doesn’t solve the issue, just saying…
@Slavax I tried the File Library workaround. It partially works for document retrieval, but it is not a replacement for sandbox mounting.
What worked:
Markdown files inside the archive could be indexed/searched/read through File Library.
What did not work:
The original .tgz was still not available under /mnt/data.
I could not directly extract the archive, inspect the full directory tree, verify hashes, or reliably diff source files between submitted archives.
So File Library is useful as a document retrieval workaround, but workflows that require actual archive/source inspection still need the sandbox mount.
Interestingly, in my account:
Project → New conversation → Work mode
→ /mnt/data mount works
Project → New conversation → Regular Chat
→ upload succeeds, but /mnt/data mount fails
I can add another reproducible case, with an additional project-specific isolation result.
I am using ChatGPT Plus on the web.
In one long-running Project, ZIP and TGZ attachments are accepted by the UI and saved successfully to Library, but they are not materialized in the analysis sandbox.
For example, the assistant is given an expected path such as:
/mnt/data/Ot_20260901_1809.zip
but checking that exact path from the execution environment shows that the file does not exist.
What makes this case interesting is the isolation:
ZIP in the affected Project: FAIL
TGZ in the affected Project: FAIL
TXT in the same Project: WORKS
PNG in the same Project: WORKS
ZIP in another Project under the same account: WORKS
The ZIP is only about 275 KB.
The affected Project’s explicit Sources list is empty, so this does not appear to be the 25-files-per-Project Sources limit.
The Project is old and has accumulated many files from previous chats. Library currently shows about 130 files when filtered to this Project, even after I deleted 49 older files. I do not know whether that is related, but I am mentioning it as a possible clue rather than claiming causality.
This looks more like a Project-specific file-reference / sandbox-materialization problem than an archive upload problem.
A temporary workaround is to concatenate source files into a .txt file; those attachments are materialized correctly.
For roughly the past 18 hours, I’ve encountered what appears to be a file-provisioning issue in ChatGPT Projects.
In two separate chats within the same Project, ZIP files appeared to upload successfully and were visible as attachments, but the chats could not access the actual file bytes in their execution environment. As a result, they could not open the ZIP, inspect its contents, or calculate its hash. The accompanying Markdown files remained readable.
My current workaround is to add the ZIP and checksum sidecar to Project Sources. After doing that, the files become accessible and verify normally, confirming that the ZIPs and checksums themselves are valid.
In one instance, the original directly attached ZIP also became accessible on a later turn over an hour later.
I have not tested whether the same issue occurs outside Projects or in a newly created Project. For now, I’m using the Project Sources workaround until the underlying issue is fixed.
