Chat attachments inside Projects intermittently fail to materialize into /mnt/data, while File Library and Project Sources work

ChatGPT Bugs
,
1

Hi everyone,

I’m experiencing what appears to be an intermittent ChatGPT Projects attachment-to-execution-sandbox issue, and I’d like to know whether anyone else can reproduce it.

The problem is not simply that the upload fails.

In affected cases:

  • The uploaded file appears normally in ChatGPT.
  • The file is present in File Library and can be opened there.
  • ChatGPT’s document/file parsing layer can often read the content correctly.
  • However, when I ask ChatGPT to actually use Python to inspect the execution environment, the corresponding binary file is missing from /mnt/data.

For example, a small TXT file containing only 123456 can be read correctly by ChatGPT, while Python reports:



/mnt/data/321321321.txt

exists: False
is_file: False
size: None
SHA-256: None

I refer to this state as NOT_MATERIALIZED simply as a diagnostic label; it is not an official ChatGPT error code.

I performed several controlled A/B tests:



Non-Project chat + direct upload
→ PASS

Same conversation moved into a Project + new direct upload
→ FAIL

New conversation created directly inside a Project
→ FAIL

Brand-new Project + brand-new conversation
→ FAIL

Same files added through Project Sources
→ PASS

When files are added through Project Sources, TXT, DOCX and ZIP files become real binary files in /mnt/data; ZIP extraction and DOCX/OOXML access work normally.

I also reproduced the failure on another computer using Chrome, so it does not appear to be specific to my original PC, Microsoft Edge, or local browser profile.

I have also seen the behavior across more than one account. An iOS upload succeeded at least once, however, so the failure is intermittent rather than universal.

I tested whether this was simply delayed synchronization. For one uniquely named TXT file I checked /mnt/data at approximately:



T+0 min  → missing
T+1 min  → missing
T+3 min  → missing
T+5 min  → missing

Meanwhile, the same file was already visible and openable in File Library.

Interestingly, some files that were initially missing from /mnt/data appeared much later, suggesting that delayed or inconsistent materialization may also occur.

My current interpretation is therefore:



Upload / storage                PASS
File Library                   PASS
File parsing                   PASS
Project chat attachment
      ↓
execution sandbox handoff      INTERMITTENT FAIL
      ↓
/mnt/data

Current workaround: adding files through Project Sources instead of attaching them directly to the Project conversation. For workflows requiring ZIP extraction, DOCX/Excel editing, or other binary file operations, this has been much more reliable.

I have already escalated the issue to OpenAI Support and provided the reproduction details.

Has anyone else observed the same difference between:

direct attachments inside Projects vs Project Sources, especially when checking the actual /mnt/data files with Python?

If so, it would be useful to compare whether it depends on account, model, platform, or Project state.

2

I’ve been experiencing this problem for 32 hours. very angry…

3

Same problem. Zips or MOV files are uploaded but non-accessible by GPT. Two days already

4

Same problem. PDFs for me. Exact same experience where it works outside of projects with direct upload even but exact same task fails within a brand new blank project!

5

Same problem. I’ve been experiencing this problem for 32 hours.

6

Absolutely the same problem here. I’m on ChatGPT Pro, and it has been going on across all of my chats for more than 26 hours now.

Newly attached files show up in the conversation, but ChatGPT cannot actually access them from the execution runtime. Screenshots/images are the only attachments that still work for me. ZIPs and other files are basically unusable, so work across all of my projects has completely stopped.
At this point ChatGPT is basically only useful for asking for a soup recipe. I literally just tested it again in brand-new conversations across several different Projects — still completely broken. No change at all.

7

Update:

The issue appears to be working normally again for me at the moment.

I re-tested direct file uploads inside a Project using three small files:

  • TXT
  • ZIP
  • DOCX

This time, all three were successfully materialized into the execution environment under /mnt/data.

I verified this with Python rather than relying only on ChatGPT’s attachment parsing layer:

  • exists=True
  • is_file=True
  • file sizes were correct
  • SHA-256 hashes could be calculated
  • the ZIP could be opened and extracted
  • the DOCX could be opened as a valid OOXML/ZIP container

I also tested another TXT file immediately before this, and that upload worked as well.

So I now have two consecutive successful tests.

However, I do not think this proves that the underlying issue is permanently fixed yet, because the previous behavior was intermittent.

Earlier, I was able to reproduce the following pattern multiple times:

  • non-Project chat + direct upload → PASS
  • same conversation moved into a Project + new direct upload → FAIL
  • new conversation created inside a Project → FAIL
  • brand-new Project + new conversation → FAIL
  • adding the same files through Project Sources → PASS

In the failure state, the file was already present in File Library and could often be parsed by ChatGPT, but Python reported that the corresponding file did not exist in /mnt/data.

I also reproduced the issue on another computer using Chrome, which made a local browser or Windows-specific cause less likely.

Interestingly, some files that were initially missing from /mnt/data appeared much later, so the issue may have involved delayed or inconsistent attachment materialization.

For now, direct uploads inside Projects are working again for me. I will continue monitoring it for the next day or two.

If anyone else who had the same problem can re-test now, especially by checking the actual /mnt/data file with Python, it would be useful to know whether this was a broader backend recovery or just an intermittent improvement.

8

he issue is still reproducible on our side.

We tested with multiple users on Windows 11 and the latest version of Chrome.

Direct uploads in regular chats work correctly, while uploads inside ChatGPT Projects fail most of the time. The files appear in the conversation but are often not materialized in the execution environment.

Since the issue is still affecting multiple users, could this be reviewed again?

9

Hi Luca, thanks for following up. I’m sorry you’re still running into this. We recently shipped some fixes for attachment access, and I’d like to understand what we’re still missing.

Could you try uploading a small, non-sensitive TXT or ZIP directly into a new Project chat, then ask ChatGPT to open it using Python?

If it fails, could you share:

  • The conversation link and approximate time of the failure, including your time zone.
  • Your plan and selected model, and whether the Project is private or shared.
  • Whether the uploaded file also appears in your Library.
10

I am having multiple failures today, worked yesterday, on having any type of .py files downloaded. I believe my recent inability to receive working downloadable files may be related to the Project/file-mount/runtime system, particularly /mnt/data, rather than to the individual prompts or file-generation instructions.

What I observed:

  • I am working inside a ChatGPT Project with a large set of Project files and uploaded ZIPs.

  • The assistant can often acknowledge, search, and read files through the Project/uploaded-file layer.

  • In several cases, the assistant later cannot access the same material reliably at the physical /mnt/data execution path required for ZIP extraction, hashing, file creation, and downloadable sandbox links.

  • I have seen ZIPs reported as uploaded/readable but later unavailable, zero-byte, or not usable by the execution environment.

  • On September 2, the assistant successfully verified that my Step 4 source ZIP existed in /mnt/data, opened it, read both members, and confirmed their exact bytes and SHA256 values.

  • During the subsequent build, however, the generated output files that should have been written to /mnt/data were not actually present. The assistant nevertheless initially returned sandbox download links, then later discovered that the target files did not exist.

  • Runtime remnants from that attempt showed messages such as NO_CANDIDATE_ROOTS, MISSING_NEW_MODULES, and an incomplete-candidate hold. The expected generated Python modules were absent.

  • I have experienced several similar failures in different chats on the same day, including chats acknowledging files successfully and later reporting that they could not access or use them.

Why I suspect a connection:

ChatGPT appears to have at least two distinct file-access layers in this workflow:

  1. A Project/uploaded-file layer that allows the model to see, search, or reference files.

  2. An execution/runtime filesystem, including /mnt/data, that is required to physically open ZIPs, generate new files, read them back, calculate hashes, and serve working sandbox downloads.

My concern is that these two layers are becoming inconsistent. A file can appear available to the conversation while not being reliably mounted or retained in the execution runtime. If the runtime mount resets, fails, or changes during a long operation, downloadable artifact generation can fail even though the source files remain visible to the model.

I am not claiming that /mnt/data is definitively the root cause. That is my inference from the repeated pattern. The directly observed problem is that file visibility/readability at the conversation or Project level has not consistently guaranteed physical byte-level availability and persistence in the execution filesystem.

This is particularly disruptive for my workflow because I require a strict artifact gate:

create file → verify exact /mnt/data path exists → reopen/read back → validate → calculate bytes/lines/SHA256 → provide sandbox download link.

Until recently this workflow worked reliably. I am now seeing repeated failures where the conversation can access the source material but the generated or mounted execution files are missing or become unusable.

I would appreciate investigation into whether there are current issues involving:

  • Project files being mounted into execution runtimes;

  • synchronization between Project/file-library access and /mnt/data;

  • persistence of /mnt/data during longer tool executions;

  • ZIP attachment mounting;

  • generated artifact persistence;

  • sandbox download links pointing to runtime files that were not successfully retained;

  • differences between Project chats, branched Project chats, and ordinary standalone chats.

The repeated same-day failures make me concerned this is a systemic runtime/file-mount issue rather than an isolated prompt or model mistake.

No Chat link - got deleted

Failed on Chrome / Mac ap - doesn’t matter what it is

Chat GPT PRO PLAN - using Chat GPT 5.6 Pro

Project is Private

Worked yesterday, was using the library to upload and linking, able to download new files, today i was able to one time confirming mounting via upload in chat, but problem now is the creation and downloading of new files.

11

here is more info from another chat that could not create downloadables either. I believe OpenAI is already aware of the current attachment/project-file issue involving /mnt/data, but I want to flag an additional impact that may not be obvious: the same problem is also preventing ChatGPT from successfully creating and delivering new downloadable artifacts.

I have now reproduced this across multiple fresh chats/builders in a ChatGPT Project.

The failure has two sides:

1. Input files sometimes fail to materialize into /mnt/data.
A ZIP uploaded through the Project Library can appear normally in the UI and be recognized by ChatGPT, while the execution environment sees:



PATH=/mnt/data/<file>.zip
EXACT_PATH_EXISTS=YES
ACTUAL_BYTES=0
ZIP_OPEN=FAIL

In some cases, Markdown/text files remain readable through ChatGPT’s uploaded-file/project-file system even though their /mnt/data representation is zero bytes. ZIP contents, however, cannot be recovered through that alternate route.

2. More importantly, output/download creation is also failing.

In one Builder run, ChatGPT successfully created and validated the requested new source files in a temporary working directory:



/tmp/track10h_f_step4_draft/

The candidate files passed their checks. However, the finalization step that was supposed to place the approved downloadable artifacts at:



/mnt/data/workflow_intake_ops.py
/mnt/data/workflow_intake_serializers.py

never completed. The final check reported:



INTERRUPTED_ATTEMPT_CANDIDATE_NOT_FOUND

As a result, ChatGPT could not provide the required working download links even though the actual code generation had succeeded.

A second fresh Builder could not even start because its input ZIP appeared at the correct /mnt/data path but had ACTUAL_BYTES=0.

I have also found an important workaround/data point: uploading the same ZIP into the Project Source section, rather than only the Project Library/message attachment path, successfully materialized the physical ZIP. On that attempt ChatGPT verified:



ACTUAL_BYTES=37350
ZIP_OPEN=PASS
ZIP_INTEGRITY=PASS

and independently verified both files inside against their expected SHA-256 hashes.

So this appears to be more than an attachment-reading problem. It looks like there may be an intermittent failure in the handoff between Project/Library file storage ↔ execution sandbox /mnt/data, and that same filesystem/materialization problem can affect both incoming files and newly generated outgoing downloadable artifacts.

This is significant for workflows that rely on ChatGPT to generate code, proofs, documents, ZIPs, or other downloadable files: the model may complete the work correctly but still be unable to deliver the resulting artifact.

Observed pattern:



UI/file reference exists
→ ChatGPT recognizes the attachment
→ /mnt/data pathname may exist
→ physical file is zero bytes or fails to materialize
→ ZIP/file cannot be opened
→ Builder must stop

And on output:



candidate artifact generated successfully
→ candidate checks pass
→ final /mnt/data materialization/finalization fails
→ downloadable artifact cannot be provided

Please make sure the engineering investigation covers outbound artifact creation/download delivery as well as inbound attachment mounting, because I have now experienced both manifestations of what appears to be the same underlying /mnt/data problem. |.

chat id: available upon request

Failed on Chrome / Mac ap - doesn’t matter what it is

Chat GPT PRO PLAN - using Chat GPT 5.6 Pro

Project is Private

Worked yesterday, was using the library to upload and linking, able to download new files, today i was able to one time confirming mounting via upload in chat, but problem now is the creation and downloading of new files.

12

This is absolutely NOT fixed, it has been affecting every chat session over the past 2 to 3 days and shows no sign of stopping! Basically this makes the service unusable and should be marked as ABSOLUTELY CRITICAL FOR IMMEDIATE ESCALATION!!!

Here is what ChatGPT itself says, in so many words, over and over again every time I try to get it to work right:

```
The uploaded attachments themselves are not exposed to me as a filesystem directory; they are in the attachment/search store, which has no path I can ls. The only filesystem path I checked for mounted uploads is /mnt/data, so I’m running ls -laR /mnt/data now, then I’ll return immediately to the Phase 3 fix work.

bash -lc ls -laR /mnt/data

Exact command result:

/mnt/data:
total 12
drwxrwsr-x 1 oai  oai_shared 4096 Sep  3 01:51 .
drwxr-xr-x 1 root root       4096 Aug  3 18:26 ..

So there is no mounted upload directory available in this runtime.
```

PLEASE PLEASE PLEASE FIX THIS IMMEDIATELY!!! WORK CAN NOT PROCEED!!!

13

Hi Pansul,
thanks. I was able to reproduce the issue again in a completely clean Project, using only a synthetic non-sensitive Excel file created specifically for this test.
The Project contains no customer, employer, production, or corporate project data.
Test details:

  • Project name: Try Upload Mount Project

  • File: OpenAI_Mount_Test_Carotaggio_BUG_SYNTHETIC.xlsx

  • File content: entirely synthetic test data

  • Upload method: direct attachment upload into a new Project chat

  • Date: September 3, 2026

  • Approximate time: [TIME]

  • Time zone: Europe/Rome (UTC+2)

  • Plan: [PLAN]

  • Selected model: [MODEL]

  • Project: [PRIVATE / SHARED]

  • File also visible in Library: [YES / NO]

  • Browser/platform: Chrome on Windows

Conversation link:
[PASTE FULL CONVERSATION LINK]
The issue reproduced successfully.
The attachment was visibly accepted by the chat, but when ChatGPT checked the execution environment, it reported that the expected file:
/mnt/data/OpenAI_Mount_Test_Carotaggio_BUG_SYNTHETIC.xlsx
was not present.
It also checked /mnt/data directly and reported that the directory was empty.
So the observed sequence was:
upload accepted by the Project chat ¡ú attachment visible in the conversation ¡ú execution runtime available ¡ú expected attachment missing from /mnt/data.
I have attached a screenshot of the reproduction as well.
Because this test was performed in a clean Project with a completely synthetic XLSX, I can safely share this conversation with you and it should remove any dependency on customer data, Project Sources, file content, or corporate documents.
This appears to be the same intermittent issue I originally reported: the chat attachment is registered successfully in the UI but does not materialize into the execution sandbox.
Please let me know if there are any additional diagnostics, IDs, or another test sequence you would like me to run in this clean Project.
Thanks,
Luca

(Attachment OpenAI_Mount_Test_Carotaggio_BUG_SYNTHETIC.xlsx is missing)

14

I can reproduce this issue as well, and I have a few additional observations that may help narrow it down.

Environment

  • Plan: ChatGPT Plus

  • Affected area: ChatGPT Projects

  • Reproduced in at least two different Projects

  • Reproduced across different chats; different chats inside the same Project can behave differently

  • Approximate period: September 1–3, 2026

  • Model: [insert the model shown in the affected chat]

  • Project type: [private/shared]

Observed behavior

The failure appears to involve a separation between the document/search layer and the execution sandbox.

In an affected Project chat:

  1. A DOCX file is visible normally in the Project/chat.

  2. ChatGPT can sometimes search or parse its textual content.

  3. Information from the file can therefore appear available to the assistant.

  4. However, the actual file is not reliably available to the execution environment in /mnt/data.

  5. Operations requiring direct filesystem/runtime access fail: direct DOCX parsing, editing an existing DOCX, creating an updated DOCX, etc.

  6. In my case, the runtime/file tools also repeatedly return:

InvalidArgumentError

This can happen even on very simple execution attempts, before meaningful document processing occurs.

I have also reproduced the /mnt/data problem itself, so the InvalidArgumentError appears to be an additional symptom rather than the only failure.

Intermittent / Project-specific behavior

The behavior is not stable:

  • One Project was affected.

  • I moved the same general workflow and sources to another Project, where it initially worked.

  • The same failure later appeared in the second Project as well.

  • Different chats inside the same Project can sometimes have different runtime/file availability.

  • Outside Projects, I have been able to create DOCX files successfully.

Because of this, it does not look like a corrupt individual DOCX file or a simple account-wide DOCX-generation limit.

Important additional impact: silent correctness risk

There is a potentially serious failure mode beyond simply being unable to create a downloadable file.

Because the semantic/search/document layer can remain available while the primary binary file is unavailable to the execution environment, ChatGPT may still appear capable of analyzing the document.

In a real long-document workflow, I observed a case where the assistant was supposed to analyze the primary manuscript but did not actually have reliable access to that manuscript text. Other derivative Project documents remained searchable.

The assistant then produced a plausible, structured analysis that was factually inconsistent with the actual manuscript.

We detected the problem only because we manually required direct quotations from the beginning, middle, and end of the primary source and compared the output with the manuscript.

This means the issue can potentially cause more than a visible file-operation failure:

primary file unavailable to runtime
→ secondary/searchable material still available
→ assistant continues the task
→ plausible but incorrect analysis

For document-heavy professional workflows, this is significantly more dangerous than an explicit “file unavailable” error.

Expected behavior

If the primary file cannot be reliably accessed, the assistant should either:

  • still receive the actual file in the execution environment, or

  • explicitly report that the primary source is unavailable.

It should not silently continue a source-dependent analysis using only search results, derived documents, or partial material.

Minimal reproduction pattern

  1. Create or open a ChatGPT Project.

  2. Add a small non-sensitive DOCX/TXT file as a Project source or direct attachment.

  3. Confirm that ChatGPT can see/read/search the file.

  4. Ask ChatGPT to inspect the actual execution filesystem and access the same file directly.

  5. Check /mnt/data.

  6. In affected sessions, the source is visible/readable at the ChatGPT document layer but missing or unusable in the execution runtime.

  7. Attempts to perform filesystem/document operations may additionally return InvalidArgumentError.

The issue has persisted intermittently across multiple days and Projects.

I am happy to provide a conversation link from a separate non-sensitive reproduction chat if that would help. I prefer not to publish the main affected Project conversation because it contains private manuscript material.

15

It seems to be working now at least for the moment, can anyone else please confirm?

16

Issue: Intermittent failure when using “Upload files from phone” in the ChatGPT iOS app

Latest reproduced: September 6, 2026, approximately 6:12–6:16 PM PDT (UTC−07:00)

Environment

  • iOS: 26.6.1
  • ChatGPT app: 1.2026.237
  • Subscription/workspace: ChatGPT Team/Business, standard tier
  • Connection: Reproduced on both Wi-Fi and cellular. Connection type and signal strength do not appear to affect the issue.

Important distinction
Photo and video attachments work normally.

The failure appears specific to the “Upload files from phone” workflow for selecting ordinary files from iOS Files.

For example, I was able to attach a screen recording through the photo/video attachment interface while the “Upload files from phone” workflow was simultaneously failing.

Behavior
New file attachments selected through “Upload files from phone” intermittently fail before the upload itself appears to begin.

Steps to reproduce:

  1. Open a ChatGPT conversation.
  2. Open the attachment menu.
  3. Choose “Upload files from phone.”
  4. Select a file from the iOS file picker.
  5. Tap Open.
  6. Instead of returning to the conversation with the selected file shown as an attachment in the chat composer, the interface returns to the Files/Library selection interface.
  7. No attachment is added to the chat.

The problem affects multiple conversations and multiple types of ordinary files.

The failure is intermittent. The same file-upload workflow will occasionally begin working normally again and then later stop working with the same behavior.

Uploading files directly into ChatGPT Library also works. However, this is not an equivalent workaround because newly uploaded Library files may not immediately be indexed/searchable or readily selectable for use in a conversation.

Unaffected attachment paths

  • Photos: working
  • Videos: working
  • Direct upload to ChatGPT Library: working

Affected attachment path

  • Upload files from phone / iOS Files picker: intermittently failing

Troubleshooting already performed

  • Updated ChatGPT to the latest available app version.
  • Force-closed and restarted the ChatGPT app.
  • Checked account/file-upload limits.
  • Tested multiple conversations.
  • Tested multiple file types.
  • Tested both Wi-Fi and cellular connections.
  • Tested under different signal conditions.
  • Confirmed photo/video attachment continues to function while file attachment fails.

The problem has persisted intermittently since approximately September 4, 2026.

A screen recording captured on September 6, 2026 at approximately 6:16 PM PDT demonstrates the failure in real time: Upload files from phone → file selected → Open tapped → interface returns without adding the selected file to the chat composer.

Can provide screen recording/shared chat link, if needed.

17

Hi Luca,

Thanks for all the help. We investigated further and deployed additional fixes. Since our deployment we haven’t been able to reproduce the original missing-file issue in recent testing, but given its intermittent nature, we’d appreciate your confirmation.

Could you repeat the same test in a new Project chat and check whether Python can now open and read the uploaded file? If it still fails, could you please share a link to the synthetic-only conversation, the approximate time and time zone, your plan and selected model, and any error or redacted screenshot. There’s no need to share private documents.

Thanks,
Pansul

18

Hi Pansul,

Thank you for your follow-up and for the effort your team put into investigating and addressing this issue.

I repeated the test following your instructions and, so far, I have not been able to reproduce the problem again. The uploaded file was successfully available to Python and could be opened and read without any issue.

This is very encouraging and suggests that the fixes recently deployed have resolved the behavior I was experiencing.

I’d also like to compliment you and the team for the prompt response, transparency, and commitment throughout the investigation. It is genuinely appreciated to see such proactive engagement with community feedback and such a quick turnaround on a complex intermittent issue.

Thank you again for your support and professionalism. I will continue to keep an eye on the behavior in future tests and will report back if I observe anything unusual.

Best regards,

Luca Esposito

19

Hi Luca, thanks for testing this again and for being so methodical throughout. Your clear repro steps and careful follow-ups really helped us investigate. We are glad your latest test is working, and we genuinely appreciate the time and patience you’ve put into helping us get this right. If you encounter any other issue - feel free to let us know.

20

Still the Same issue is observed here where in Project when we are asking to build the deck it shows the error as

“can’t safely build and deliver the July deck from the available runtime data alone. still cannot be accessed by the execution runtime” and asking to upload as CSV files ..