Update: I was using the ChatGPT Classic desktop app. The issue was persistent on my pc for web app too. However the updated desktop app (with codex) was able to mount the ZIP file. I believe the issue is on the older upload pipeline which is still in use by the web app and the classic app.
It’s quite impactful to some users but depending on what tier of customers is being impacted the most as with 5.5 mini this does not look like a nerf unless poorly implemented so eventually this will probably be looked into and fixed but so far there is nothing on the status page same as with 5.5 mini so might take a while
Best you can do if you have time to troubleshoot for the community is explain your situation in detail to chatgpt and ask it what tests you should run but usually if there is nothing on status page this is a low priority so might take a while, whatever work around works for you now I’d probably stick to it and hope eventually it’s fixed even if it takes like a week again
for me its on 5.6 sol
work with 5.6 sol extra high also doesnt seem to actually see files in the project properly
Same issue here. I started experiencing this today, August 31.
Newly uploaded attachments are visible in the ChatGPT conversation UI, but they are not available to the execution environment. The expected files are missing from /mnt/data, and attempts to access them result in ENOENT / file not found.
I reproduced this across multiple ChatGPT Projects, different conversations, and different ZIP files. In affected conversations, other previously available files can still remain accessible, so the execution environment itself is running — it is specifically the newly uploaded attachment that never becomes available to the runtime. I also reproduced the same behavior in a fresh conversation with a different file.
Have the same issue with audio
that’s… interesting. note: an OLDER file was mounted then disappeared from the CURRENT container so appeared to be a deletion.
this tends to suggest quite a sophiaticated emulation of a filesystem - likely involving… mmm… fuse and cacheing and all sorts of stuff some of which keels over or performs cache-cleanups without keeping a proper usage-count (which, having atudied how sophisticated webkit is i know is REALLY hard to get right and still be efficient/fast) and it all goes to hell in a handbasket sporadically.
Me too.
I am using markdown files and ZIP files to handoff to a new chat in a ChatGPT Project. It worked well, until I encountered the issue similar to the OP on Aug 30-31.
Same issue. Only have this issue when create chat in Project. Start from yesterday. Cant find uploaded files in sandbox and cant use zip file. I also asked 2 of my friends they all tested the same issue.
Same issue here, the problem appeared today.
The attachment is successfully indexed/readable at the ChatGPT document layer but is not mounted at its declared path in the code-execution sandbox.
This happens inside my big project but not on new chats outside
been having the same issue for the past couple days together with the model downgrade rerouting issue, i tried subscribing to pro and using that and after couple hrs of pro work in total i’m now limited for a week? what a messy service
I believe OpenAI is already aware of the current attachment/project-file issue involving /mnt/data, but I want to flag an additional impact that may not be obvious: the same problem is also preventing ChatGPT from successfully creating and delivering new downloadable artifacts.
I have now reproduced this across multiple fresh chats/builders in a ChatGPT Project.
The failure has two sides:
1. Input files sometimes fail to materialize into /mnt/data.
A ZIP uploaded through the Project Library can appear normally in the UI and be recognized by ChatGPT, while the execution environment sees:
PATH=/mnt/data/<file>.zip
EXACT_PATH_EXISTS=YES
ACTUAL_BYTES=0
ZIP_OPEN=FAIL
In some cases, Markdown/text files remain readable through ChatGPT’s uploaded-file/project-file system even though their /mnt/data representation is zero bytes. ZIP contents, however, cannot be recovered through that alternate route.
2. More importantly, output/download creation is also failing.
In one Builder run, ChatGPT successfully created and validated the requested new source files in a temporary working directory:
/tmp/track10h_f_step4_draft/
The candidate files passed their checks. However, the finalization step that was supposed to place the approved downloadable artifacts at:
/mnt/data/workflow_intake_ops.py
/mnt/data/workflow_intake_serializers.py
never completed. The final check reported:
INTERRUPTED_ATTEMPT_CANDIDATE_NOT_FOUND
As a result, ChatGPT could not provide the required working download links even though the actual code generation had succeeded.
A second fresh Builder could not even start because its input ZIP appeared at the correct /mnt/data path but had ACTUAL_BYTES=0.
I have also found an important workaround/data point: uploading the same ZIP into the Project Source section, rather than only the Project Library/message attachment path, successfully materialized the physical ZIP. On that attempt ChatGPT verified:
ACTUAL_BYTES=37350
ZIP_OPEN=PASS
ZIP_INTEGRITY=PASS
and independently verified both files inside against their expected SHA-256 hashes.
So this appears to be more than an attachment-reading problem. It looks like there may be an intermittent failure in the handoff between Project/Library file storage ↔ execution sandbox /mnt/data, and that same filesystem/materialization problem can affect both incoming files and newly generated outgoing downloadable artifacts.
This is significant for workflows that rely on ChatGPT to generate code, proofs, documents, ZIPs, or other downloadable files: the model may complete the work correctly but still be unable to deliver the resulting artifact.
Observed pattern:
UI/file reference exists
→ ChatGPT recognizes the attachment
→ /mnt/data pathname may exist
→ physical file is zero bytes or fails to materialize
→ ZIP/file cannot be opened
→ Builder must stop
And on output:
candidate artifact generated successfully
→ candidate checks pass
→ final /mnt/data materialization/finalization fails
→ downloadable artifact cannot be provided
Please make sure the engineering investigation covers outbound artifact creation/download delivery as well as inbound attachment mounting, because I have now experienced both manifestations of what appears to be the same underlying /mnt/data problem.
Thank you very much for taking the time to explain this in such detail. Your findings about a possible failure in the materialisation layer between Project/Library storage and the sandbox are particularly interesting, and they may help explain at least part of what we are seeing.
My case seems to be somewhat more severe, though.
In the affected Project, the executor can fail before any meaningful filesystem operation even takes place. For example, extremely basic commands such as pwd or ls -la /mnt/data can immediately return:
ClientError — Encountered exception: <class 'caas.internal.errors.ClientError'>
We have done quite a bit of troubleshooting to isolate it, without involving any project-specific code or workload. In summary:
-
New chats created inside the affected Project reproduce the same failure.
-
Branches/chats within that Project show the same behaviour.
-
Very basic executor commands fail, so the issue is not dependent on Node, Python, ZIP processing, or any particular application code.
-
Simple filesystem and file-materialisation tests also fail in the affected environment.
-
The same account can use the executor normally outside the affected Project.
-
A newly created test Project also works normally.
-
The problem was reproduced from another machine as well, which makes a purely local browser/OS/cache issue much less likely.
So in my case, it looks as though the problem may occur even earlier than the /mnt/data materialisation failure you described — possibly during provisioning or initialisation of the execution environment associated with that particular Project.
Of course, that is only an observation/hypothesis from the tests we have performed, not a confirmed root cause.
I am currently in contact with OpenAI Support and have already provided them with timestamps, screenshots, reproduction steps and environment details. If I receive any useful information, confirmation, workaround, or resolution from them, I will definitely share it here as well.
Thanks again for documenting your findings. It is very helpful to see another reproducible case and a possible explanation for what may be happening at the storage/sandbox boundary.
ahh there’s been a major outage on chatgpt dot com a couple of hours ago. ChatGPT 5.6 informed me after evrrything returned that “git store was missing”. that means that the OpenAI team implement a multi-layered fuse / composite filesystem where .git subdirectories get entirely removed anf cached separately.
this explains the repeated inexplicable “the .git directory has disappeared” messages as the cacheing timeout on .git directory contents DESTROYS a directory that happens to be mounted from a totally separate subsystem.
one for the devteam to sort out as it’s fairly major.
The reset means this incremental bundle’s prerequisite objects are no longer present in my current Git object store,
I’m experiencing what appears to be the same issue.
The failures are intermittent and occur in both Project and non-Project chats.
In affected chats, uploaded/Library-attached files are visible to the conversation, but Python/container execution fails before the command starts with:
caas.internal.errors.ClientError
Even minimal commands such as pwd, ls -la /mnt/data, or simple Python execution fail.
At roughly the same time, another fresh chat on the same account successfully started Python, created a file in /mnt/data, read it back, calculated its SHA-256, and returned a working sandbox download link.
I have also seen a separate failure mode where Library-attached files are visible in the chat metadata but their bytes are not available inside /mnt/data.
Environment: ChatGPT Web, Team workspace, Taiwan/APAC.
So this does not appear to be caused by a specific ZIP, script, Project, or conversation history. It looks like an intermittent CAAS/container provisioning or file-to-sandbox materialization issue.
devs, just so you are aware: since the rather major “oops” of a couple days ago, approximately… 100 long-running conversations, i’ve had timeouts at the limit of the UI stream (near “you have reached Max requests, start a new chat”) and interestingly stalling is less and also the few times i’ve had to stop it and recover it has not said “.git contents disappeared”. early days yet, empirically, but it looks like major useability issues on day-to-day workflow when pushing things to limits is improving.
ChatGPT uploaded files appear accessible, but the full file isn’t consistently available to the analysis environment
I’m having an issue where ChatGPT successfully accepts uploaded files, but the full underlying file isn’t consistently accessible for analysis.
The file appears attached to the conversation, and ChatGPT can sometimes see or retrieve parts of it, but it cannot reliably access the complete file through the analysis/Python environment.
For example, I uploaded a CSV in one conversation and ChatGPT was able to inspect it. I then uploaded the exact same file to another conversation, where ChatGPT could see that the file existed but couldn’t access the full contents.
This has been happening for around 10 days.
The important distinction is:
File upload works → file is visible → but full file access/mounting to the analysis environment does not consistently work.
This is especially problematic with large files, where being able to retrieve snippets is not enough — the entire file needs to be accessible for proper analysis.
Has anyone else experienced this, or know whether there is currently an issue with uploaded files not being fully mounted/available to the code interpreter/analysis environment?
OpenAI Support has already escalated my case, but I’m trying to determine whether this is a known issue affecting other users too.
Exactly we are not getting the output consistently as some times it comes and sometimes it say cant access or excute in working environment unable to access MMT data