Part of me is relieved to see that I’m not the only one encountering this error, although I’m certainly not happy that other people’s work is being disrupted too.
I found a couple of existing Developer Community threads describing symptoms similar to mine, so I wanted to add a structured account of what I’ve observed and tested. I’m not assuming that all of these reports necessarily have the same underlying cause.
Environment
- ChatGPT plan: Pro 20x
- Browser: Chrome Version 152.0.7977.76 (Official Build) (64-bit)
- Desktop app: ChatGPT Version 26.901.51231
- Conversation contexts tested: Project chats, fresh chats outside the Project, regular chats, and Temporary Chats
- Test period: Sep 6–8, 2026
This concerns ChatGPT’s built-in Python/container execution environment, not the OpenAI API and not Python running locally on my machine.
Main error
The recurring error is:
ClientError
Encountered exception: <class 'caas.internal.errors.ClientError'>.
In affected turns, the execution request sometimes returns no usable filesystem or Python output at all.
Later diagnostic attempts also produced isolated instances of:
caas.internal.errors.TransportTimeoutError
caas.internal.errors.InvalidArgumentError
I’m keeping those separate rather than assuming they all have the same cause.
What originally triggered the investigation
My actual task involved a documentary review of several uploaded research files, including two large ZIP archives:
- ZIP 1: 395,301,096 bytes
- ZIP 2: 492,689,298 bytes
- small prior-review ZIP: 398,361 bytes
- small DOCX: 15,892 bytes
Combined size: approximately 888.4 MB.
Both large ZIPs are individually below the documented 512 MB per-file upload limit.
Initially, the pattern made it look as though adding the second large ZIP might be triggering the failure. Several tests showed the smaller files and ZIP 1 becoming available successfully, followed by repeated ClientError responses after ZIP 2 was added.
However, subsequent testing made the picture more complicated.
Tests performed
To separate the execution problem from the actual research task, I reduced the requests to very basic checks:
- run a trivial Python expression;
- verify that
/mnt/dataexists; - enumerate mounted attachments;
- obtain filesystem byte sizes;
- open each file for a one-byte read.
During those checks I explicitly did not request:
- ZIP extraction;
- ZIP central-directory inspection;
- full-file hashing;
- document parsing;
- workbook analysis;
- substantive research analysis.
So the observed failures did not require the original complex workflow to reproduce.
I tested both ChatGPT Desktop and Chrome, and both regular and Temporary Chat contexts.
I also tested multiple model/reasoning configurations:
- GPT-5.5: Instant, Medium, High, Extra High, Pro
- GPT-5.6 Sol: Instant, Medium, High, Extra High, Pro
- GPT-6 Astra Pro
Switching configurations sometimes coincided with recovery, but failures later occurred under settings that had previously worked. I therefore did not identify a consistently reliable model-switching workaround. These were sequential troubleshooting tests, not a controlled benchmark of model reliability.
Most informative test: ZIP 2 by itself
I eventually tested ZIP 2 alone in a fresh Desktop Temporary Chat.
That archive repeatedly passed the narrow materialization check:
- present in
/mnt/data; - reported at 492,689,298 bytes;
- successful one-byte read.
The important part is that the same conversation later began returning ClientError, then recovered, then failed again, without another upload or deliberate file change being recorded.
So the hypothesis that “both large ZIPs together are necessary to trigger the error” does not hold.
ZIP 2 alone can be accessible, and the same session can later fail.
Minimal commands also failed
During later diagnostic periods, even trivial execution requests failed, including commands equivalent to:
print("execution_probe_ok", 1 + 1)
and:
/bin/echo execution_probe_ok
I also tried alternate execution paths/configurations, including Python and container execution.
At times, all of them returned ClientError before useful filesystem output was produced.
This makes an error in my ZIP-processing code or research workflow a poor explanation.
At the same time, I don’t think this proves that attachments are completely unrelated. A minimal command issued inside a conversation containing a large attachment may still depend on session initialization or attachment preparation behind the scenes.
Intermittent recovery
Another important observation is that the problem has not been permanently reproducible.
There have been sequences where:
- an attachment check passed;
- later execution failed with
ClientError; - subsequent attempts succeeded again;
- later failures returned.
There were also periods where repeated retries failed for an extended period.
This makes the issue look more like an intermittent execution/session/materialization problem than a deterministic “this particular ZIP is unreadable” condition.
One unusual file-size observation
In the single-ZIP test, successful checks normally reported ZIP 2 as:
492,689,298 bytes
One successful response instead reported:
487,325,696 bytes
A later check returned to the original 492,689,298-byte value.
That is a difference of 5,363,602 bytes.
I am not claiming this proves truncation or corruption. It could represent:
- a runtime/materialization issue;
- a reporting error;
- a transcript/UI artifact;
- some other explanation I can’t verify from the available diagnostics.
I mention it because it may be useful to someone who has access to backend request or file-materialization logs.
What I do not think the tests establish
I don’t think the evidence currently justifies claiming that:
- either ZIP is corrupt;
- there is a fixed combined-size threshold;
- Project history or the number of Project conversations is the cause;
- one particular model causes the error;
- one particular model fixes the error;
- Chrome is the cause;
- the Desktop app is the cause;
- Temporary Chat is the cause;
- all reported
ClientErrorcases in the community share the same root cause.
Some of those remain possible, but my tests do not isolate them.
Current working hypothesis
My current working hypothesis is an intermittent issue somewhere in the execution/session/file-materialization path.
Large attachments may increase the likelihood of encountering it, but I don’t have enough evidence to claim that archive size itself is the root cause.
The fact that:
- the same archive can be accessible, while later attempts in the same conversation can fail before its state can be verified;
- trivial execution can fail;
- the issue has reproduced across multiple chat contexts and clients;
- switching models does not reliably fix it;
makes a transient service/session issue seem more plausible to me than a defective archive.
That is still a hypothesis, not a confirmed OpenAI root-cause determination.
Practical impact
In my case this is blocking a provenance-sensitive research workflow where I need to verify exact source files before processing them.
Because of that, I cannot simply treat a previous successful attachment check as proof that the file is still available later. I have had to build explicit file-identity/materialization gates into the workflow and stop whenever the execution environment fails.
For now I’m:
- preserving the original files unchanged;
- avoiding unnecessary extraction or duplication;
- verifying inputs before substantive work;
- stopping rather than inferring results when execution fails;
- preserving the failed attempts for troubleshooting provenance.
Related community reports
I found two existing Developer Community discussions that appear relevant:
- “caas.internal.errors.ClientError — Python/container + uploaded files intermittently unavailable for 4+ days”
- “Unable to access files in /mnt/data — both Python and container tools return ClientError”
I’m mentioning these as related symptom reports, not as proof that our cases share the same cause.
Questions for OpenAI / anyone investigating
If someone from OpenAI or anyone familiar with the execution infrastructure sees this, I’d be very interested to know:
- Is there a supported way to recover or reinitialize the execution environment without losing the conversation and uploaded files?
- Is attachment materialization performed again when a new execution session starts?
- Could a large attachment affect execution startup even when the command itself does not reference the file?
- Is there any diagnostic identifier, request ID, or log information users can collect that would help correlate these
caas.internal.errors.ClientErrorevents? - Are there limits beyond the documented per-file upload limit that could affect the execution environment—for example aggregate mounted-file size, temporary storage, or materialization limits?
- Would OpenAI prefer conversation IDs, timestamps, screenshots, HAR files from the browser, or some other information for investigation?
I have preserved the test transcripts and can provide redacted excerpts, conversation details, and reproduction steps privately if useful.
Hopefully this adds another useful data point without overstating what my tests actually prove. 
