Project Files Visible but Not Accessible for Over a Month, Across All Devices and Projects (Sandbox Token / Permission Bug)

ChatGPT Bugs
1

I’ve had a persistent Project Files bug for 6+ weeks, and Support has unfortunately only provided the same boilerplate troubleshooting steps over and over (logout, clear cache, try a different browser, disable extensions, try a different device, etc.). None of these apply to the issue, and nothing has changed.

I really need this escalated properly, because this is clearly a backend problem.

The Bug

In every Project:

  • Files are visible,

  • But not readable,

  • And not writable,

  • Status always returns “Locked”.

This happens for every file, across multiple projects, including files created and uploaded by me.

Troubleshooting Already Done

This issue persists across:

  • laptops, desktops, mobile

  • Chrome, Safari, Edge

  • incognito/private mode

  • cache cleared

  • all extensions disabled

  • multiple networks

  • logging out everywhere

  • reinstalling the iOS app

Nothing resolves it.

Why This Is Not a User Issue

These are personal, non-shared projects, so permissions cannot be the issue.

This behavior matches a sandbox token / project container desync, not a client-side or permissions issue.

Impact

All Projects have been unusable for over a month because ChatGPT cannot open, read, or write to any file.

Request

I need this escalated to Engineering/Infrastructure for:

  • a sandbox token refresh, or

  • a project environment reset, or

  • any backend fix that restores normal read/write access.

  • I can provide screenshots or screen recordings if needed.

If you want, I can also create a very blunt/angry version, a hyper-technical version, or a version with timestamps and logs.

I have gotten nothing but the runaround from support so I’m hoping someone can please help me resolve this longstanding issue. Thanks.

3

Hi, this issue is reproducible at the API/tooling layer, not only the ChatGPT UI.

I’m reporting it here because project file access uses the same underlying sandbox/container infrastructure exposed to developers building tools, and the bug affects read/write permissions at the environment level.

This isn’t a general “ChatGPT support” question.

It’s a persistent sandbox permission failure that appears to be the same environment used for MCP/custom tool execution, so it is relevant to developers using OpenAI’s platform.

Support has not been able to escalate this, and I’m hoping a technical moderator can take a look or confirm whether this is a known infrastructure issue.

If this still belongs elsewhere, please let me know where infrastructure-level bugs should be reported, since the standard support channel is looping.

Thank you.

5

I encountered the same issue as well. ChatGPT keeps telling me to re-upload files even though the files are visible.

6

I want to highlight that the project files regression described in this thread isn’t just a minor inconvenience; it has rendered the Project Files feature unusable for structured multi-session workflows that depend on persistent, reliable file access.

Specifically:

  • Files appear as uploaded but the assistant cannot access them, or only reads partial/hallucinated content instead of actual file contents.

  • Project files are not actually accessible across chats within the same project. This breaks fundamental assumptions about project persistence.

  • Users report that this happens cross-platform and remains unresolved even after re-uploading, browser refresh, clearing cache, creating new projects, or switching devices.

For users building multi-threaded, document-heavy workflows, this bug eliminates the core value of the Projects feature. It forces constant manual re-uploading, breaks continuity, undermines institutional knowledge capture, and ultimately prevents projects from functioning as advertised.

Request to the OpenAI devs / engineers:

  1. Please acknowledge whether file persistence across chats/projects is intended to work under current product definitions.

  2. If it is intended, please provide a timeline for a fix or rollback that restores reliable file access.

  3. If it isn’t, clarify the product messaging so users don’t build workflows on a broken assumption.

Project Files are a paid feature for many of us, and restoring this functionality is vital for real multi-session project continuity.