Unable to access files in /mnt/data — both Python and container tools return ClientError

ChatGPT Bugs
1

’m experiencing an issue with the local execution environment in ChatGPT.

I have a Parquet file uploaded to the project at:

/mnt/data/ts_target(1).pq

Previously, ChatGPT was able to read and analyze Parquet files from /mnt/data normally. However, it is now unable to access this file at all.

The problem does not appear to be related to the Parquet file itself, because the error occurs before any Parquet parsing takes place.

For example, even very basic operations such as:

  • checking whether /mnt/data/ts_target(1).pq exists;
  • listing the file with ls;
  • accessing /mnt/data through the Python execution environment;

all immediately fail with:

ClientError

I also tried using a separate local/container execution path, and it returned the same ClientError.

Therefore, this seems to be an issue with the ChatGPT local execution environment, sandbox, or /mnt/data file mounting/access layer rather than with the contents or schema of the Parquet file.

The file is still shown as uploaded and its expected path is:

/mnt/data/ts_target(1).pq

Could you please help investigate:

  1. Why the execution environment can no longer access files under /mnt/data?
  2. Whether the sandbox/file mount for this conversation or project is currently broken.
  3. Whether the execution environment can be reset or reinitialized without requiring me to re-upload all of my project files.

This is particularly important because I have multiple large Parquet datasets already uploaded to this ChatGPT project, and they were previously accessible for local analysis.

2

yep i just suddenly started seeing this exact same thing, 90 minutes ago.

two long-running complex sessions (to give some idea: if i do print save-as to pdf it comes to 300 pages, and i frequently hit “Too many requests” and “Max UI session limit, start a new one”) suddenly both stopped being able to run even “echo ok”.

after they reported “Error”, looking at thinking showed it was aiohttp, but what does that have to do with bash, ls and echo??

i started a new session from-scratch: it was also fine initially and after running multiple commands successfully also half-way through exhibited the exact same error.

the weird part is that when every session goes “i got ClientError”, and i ask “ok please try again” it says “yes i was able to run some commands then it happened again”.

that diagnostic was at least enough for me to be able to request the absolute bare minimum of pre-installed git commands to get the work extracted, untested, out of the container.

this type of situation has happened before: about… four months back. it was much more serious, no diagnostics were possible at all: all container usage stayed dead for about 12 hours. i do mean all

by the morning i assume some sort of hard reset or refresh occurred: containers magically started working again.

as a software developer i suspect this is one of those edge-cases that just was never envisaged as part of a rollout, so repro/systems-test prior to rollout is challenging.

ChatGPT 5.6 Sol High thinking. the repos being uploaded are 7mb and 2mb respectively, so not massive urrr fe4 gof’s sake url post prohibited. laaaame. /gitlab.com/d12rg/d12rg-riemann /gitlab.com/d12rg/d12rg_hypergroup

3

Screenshot_2026-08-30-21-24-49-640
Screenshot_2026-08-30-21-24-49-6401080×2400 268 KB

4

I ran into something adjacent while cleaning up a fairly large ChatGPT Library, and one thing I learned is that a file still being visible in the UI does not necessarily mean the current execution container can successfully mount/access the underlying file.

In my case, some older files still had valid-looking metadata/references, but the backing storage could no longer be resolved. So your observation that the failure happens on ls, exists(), or basic /mnt/data access before Parquet parsing does make the mount/runtime layer worth investigating rather than pyarrow, Pandas, or the Parquet schema.

A few tests might help narrow it down:

  1. Upload a brand-new tiny .txt file to the same project and see whether Python can access that under /mnt/data.
  2. Try listing /mnt/data without referencing the Parquet filename at all.
  3. Try a new conversation/runtime inside the same Project and see whether the existing Project files remount there.
  4. If possible, test one of the affected files through ChatGPT’s normal file-reading path versus Python/container access. If ChatGPT can still read the file but Python cannot stat it, that strongly suggests a mount/provisioning issue.
  5. Record whether the failure affects only older uploads or also files uploaded right now.

Those tests should help separate:

  • an individual file/backing-storage problem,
  • a broken Project/conversation mount,
  • or a broader execution-environment failure.

I would also avoid re-uploading all of the large datasets until that distinction is clear. If the files are still valid Project assets, ideally resetting/reinitializing the execution runtime should remount them rather than requiring another multi-GB upload.

When reporting it, I’d include the exact ClientError, approximate time it started, whether a newly uploaded tiny file works, and whether the same Project files work in a fresh conversation. That should give the backend team much more to trace than the Parquet filename alone.

5

yeah i’ve found that container filesystems entirely disappear out from under the chat instance, particularly after a long session stalls or if you come back after leaving it unattended (no interaction) - the .git filesystem is “gone”. this is a regular recurrence not a one-off:

  • timeout on running pytest
  • interaction stalls (no messages get through, “we are processing yiur request”)
  • the square comes up prohibiting further messages
  • editing the “you look stuck how are you getting on” messages requires stopping the thread to resubmit
  • it then says “yes tooling failed, timeout, i’ll retry, oh no i can’t, the entire .git tree is gone, i’ll try to recreate it” and it has to start from scratch

that is quite different from this ClientError, it’s a routine occurrence on timeout of long-running commands where it doesn’t always recover.

6

Yeah, that distinction makes sense. What you’re describing sounds more like the execution container itself being lost/recreated after a timeout or stall, taking the ephemeral .git filesystem with it.

The ClientError case seems different because it appears to fail before any Parquet work or long-running command begins — even basic access to /mnt/data is failing.

That makes me think there may be at least two separate failure modes:

  • runtime/container loss after timeout or stall, where the working filesystem disappears;
  • file mount/backing-storage access failure, where the chat/project still knows the file exists but the execution environment cannot mount or access it at all.

We’ve also seen cases where file metadata remained visible while the underlying storage reference was no longer resolvable, so I wouldn’t assume a visible uploaded file guarantees that the current runtime can actually reach its backing data.

Your timeout example is still useful though, because it shows the execution environment can lose state independently of the conversation itself. The main thing I’d want to know in the ClientError case is whether a brand-new tiny file can be mounted successfully in the same project/runtime. That would help tell whether the failure is the whole container, the project mount, or just the older uploaded files.

7

aaand we’re back. no more ClientError on aiohttp. which annoyingly make repro of this case, including tiny file creation, irkesome. i’ll keep an eye out and if it ever happens again i’ll come back here to follow the procedure you suggested.

to the dev-team, if you sorted something “oops” quietly… thanks :slight_smile:

the timeout is much more routine so i could potentially put some standing instructions in or just remember to ask for tests rather than let it lose-and-recreate. thx clatkins27.

btw i’m not the OP.

8

Seeing something very similar here, started suddenly today

The ChatGPT app is working normally for me right now, including my regular Project work, but on web I can reproduce new Project attachments showing as attached and then not appearing in /mnt/data

I tested with a tiny 13 byte file. The same file worked in a normal non-Project chat, while Project chats on web failed, including a completely new empty Project. Tried another browser too and got the same Project failure

I checked the network log on one of the web failures and the upload itself looked normal. File create 200, raw storage upload 201, processing reached 100%, conversation request 200, no 4xx/5xx or browser network errors. But when the Project execution checked /mnt/data, the new file wasn’t there

I also made a completely fresh tiny zip with a different filename, size, hash and contents so it couldn’t be confused with an older upload. The chat metadata saw the new attachment, but /mnt/data still only had the older test zip and the fresh one wasn’t anywhere under /mnt or /tmp

One earlier web test looked like it worked, but that used the same zip bytes that were already present in the sandbox, so I don’t think it’s clean proof that a fresh web attachment mounted. Also noticed the filename shown in chat can differ from the one that ends up in /mnt/data, eg metadata can say file(2).zip while the sandbox gets file.zip, so checking only the expected filename can be misleading

So at least in my testing the app side is working normally right now, while fresh Project attachments on web are where I can reproduce the problem. Upload/storage itself seems to succeed, but the fresh attachment can fail to make it into the Project execution environment. Don’t know the exact backend cause, just sharing what I found in case it helps narrow it down

9

im having the exact same issue along with some others inside of the web version.
it cant read a 4kb zip in the project but it was able to read the same file outside the project.
tried renaming, trying to repack/rename it etc, but nothing worked.
it was able to read non zip files such as a .txt inside of the project tho.
originally I was at 19/20gb storage used and freed up space, also tried deleting some of the chats inside the project but that did not resolve anything.

other oddities ive had in the past day or so is chunks of chat being deleted, other chats bleeding together such as it saying it couldn’t fulfill my request inside of image generation mode despite not asking for any sort of generation.
then after failing to accept the zip it then brought in outdated and irrelevant files from my google drive and understood/agreed after I pointed out the mistake.
it was also failing to send a google drive access notification request then going dead silent as a result.

10

Another possibly related thing I hit today which is a bit more worrying

With the new 25-26 min cutoff I had some testing/experiment running in the temporary workspace, some of it had already finished successfully but after the interruption the execution environment had reset and the whole temporary working directory was gone

So it wasnt just the current test getting stopped, files/state from work that had already completed were gone too

Im not saying the 25-26 min cutoff definitely caused the workspace reset, this is the first time Ive seen it happen so I dont have enough evidence to say that, but with the timing and the other recent /mnt/data and execution environment issues here it feels worth mentioning

Anyone else seen this recently, like hitting the 25-26 min cutoff and then finding the temporary workspace/container was reset instead of just the current run stopping?

11

I’m seeing what looks like a closely related variant of this issue today, August 31, 2026, specifically inside a ChatGPT Project.

Environment

  • ChatGPT Plus
  • ChatGPT web
  • Windows 11
  • Chrome 152
  • Existing long-running Project
  • GPT-5.6 Sol

File involved

A normal ZIP deployment archive, only about 13–14 MB. This is a source-code repository ZIP, so nowhere near any individual file-size limit.

What happens

The upload appears to succeed normally in the UI. ChatGPT then receives attachment metadata including a concrete internal path, for example:

/mnt/data/php-gallery-deploy(20260831-101204).zip

However, when the execution environment actually tries to use that exact file, it is not there.

I reproduced this several times. Examples:

  • Aug 31, ~12:07:23 CEST: php-gallery-deploy(20260831-100723).zip
  • Aug 31, ~12:08:21 CEST: php-gallery-deploy(20260831-100821).zip
  • Aug 31, ~12:12:04 CEST: php-gallery-deploy(20260831-101204).zip

In my case the symptom is slightly different from the ClientError reported in the original post:

  • Python checking the declared path reports that the file does not exist.
  • The container/filesystem check reports No such file or directory.
  • A second independent Python execution environment also reports that the path is not a file.

So, just like the original report, this fails before ZIP parsing or application-level processing even begins. The ZIP contents are irrelevant because the runtime never gets access to the uploaded bytes.

What makes this particularly interesting is the control test:

I uploaded the same current source ZIP outside the Project, in a normal ChatGPT conversation, and it worked there.

The file was accessible to the runtime and ChatGPT could work with it normally.

Therefore the relevant variable appears to be:

normal chat -> works

Project conversation -> upload accepted, /mnt/data path assigned, file absent from runtime

This also makes a browser extension, proxy, ZIP corruption, or general upload-size issue much less convincing, since the same browser/account/file combination works outside the Project.

Storage/quota information

My account storage is only:

3.42 GB / 20 GB

so I am nowhere near the overall storage limit.

Another strange detail is that these failed ZIP uploads do not appear in my Files list afterward. I also cannot find a Project-specific file list or file counter in the current UI.

OpenAI Support confirmed to me that there currently is no documented UI location showing the per-Project file count or the remaining rolling upload quota. They also mentioned that failed uploads can sometimes count against the rolling upload limit, but there is no user-visible way to inspect that quota.

I have reported this through OpenAI Support as:

Case #14080200

The support case includes the timestamps above and the repeated /mnt/data mount failures.

From the behavior, my suspicion is that the upload/attachment registration succeeds far enough for the conversation to receive metadata and an expected /mnt/data/... path, but the backing object is never successfully mounted/provisioned into the Project’s execution sandbox.

So this may not be exactly the same failure mode as the ClientError in the original post, but it looks like it could be in the same Project file storage → execution sandbox mount/provisioning layer.

If anyone else is seeing this, I think an especially useful test would be:

  1. upload the same file inside a Project;
  2. verify whether /mnt/data/<filename> actually exists from Python/container;
  3. upload the same file in a normal non-Project chat;
  4. compare the result.

In my case that A/B test is currently reproducible: Project fails, normal chat works.

I’ll update this thread if Support confirms anything on Case #14080200.

12

Can confirm. Projects dont link uploaded files into mnt/data. Regular chat works as expected. Started today. Multiple projects includin new ones. so not the limit issue

13

Have you tried manually uploading file to the storage outside chat and then within chat using attach from library?

image
image600×191 3.71 KB

image
image1135×291 8.44 KB

14

Confirm that works( replyto Slavax if link broken), however that’s a workaround, and it doesn’t solve the underlying main problem at all. Something broken and should be fixed anyway.

15

Same issue, none of the files i upload be it directly or linked through library, get “mounted”. Chatgpt says it sees the files but cannot interact with them because the bridge between the upload space and workplace sandbox is broken. Also, EVERYTHING is gone from the sandbox, including tons of current work. Amazing.

16

I’m seeing the same issue today.

Environment:

  • OS: Windows

  • Browsers: Chrome and Edge

  • Incognito/InPrivate mode: same behavior

Reproduction results:

  1. Regular Chat

    • ZIP upload: succeeds

    • TGZ upload: succeeds

  2. Project → existing conversation

    • ZIP/TGZ upload: succeeds in the UI

    • Attachment is recognized

    • Sandbox mount fails

    • The expected /mnt/data/... file is not accessible

  3. Project → existing conversation → moved/changed to Regular Chat

    • ZIP/TGZ upload: succeeds in the UI

    • Sandbox mount still fails

    • The expected /mnt/data/... file is not accessible

  4. Project → new conversation

    • ZIP/TGZ upload: succeeds in the UI

    • Attachment is recognized

    • Sandbox mount fails

    • The expected /mnt/data/... file is not accessible

I also reproduced the issue in both Chrome and Edge private/incognito sessions, so it does not appear to be caused by browser cache or an existing login session.

I checked the browser Network panel while reproducing it and did not observe an obvious 4xx or 5xx response associated with the file upload.

So from the client side, the upload appears successful, but the uploaded attachment is not being made available to the execution sandbox under /mnt/data.

This appears specifically related to the Project conversation → sandbox file mount path, rather than the upload UI itself.

Additional reproduction information:

I tested the same issue across different client/network environments.

  • Windows ChatGPT Classic desktop app

    • Upload succeeds in the UI

    • Sandbox mount still fails

  • Same laptop, different network

    • Disconnected the wired LAN

    • Switched to a mobile phone hotspot over Wi-Fi

    • Same sandbox mount failure

  • Different PC in a different physical location

    • Same issue reproduced

So far, the issue is reproducible across:

  • Chrome

  • Edge

  • Incognito / InPrivate sessions

  • Windows ChatGPT Classic desktop app

  • Wired network

  • Mobile hotspot

  • Different PCs

  • Different physical locations

This makes a browser-specific, local-machine-specific, local-network, or ISP-related cause increasingly unlikely.

The consistent failure remains:

Attachment upload appears successful → attachment metadata is created → file is not mounted/accessible in the sandbox under /mnt/data.

Regular non-Project chats have successfully handled ZIP/TGZ uploads in comparison, while Project-related conversations reproduce the sandbox mount failure.

Additional finding — the issue appears to differ between Work mode and regular Chat mode inside the same existing Project.

Using the same existing Project and the same type of ZIP archive:

Existing Project → New conversation → Work mode

  • ZIP upload succeeds

  • /mnt/data sandbox mount succeeds

  • ZIP can be opened

  • Archive extraction succeeds

  • Extracted Markdown file can be read normally

Existing Project → New conversation → Regular Chat

  • ZIP upload succeeds in the UI

  • Sandbox mount fails

  • Expected /mnt/data/...zip file is absent

  • ZIP cannot be extracted

Existing Project → Existing conversation → Regular Chat

  • Same sandbox mount failure

This is important because the Project, file type, account, browser/network environment, and upload flow are otherwise the same.

The variable that changes the result is the conversation execution mode:

Work mode → mount works
Regular Chat mode → mount fails

This suggests the problem may be specific to the regular-Chat Project attachment → execution-sandbox materialization/provisioning path, rather than Project storage or ZIP handling in general.

For now, creating a new Work-mode conversation inside the same Project appears to be a viable workaround for ZIP extraction and sandbox file access.

17

I’m experiencing the same issue. Files uploaded inside a Project are not accessible, while the same files are correctly found when uploaded in a chat outside the Project.

18

What worked for me is either staying inside the windows app which I personally despise (no hate but it’s missing things such as message counter and thinking which I did in an extension)

Or uploading files manually to library outside project then after refresh linking them inside a project message

Some people said it doesn’t help so I can only assume it’s either random or my workaround was perhaps misunderstood

19

Btw, the original post being posted 19 days ago. It aligns with me losing majority of initial work around that same time as it was posted

20

Same problem here for over 3 hours. The interesting thing is I was able to get the file mounted as expected when uploading from another device with a different connection. Wondering the issue is on my end or not. Any ideas on how to debug this?