Projects and Library are not synchronized correctly

ChatGPT Bugs
, , ,
1

I discovered three related problems when working with Projects, project chats, Library, and Project Sources.

1. Renaming a Project creates a new Library folder

Steps to reproduce

  1. Create a Project named Project A.
  2. Create a chat inside it.
  3. Upload a file specifically to this project chat.
  4. Open Library.

Verified behavior: ChatGPT automatically creates a folder in Library with the exact same name as the Project – Project A – and places the file uploaded to the project chat there.

  1. Rename the Project from Project A to Project B.
  2. Upload another file to any chat inside the same Project.

Actual behavior

ChatGPT does not use the existing Project A folder and instead creates a new Project B folder in Library.

As a result, after several renames, the same Project may have several folders in Library, each containing some of its files.

This is especially problematic for long-term Projects: the name is often refined during the course of work, once the scope of the task becomes clearer.

Expected behavior

One Project should remain permanently linked to one folder in Library regardless of changes to its name.

When a Project is renamed, the system should either:

  • rename the Library folder linked to it;
  • or continue using the same folder regardless of its displayed name.

Renaming a Project should not create a new folder and fragment its files.

2. Moving an existing standalone chat to a Project does not migrate its Library files

Steps to reproduce

  1. Create a regular standalone chat.
  2. Upload several files to it.
  3. Later move this chat to a Project.
  4. Continue working inside the Project.

Actual behavior

The chat itself becomes a project chat, but the files previously uploaded to it remain in their previous location in Library.

At the same time, the system does not perform the same action that it already performs automatically for new files uploaded directly to a project chat: it does not create/use the Library folder with the same name as the Project and does not move the existing files from that chat into it.

As a result, documents related to the same work are scattered across Library, and the user has to find and move them manually.

Expected behavior

When a standalone chat is moved to a Project, the system should:

  1. create a folder in Library with the Project name if it does not already exist;
  2. move into it all Library files that had previously been uploaded to that chat;
  3. continue placing there new files uploaded to project chats inside the same Project.

This would be fully consistent with ChatGPT’s existing behavior when files are uploaded directly to a project chat.

Related report: “Project Sources empty after moving conversation to a project”. That report describes inconsistent file migration when moving an existing conversation into a Project; the first issue in this report – duplicate Library folders created after renaming the same Project – is a separate problem.

3. Existing Library files cannot be added or moved to Project Sources without re-uploading

This problem is especially noticeable after moving a regular chat to a Project.

Important documents already exist in Library, but the user may realize that it would be better to make them Project Sources, so that they are used as persistent sources of context for the Project.

At present, an existing Library file cannot simply be selected and added or moved to Project Sources. In practice, the same file has to be uploaded again, and the user then has to manually deal with the copy that remains in Library.

Expected behavior

Existing Library files should have simple operations such as:

  • Add / Link to Project Sources – the file becomes a Project Source without being re-uploaded and remains in Library;
  • Move to Project Sources – the file becomes a Project Source and no longer remains as a separate file in Library.

The user should not have to re-upload a file that is already stored in ChatGPT just to change how it is used inside a Project.

Related discussion: “Allow adding Library files directly to Projects”. This feature request addresses the same Library → Project Sources limitation and has already been discussed separately.

Why this matters

All three problems arise in normal usage scenarios:

  • a regular chat gradually grows into a Project;
  • the Project name is refined during the course of work;
  • after moving a chat, the user realizes that some of the documents already uploaded should be used as Project Sources.

At present, these normal actions create duplicate folders, scatter the files of one Project across different places in Library, and force the user to perform file operations manually that the system could handle itself.

For long-term Projects with a large number of documents, this is no longer a cosmetic inconvenience, but a real data-organization problem.

2

I am experiencing the same class of Project–File Library synchronization failures.

For approximately two weeks, files have appeared duplicated, outdated, missing or inconsistently associated between File Library and an affected Project. File-management operations have produced errors involving no_shard, Sediment-26, library_file_id, persistence, indexing and Library–Project association.

Three linked support cases remain unresolved. OpenAI Support acknowledged that substantial evidence and troubleshooting had already been provided, but continues requesting another screen recording without stating which backend records were reviewed, what Engineering found or what reconciliation will be applied.

The operational impact is severe: every file, version and update must be manually checked because the system provides no reliable confirmation that changes were persisted and associated with the correct Project. Hours have been lost documenting and repeatedly demonstrating a defect in a paid product.

No private project content or complete case numbers are disclosed here.

OpenAI should:

  • investigate the affected storage, indexing and association records;

  • reconcile duplicated, outdated and missing references;

  • explain the technical findings;

  • provide a verifiable persistence mechanism;

  • stop requiring users to repeat evidence already supplied.

This remains unresolved and should be treated as a broader product reliability and data-integrity issue, not isolated user troubleshooting.