I am adding another independent report of the recurring caas.internal.errors.ClientError issue. I am using a normal ChatGPT conversation, not ChatGPT Work.
WHAT WORKED BEFORE
In the same ongoing conversation, ChatGPT previously opened uploaded ZIP archives, inspected and modified files, ran Python and other commands, performed tests, and generated downloadable ZIP packages. Those operations worked with large archives containing many files.
WHAT FAILS NOW
Since 14 October 2026, every attempt to execute even a basic Python or container command has failed. Repeated attempts on 15 October have produced the same problem.
Exact error:
system_error
ClientError
Encountered exception: <class ‘caas.internal.errors.ClientError’>
This happens with trivial tests, including basic Python print statements, before useful code has a chance to run. Simple container/shell commands also fail. Changing the code does not help.
WHAT IS STILL WORKING
The conversation itself still responds normally. ChatGPT can sometimes search, list and locate files in the conversation or Library. However, it cannot reliably open those files inside the execution environment or modify them using Python/shell tools.
PRACTICAL IMPACT
- ZIP archives cannot be extracted and updated.
- Existing files cannot be programmatically edited.
- Automated tests and scripts cannot run.
- New downloadable files and final ZIP packages cannot be created.
- Previously working ongoing workflows become completely blocked.
IMPORTANT DETAIL
This is separate from an internet/dependency-download problem: even tests that require no downloads, external packages or user files fail. It is also different from a bad ZIP archive because the same workflow worked earlier in the same conversation.
POSSIBLE CONNECTION TO EXISTING REPORTS
In the existing threads, OpenAI Support has said that some similar failures were traced to attachment/file-copy operations timing out before the requested code started running. That might explain why the error appears even for trivial commands, but I do not know whether that is the cause of this particular session. I have no access to backend logs.
REQUEST
Could OpenAI confirm whether this session’s error is the same known execution/attachment-transfer problem, whether there is a practical workaround, and whether an engineering fix or estimated resolution is available? It would help if affected users could track this on the public status page.
I can provide exact failure timestamps and further reproduction details privately through Support if needed. I am deliberately omitting names, private files, and project details here.
Observed: 14–15 October 2026, South Africa (UTC+02:00).