[ChatGPT Projects] Files moved between Projects keep visible attachment references but become inaccessible to the assistant/runtime

Summary

Files that were moved from one ChatGPT Project to another remain visible/referencable in the destination Project, but the assistant cannot actually read them.

The UI/context still resolves the filenames and exposes attachment/file references, yet attempts to access the underlying files from the assistant runtime fail as if the blob is no longer bound to the destination Project.

This looks like a Project migration issue where attachment metadata survives the move but the underlying file/blob association or indexing does not.

This report concerns first-party ChatGPT Projects rather than Codex itself. I am filing it here because there does not appear to be a dedicated public GitHub tracker for ChatGPT Projects bugs, and first-party ChatGPT Project issues are already being tracked in this repository (for example #40201). Please transfer or route internally if another tracker is preferred.

Environment

• Product: ChatGPT Web
• Feature: Projects / project files / moved artifacts
• Account: paid ChatGPT plan
• Date observed: 2026-09-11
• Affected file types observed: .zip, .tar.gz

What happened

I had three binary/toolchain artifacts in one ChatGPT Project and used the product's Move functionality to move them into another Project.

In the destination Project:

• the files are still visible enough to be referenced by filename with @...;
• the conversation context reports stable attachment/file IDs for all three files;
• the assistant is even given apparent sandbox paths such as /mnt/data/<filename>;
• however, the underlying files are not actually available to the assistant runtime.

Two independent access paths failed:

1. Direct runtime access to the exact /mnt/data/... paths reported for the attachments returned No such file or directory / exists() == false.
2. Uploaded-file search for the current conversation returned no retrievable file objects for those attachments.

Repeating the @filename reference in later messages does not repair the attachment. The UI still resolves the same logical files, but the assistant still cannot access their bytes.

Steps to reproduce

The exact sequence on my account was:

1. Have files attached/stored in ChatGPT Project A.
2. Use the ChatGPT UI to move those files/artifacts from Project A to Project B.
3. Open or continue a conversation in Project B.
4. Reference the moved files by filename using @filename.
5. Ask ChatGPT to inspect/read the files.
6. Observe that the filenames resolve and attachment metadata/file IDs are present, but the assistant cannot read the actual files.
7. Ask the assistant to retry through direct runtime access and uploaded-file search.
8. Both fail even though the attachments are still represented in the conversation/project UI.

I have not yet tested whether downloading the files locally and uploading them again as brand-new files into Project B creates new working file IDs, but that is the expected workaround.

Expected behavior

Moving a file between ChatGPT Projects should be atomic from the user's perspective:

• the destination Project should receive a valid file/blob association;
• the assistant should be able to read the moved file exactly as before;
• file search/indexing should resolve the moved object;
• any generated runtime attachment path should point to an actually mounted/available file.

If the move cannot preserve the existing file object, the product should create a new valid file object in the destination Project and update references accordingly.

Actual behavior

The destination Project appears to contain an orphaned or half-migrated attachment state:

Project A
  └─ file object / blob
        ↓ Move
Project B
  └─ visible filename / attachment reference / file ID
       └─ underlying bytes not retrievable by assistant runtime

The failure persists across multiple attempts to reference the same moved files.

Why this looks like a migration/binding problem rather than a bad archive

Three separate files moved together show the same behavior, across both ZIP and tar.gz formats.

The failure occurs before archive parsing: the assistant cannot even stat or open the paths, and uploaded-file retrieval does not return the objects.

The UI/context nevertheless still knows the filenames and file references. That split strongly suggests stale/orphaned Project attachment metadata or a missing blob/index rebinding after Move.

Related issue

• #40201 — ChatGPT Android Projects can retain stale Project references after content is detached/moved and the original Project is deleted.

That issue is not a duplicate: #40201 concerns a stale Project link in Android UI, while this report concerns moved Project files whose references remain visible but whose underlying content becomes inaccessible to the assistant/runtime. The common theme may be incomplete cleanup/rebinding of Project-associated metadata during moves.

Impact

This is especially disruptive for long-running technical/research Projects where binary artifacts, toolchains, datasets, or generated bundles are moved between Projects to preserve context. The files appear to be present, so the failure is discovered only when the assistant tries to use them.

It also risks confusing users into thinking the assistant or archive format is broken, when the apparent failure is in Project file migration/access.

I can provide the affected filenames and attachment/file IDs privately if maintainers need them for backend lookup.

No repository file, test, or entry point is named; first confirm whether openai/codex owns ChatGPT Projects, since the report identifies this as a first-party ChatGPT Web issue rather than a Codex issue. Review related issue #40201 and the reproduction steps, with completion defined as moved files remaining retrievable by the assistant runtime and file search.