Bug: Multi-file uploads failing and ZIP archives not parsing / sandbox timeout (100% Limits Remaining)

Nyu · September 1, 2026, 2:22pm

Critical ChatGPT file/sandbox regression since Aug 31, 2026.

Uploaded ZIP files appear normally as attachments in the ChatGPT conversation, but they are no longer reliably made available to the execution sandbox/runtime.

This is NOT an upload failure: ChatGPT sees the attachment, but when it tries to inspect/extract it, the file is missing from /mnt/data or otherwise inaccessible to the runtime.

Observed behavior:

Started Aug 31 on ChatGPT Web.
Briefly worked again in the browser during the evening, then failed again.
Desktop app continued working somewhat longer.
As of Sep 1, the desktop app is affected too.
Same ZIP-based workflows worked normally before this regression.

This is severely disrupting research/software-development workflows that depend on reviewing code and analysis bundles.

Please treat this as an attachment → sandbox/runtime mounting/access regression, not generic file-upload troubleshooting.

I have also submitted the issue to OpenAI Support.

narat128 · September 1, 2026, 8:51pm

Same here. It won’t mount or traverse any zip (or other) file under a project chat session.

Response:

“I could not mount or traverse the attached ZIP: the provided sandbox path /mnt/data/latest_data.zip is currently absent from the execution filesystem. The direct file read failed with FileNotFoundError, so I cannot truthfully claim the archive was traversed.”

…it still works, however, under a chat session not under an existing project.

swiftless · September 2, 2026, 1:39am

Same issue here, it was working yesterday, then stopped for an hour, then started working again.

Came in this morning and it worked again for an hour, now fails again.

I’m in a browser, in a project without Library access (on purpose) and using general chat on 5.6 Sol → High thinking effort.

The zip file uploads and the chat knows about it, but it’s not available at the /mnt/data/xyz.zip path.

I’ve tried .zip and .7z, even changing the filename, and no luck.

nikoskalomiris · September 2, 2026, 2:21am

I think I have found a workaround, and I hope it helps someone else facing this issue. I linked my GitHub account with ChatGPT and created a specific private repository for the Project agents to reference.

This setup allows every file type to work perfectly. The agents can interact with GitHub and make commits seamlessly, which provides excellent continuity and gives every agent a clear view of the repository’s history.

That said, I hope OpenAI addresses this matter soon. While I pay 23 EUR per month for a Plus account, many others rely on this platform professionally and pay hundreds of dollars or euros monthly. Leaving a critical issue unresolved like this is both unreliable and unacceptable.

jackden · September 2, 2026, 10:05am

I’m seeing what appears to be the same issue, particularly with .tar.gz archives.

My workflow involves uploading source-code archives for analysis and review.

The upload itself appears successful, and ChatGPT can often see the filename or attachment metadata. In some cases the file is also visible from Library.

However, when ChatGPT tries to actually inspect the archive, the underlying file is not available to the execution environment. Operations such as:

listing archive contents
extracting the archive
calculating checksums
comparing directory trees
performing programmatic source-code analysis

cannot be completed because the archive is effectively unavailable to the runtime.

The confusing part is that ChatGPT may still recognize that the uploaded file exists, while being unable to access the actual archive bytes.

I have also noticed a difference between file types:

individual .py, .txt, and .md files generally work
.tar.gz and other archive files are much more likely to fail
the behavior can be intermittent and may differ between conversations or projects

I started seeing this repeatedly around Aug 31 – Sep 2, 2026.

Using Library as a workaround does not fully solve the issue for my use case. ChatGPT may sometimes be able to search or index parts of the archive, but that is not equivalent to having the original archive available in the execution runtime.

For source-code review, the complete archive is needed so tools can extract the full directory tree, inspect all files, run diffs, calculate hashes, and perform consistency checks.

From the user side, the behavior looks roughly like:

Upload succeeds
→ attachment/file metadata exists
→ ChatGPT recognizes the file
→ archive is not available to the execution environment
→ extraction or programmatic inspection fails

This has happened multiple times with valid archives that can be extracted normally outside ChatGPT.

It would be useful if OpenAI could confirm whether this is the same file-materialization / sandbox issue reported in this thread, and whether there is a reliable workaround for archive-heavy workflows.

I can provide specific timestamps and anonymized reproduction details if that would help with backend investigation.

wbraswell · September 3, 2026, 2:23am

CROSS POSTING FROM https:// community openai com/t/chat-attachments-inside-projects-intermittently-fail-to-materialize-into-mnt-data-while-file-library-and-project-sources-work/1394088/12

This is absolutely NOT fixed, it has been affecting every chat session over the past 2 to 3 days and shows no sign of stopping! Basically this makes the service unusable and should be marked as ABSOLUTELY CRITICAL FOR IMMEDIATE ESCALATION!!!

Here is what ChatGPT itself says, in so many words, over and over again every time I try to get it to work right:

```
The uploaded attachments themselves are not exposed to me as a filesystem directory; they are in the attachment/search store, which has no path I can ls. The only filesystem path I checked for mounted uploads is /mnt/data, so I’m running ls -laR /mnt/data now, then I’ll return immediately to the Phase 3 fix work.

bash -lc ls -laR /mnt/data

Exact command result:

/mnt/data:
total 12
drwxrwsr-x 1 oai  oai_shared 4096 Sep  3 01:51 .
drwxr-xr-x 1 root root       4096 Aug  3 18:26 ..

So there is no mounted upload directory available in this runtime.
```

PLEASE PLEASE PLEASE FIX THIS IMMEDIATELY!!! WORK CAN NOT PROCEED!!!

david_horsman · September 7, 2026, 12:23am

I will start by covering my bug report. It also fails to find the files. It is important to note that this Behavior started when I moved the bootstrap zip file from my AI project to the library.

This “custom instructions” now halts on missing files "ChatGPT (?).zip

"Before doing anything else, load the ChatGPT operating instructions from one
available ChatGPT archive.

Accept only these uploaded filenames:

ChatGPT.zip
ChatGPT().zip

Select exactly one archive as follows:

If reliable upload timestamps are available, select the unique newest
archive.
Otherwise, select the archive with the unique highest numeric suffix;
treat ChatGPT.zip as suffix 0.
If no matching archive exists, or selection produces a tie, report the
problem and halt. Do not answer the current request.

Open only the selected archive. It must contain this exact, case-sensitive
entry:

ChatGPT/Bootstrap/ChatGPT-Developer-Bootstrap.md

If the entry is missing, report the problem and halt. Do not substitute a
generic bootstrap, an .AI archive, memory, another conversation, or any other
source.

Load the verified bootstrap and the files it explicitly requires, resolving
all internal paths from the ChatGPT archive root. Load each file at most once
and prevent circular loading.

After bootstrap loading completes successfully, continue with the user’s
current request."

Originally the first paragraph directs chat to load from the AI project. Not the library.

There are two bugs present here. First, you have to keep these zip files in some project, not the library.

But there is a second bug that the file name chat displays is not the true file internally.

File names are unique across the system. Internally chat assigns a progressively higher number to files with duplicate names. It emulates Windows in this one regard. Under certain circumstances this might be opaque.

Although I aim for a deterministic bootstrap this discovery is unavoidable:

"Accept only these uploaded filenames:

- ChatGPT.zip

- ChatGPT().zip

Select exactly one archive as follows:"

To fix this issue paragraph one should read:

"Before doing anything else, load the ChatGPT operating instructions from the AI Project ChatGPT sources."

That worked when I had a single copy of the zip file and even when I had multiple copies in different projects.

If anyone has experiences or has some comment that would be great. It’s a critical problem. I hope this workaround works for you.

david_horsman · September 10, 2026, 10:03pm

I will start by covering my bug report. It also fails to find the files. It is important to note that this Behavior started when I moved the bootstrap zip file from my AI project to the library.

This “custom instructions” now halts on missing files "ChatGPT (?).zip

"Before doing anything else, load the ChatGPT operating instructions from one
available ChatGPT archive.

Accept only these uploaded filenames:

ChatGPT.zip
ChatGPT().zip

Select exactly one archive as follows:

If reliable upload timestamps are available, select the unique newest
archive.
Otherwise, select the archive with the unique highest numeric suffix;
treat ChatGPT.zip as suffix 0.
If no matching archive exists, or selection produces a tie, report the
problem and halt. Do not answer the current request.