Independent report shows Chat CAAS/Python/container failures persisting for 7+ days while Work execution remains healthy on the same account.

A paid ChatGPT user in the APAC region reports that for over seven days, Python and container executions in regular Chat fail with caas.internal.errors.ClientError, while ordinary chat responses, project retrieval, and Work spreadsheet execution remain healthy, showing the failure is isolated to the Chat execution/tool-runtime path.

> Independent report: Chat CAAS/Python/container failures persist for 7+ days while Work execution remains healthy on the same account
>
> 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 separ