[Windows][Projects] Same-named synced web project can make a local project and its history unavailable

What version of the Codex App are you using (From “About Codex” dialog)?

26.915.3509.0 (current installed Windows package version; the exact version at the incident time was not recorded)

What subscription do you have?

Unknown (not available to the reporter at the time of submission)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

A local Codex project and a ChatGPT web Project had the same display name: fault_diag.

After the web Project synchronized into the ChatGPT desktop app, the existing local fault_diag project disappeared from the desktop project list. Its previous local conversation history also became unavailable through that project.

The underlying local folder was not deleted. It still existed and could be used to recreate a local project, so the confirmed loss is the original local project entry/association and access to its prior conversations rather than deletion of the source files.

No error message, duplicate-name warning, merge prompt, or conflict-resolution dialog was shown or recorded.

This has occurred once for the reporter and may be intermittent. It has not been deliberately reproduced again because the suspected failure can make project history unavailable.

What steps can reproduce the bug?

The following reconstructs the observed sequence. Use disposable data for a controlled reproduction.

1. In the Windows ChatGPT desktop app, create or use a local Codex project named fault_diag and start conversations in it.
2. Using the same ChatGPT account on the web, create or rename a ChatGPT Project so that it is also named fault_diag.
3. Allow the web Project to synchronize into the desktop app. The exact trigger is unknown; it may be automatic synchronization, refresh, or a later restart.
4. Inspect the Projects list and the local project's conversation history.
5. Observe that the original local fault_diag project is no longer available, although its underlying folder still exists.

Post-incident recovery attempts:

1. The web Project was renamed from fault_diag to 故障诊断相关.
2. The desktop app was restarted. The renamed web Project refreshed successfully in the desktop app, confirming active web-to-desktop project synchronization.
3. A new local fault_diag project was created from the existing local folder.
4. The desktop agent was asked to search for and restore the previous conversations.
5. Recovery of the original project entry and its conversation history has not been confirmed.

What is the expected behavior?

Web ChatGPT Projects and local Codex projects should retain distinct identities even when their display names are identical.

Synchronizing a web Project must not overwrite, merge, hide, detach, or remove a local project or its conversation history. Both projects named fault_diag should remain independently accessible and should be distinguishable by project type, source, path, or another stable identity.

Additional information

The behavior is consistent with an identity collision involving same-named cloud/web and local projects, but that is only an unconfirmed hypothesis.

Workaround: rename the web Project to a unique name, restart the desktop app, and recreate the local project from its surviving folder. This does not restore the original conversation history.

Related but not identical reports:

• #28646 reports a same-name remote/local collision that associates a new conversation with the wrong project on macOS. This report concerns a Windows web/local collision where the local project and its existing history become unavailable.
• #46413 reports projects and project-associated history disappearing after an app update, without the same-name web/local collision condition.
• #43564 reports duplicate cloud/local project entries on Windows/WSL rather than disappearance of the local project.

No account email, local paths, tokens, or private conversation content are included.

Start by tracing Windows desktop project synchronization and how local and web Projects are identified when their display names match. Reproduce the sequence with disposable projects, then verify that both entries remain independently accessible and that the local project's existing conversation history is still available after synchronization.