Local Project can become undiscoverable after removing managed mirror source folder

Summary

In the unified ChatGPT desktop app on macOS, one Local Project became undiscoverable after its secondary ChatGPT-managed project mirror was removed from Source folders and the change was saved.

The same operation was subsequently performed on four other Local Projects with comparable configurations. None of those four Projects disappeared. Each remained visible even though another separately named Local Project referenced the same Primary folder.

The behavior is therefore inconsistent and does not appear to be a deterministic folder-based deduplication or merge.

Environment

• ChatGPT for macOS: 26.803.41515
• Build: 6321

Project configuration

The affected configuration contained three distinct Project entries:

1. A ChatGPT Project whose settings displayed Available sources.
2. An older Local Project with:

• a user-owned folder marked Primary; and
• a ChatGPT-managed project mirror as a secondary Source folder.

1. A separately named Local Project using only the same user-owned folder as Primary.

The ChatGPT Project and the two Local Projects were distinct UI entries.

Affected behavior

In the older Local Project:

1. Edit project was opened.
2. Only the secondary ChatGPT-managed mirror was removed from Source folders.
3. The user-owned Primary folder was preserved.
4. Save was selected.

After saving, the older Local Project was no longer separately visible or discoverable. The ChatGPT Project and the separately named Local Project remained visible.

The application did not display a warning, merge confirmation, reassignment summary, deletion notice, or explanation of what happened to the original Local Project record or its chats.

Supported recovery checks

The affected Local Project was then checked using the supported discovery paths identified by OpenAI support:

• Projects search / Cmd+G: NOT FOUND
• Settings → Data Controls → Archived chats: NO RELATED CHATS FOUND

The application exposes no supported interface for determining whether the missing Local Project was hidden, unregistered, merged, reassociated, or retained under an inaccessible internal identity.

These results do not prove that the underlying record was deleted, but the Project is no longer accessible through the supported UI discovery paths.

Comparative results

The same secondary-folder removal was performed on four other Local Projects with comparable configurations.

For each comparison Project:

1. The user-owned folder remained marked Primary.
2. The secondary ChatGPT-managed mirror was removed.
3. The change was saved.
4. The original Local Project remained visible.

After saving, each comparison configuration continued to show all three entries:

• the ChatGPT Project;
• the original same-name Local Project; and
• the separately named Local Project referencing the same Primary folder.

Therefore:

• two Local Projects can remain visible while referencing the same Primary folder;
• removing the secondary managed mirror does not consistently deduplicate or hide a Local Project; and
• the affected disappearance appears intermittent or dependent on additional internal Project-record state.

Expected behavior

Removing a secondary Source folder while preserving the Primary folder should leave the Local Project registered and visible.

If the resulting configuration conflicts with another Local Project, the application should:

• keep both Local Projects separate; or
• prevent the conflicting configuration and explain why; or
• provide an explicit merge flow that identifies the affected Project records, chats, settings, and folders.

A Local Project should not silently become undiscoverable.

The UI should also clearly distinguish ChatGPT Projects from Local Projects when their display names match.

Actual behavior

One Local Project became undiscoverable after the secondary managed mirror was removed.

Four comparable Local Projects remained visible after the same operation, including configurations in which two Local Projects referenced the same Primary folder.

No warning or explanation accounted for the different results.

Documentation gap

The current Projects and chats documentation explains that Local Projects can contain multiple folders, one folder can be marked Primary, and new chats start in the Primary folder.

It does not explain:

• Local Project identity;
• whether identity is based on a Project record, folder path, or both;
• whether multiple Local Projects may share the same Primary folder;
• deduplication, merge, or hiding behavior;
• how removing Source folders affects Project identity;
• or how to inspect or recover a Local Project that is no longer discoverable.

OpenAI support also confirmed that the published documentation does not define this behavior and that the product exposes no supported method for inspecting a hidden Local Project identity.

Impact

The inconsistent behavior created uncertainty about whether existing chats and Project settings remained associated with the intended Local Project.

It also caused repeated Project-creation and runtime-validation attempts and substantial additional model usage while attempting to determine whether the original Project still existed.

No user-owned files or folders were deleted, moved, renamed, overwritten, or otherwise modified.

Related public reports

• #37314 — related because it describes multiple Local Project records referencing the same folder, but it has a different trigger and outcome: newly created threads were assigned to a second Project.
• #24875
• #35135
• #34076

The behavior was also reported separately through the in-product feedback mechanism. No private Project names, filesystem paths, account details, screenshots, logs, or task/session identifiers are included here.