I’m posting this as an independent corroboration of the recent reports about caas.internal.errors.ClientError, Python/container failures, and /mnt/data / sandbox instability.
I am a paid ChatGPT user in the APAC region. I have been experiencing a closely related issue for more than seven days, and it is still reproducible as of September 8.
The recurring error is:
caas.internal.errors.ClientError
Encountered exception: <class 'caas.internal.errors.ClientError'>
The important part: this is not just a file-mount problem
In affected Chat sessions, even trivial execution can fail before any real workload begins.
Examples include:
Python:
1 + 1
6 * 7
Container:
/bin/true
/bin/echo test
These can fail with the same CAAS ClientError.
When that happens, /mnt/data cannot be meaningfully tested because the execution environment itself does not start.
At the same time:
Ordinary Chat responses WORKING
Project/source retrieval WORKING
Python execution FAILING
Container execution FAILING
So the conversation and retrieval layers can remain available while the execution layer is unavailable.
Same-account Chat vs Work comparison
The strongest control I have is on the same account during the same general period:
Regular Chat
Python/container execution FAIL
ChatGPT Work
Spreadsheet execution PASS
Work is not a complete replacement for my normal workflow, but this comparison makes a browser-wide, network-wide, or complete account-wide outage a much weaker explanation.
The failure appears disproportionately concentrated in the regular Chat execution/tool-runtime path.
The environment also flaps
This has not been a simple permanent failure.
Across repeated observations I have seen states such as:
container FAIL + Python FAIL
↓
container FAIL + Python PASS
↓
container PASS + Python PASS
↓
container FAIL + Python FAIL again
I have also seen different conversations around similar times exhibit different execution states.
No relevant browser, network, account, or user-side configuration change occurred between those transitions.
That makes a static file problem or permanent account capability restriction difficult to reconcile with the observations.
Controlled diagnostic evidence
During one controlled reproduction, the execution request was issued quickly, but the tool layer did not return the CAAS error until roughly a minute later.
The conversation stream itself remained active during the wait.
In other words, the observable sequence looked approximately like:
conversation functioning normally
→ execution tool invoked
→ long wait inside tool/runtime path
→ caas.internal.errors.ClientError
→ conversation continues
This is why I suspect the relevant failure domain is somewhere around execution provisioning, runtime allocation/binding, tool routing, worker lifecycle, or another sandbox orchestration layer.
Those are hypotheses only; I do not have access to backend logs.
Support status
I have already supplied Support with extensive diagnostic material including:
- controlled failure timestamps,
- HAR data,
- browser console data,
- execution error strings,
- cross-session comparisons,
- Chat-vs-Work observations.
Support has stated that an end-to-end trace focused on the Chat tool/runtime path is being performed.
There is still no confirmed root cause or remediation.
Related community reports
I found another recent Developer Community thread reporting extremely similar behavior:
“caas.internal.errors.ClientError — Python/container + uploaded files intermittently unavailable for 4+ days”
That thread includes reports of:
- uploaded files becoming inaccessible to execution,
- Python/container startup failures,
- temporary recovery followed by recurrence,
- Project and non-Project failures,
- and Work functioning better than regular Chat for some users.
I am creating a separate post because my case adds a useful differential:
the same account can have working Work execution while regular Chat execution continues to fail for more than a week.
Looking for specific reproductions
If you are currently affected, could you report the following?
Plan:
Region (country not required):
Approximate date/time + timezone:
Regular Chat:
Python: PASS / FAIL
Container: PASS / FAIL
/mnt/data: PASS / FAIL / not testable
Project chat:
Python: PASS / FAIL
Container: PASS / FAIL
Work:
Execution: PASS / FAIL / not tested
Did the failure later recover?
Did it return after recovery?
Especially useful would be independent confirmation of any of these:
- Python/container fails while ordinary Chat continues working.
- Project/source retrieval works while execution fails.
- One conversation works while another fails.
- Failure temporarily disappears and later returns.
- Work execution works while regular Chat execution fails.
- The problem persists for several days.
I am not claiming intentional throttling or deliberate restriction.
I am trying to establish whether there is a broader intermittent problem in the Chat execution infrastructure that is not visible in aggregate service status.
If multiple users can provide clean A/B observations, that should make this considerably easier to isolate.