An interesting problem began yesterday, files uploaded into “chat” sessionss were visible for the agent to search, but the agent reported not being able to mount it in the local runtime environment. It started with a long running chat, and has begun to appear in every single chat, including chats inside of projects with isolated memory. Consistently the agent is able to search a document but not interact with it with python or other tooling. In other words if I upload a text file it can see the text, but python automations can’t map or correctly.
Branching a chat will temporarily “fix” it, presumably because a new runtime is instantiated, but eventually those branched chats end up in the state too. This is entirely independent of platform/browser and I have no reason to believe the UI has anything to do with it.
This is the agents own summary:
=================================
What I’m seeing is a split between two file-access paths that are behaving differently:
-
The attachment/file-search layer often sees the uploaded file correctly and can even expose its contents.
-
The Python/runtime filesystem sometimes never receives that same upload at the advertised
/mnt/data/...path. -
Files that I create myself inside
/mnt/dataremain accessible and can be reopened normally. -
The failure has happened across CSV, ZIP, TXT, and SQLite attachments, including renamed copies, so it doesn’t look tied to one file type or one corrupt file.
My best inference is an intermittent handoff/synchronization bug between the upload/attachment service and the execution sandbox mount. In other words, the platform successfully registers the upload, but the step that materializes that file into the code runtime sometimes fails.
The .txt experiment strengthened that suspicion: the file was fully readable through file search while still absent from /mnt/data. Then, when I recreated a CSV from that searchable content, the new file written directly in the runtime behaved perfectly. So the problem appears to be incoming attachment → sandbox mounting, not general filesystem instability or inability to work with the data once it is inside the runtime.
I would not claim a deeper backend cause than that without platform logs, but the evidence is pretty consistent with a file-service/runtime-mount synchronization failure.
====================
The only other thing that is possibly pure coincidence, is that I ran out of “pro” usage right before this began, and it isn’t getting reset till tonight. I don’t know if somehow that restricted usage impacted the runtime behavior for chats functioning as high/extra high, but it is a little curious in terms of timing.
I did open a help chat on help.openai , the agent tried to escalate, but I never saw a human pick up the chat, or a ticket created, perhaps that was not the right avenue to report a bug.
I’m a little stimied, and would appreciate if someone had some similar experience to share.