[Windows][WSL][Projects] Cloud Project and Local Work split into duplicate project entries

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

Not recorded. The behavior is in the current ChatGPT Desktop app; the exact version can be provided privately if needed.

What subscription do you have?

Not relevant to reproduction.

What platform is your computer?

• Windows 11
• WSL Ubuntu
• ChatGPT Desktop
• Local Work using a Git repository in WSL

What issue are you seeing?

A Cloud Project and Local Work started from that same Cloud Project are not kept as one Project in ChatGPT Desktop on Windows with WSL.

This is a functional context-boundary problem, not merely a duplicate-name cosmetic issue:

• A normal Chat created inside <cloud-project> remains in the cloud Project entry.
• Starting Local Work from that same <cloud-project>, targeting a valid WSL Git repository, creates a second visual Project entry with the same name.
• The Local Work task remains under the second entry, while the normal Chat remains under the original cloud entry.
• It is therefore unclear whether project instructions, files/sources, shared context, and memory are guaranteed to be shared between the two entries.

Local Work itself can successfully run in <wsl-repo> and see a clean Git working tree. That isolates the problem away from repository validity and toward the Cloud/Local Project association or desktop project representation.

Related errors observed while attempting to use this Cloud Project + Local Work workflow:

Invalid request: AbsolutePathBuf deserialized without a base path
Invalid request: invalid type: map, expected path string
EBUSY: resource busy or locked, rename .../.chatgpt-projects/<project-id> -> .../.<project-id>-previous-...

The errors are reported as related observations, not as a claim that they necessarily share one root cause.

No screenshots, logs, account identifiers, project IDs, real project/repository names, real paths, branch names, commit names, installation IDs, or tokens are attached. The report intentionally uses placeholders.

What steps can reproduce the bug?

1. On Windows 11, configure ChatGPT Desktop to use WSL Ubuntu for Local Work.
2. Create or open an existing Cloud Project named <cloud-project>.
3. In that Cloud Project, create a normal Chat and confirm that it appears in the Cloud Project entry.
4. From the same Cloud Project, start a Local Work task and select a valid Git repository in WSL, for example /home/user/projects/example.
5. Confirm that Local Work can initialize in the repository and that its Git working tree is clean.
6. Return to the Projects/sidebar view.
7. Observe a second Project entry with the same displayed name as <cloud-project>.
8. Observe that the normal Chat remains in the cloud entry while the Local Work task appears in the second/local entry.
9. During repeated attempts to use or repair this workflow, observe one or more of the errors listed above. A representative redacted state location is:

C:\Users\user\.codex\.chatgpt-projects\<project-id>

What is the expected behavior?

Starting Local Work from a Cloud Project should retain one unambiguous Project identity:

• normal Chat and Local Work should appear under the same Project entry;
• project instructions, files/sources, and intended shared context should have documented and reliable semantics across both modes;
• the UI should make any Cloud versus Local execution boundary explicit without creating an indistinguishable duplicate Project entry;
• valid WSL repository paths should not cause path-deserialization failures or locked-state rename failures;
• if Cloud and Local Projects are intentionally separate objects, the product should state this explicitly and should not present them as duplicate entries with the same name.

Current official Projects documentation states that the same Project can contain chats started with Chat or ChatGPT Work, and that Project instructions apply to all chats. The observed Windows+WSL behavior does not satisfy that expectation in the Desktop UI.

Additional information

This blocks commercial development workflows. A Project is normally used as the durable unit that holds conversations, files, instructions, and context. If Chat and Local Work are silently split into separate project representations, a team cannot know whether a Local Work task received the required Project instructions/files/context, or whether future Chat follows the Local Work context. Reconstructing or manually copying context between entries is not a reliable development process.

Requested clarification/fix:

1. Confirm whether Cloud Project and Local Work are intended to be one Project with shared context on Windows+WSL.
2. If yes, fix the identity/mapping so one Project does not become two same-named entries, and add regression coverage for Chat + Local Work in a WSL Git repository.
3. If no, clearly distinguish and document the two objects, their synchronization and context boundaries, and why starting Local Work from a Cloud Project creates an apparent duplicate.
4. Investigate the path-deserialization and EBUSY rename errors as potentially related Windows/WSL project-state failures.

Related but distinct issue: #33723 reports a Cloud Project association being lost when switching from Work to Chat. This report concerns the opposite direction: Local Work launched from a Cloud Project becomes a separate duplicate project representation while the normal Chat remains in the original Cloud Project.

Start by reproducing the Windows 11 and WSL workflow described in the issue, then trace how the Cloud Project and Local Work project identities are associated and how the listed path and rename errors arise. Done means either one shared Project entry with regression coverage for Chat plus Local Work, or clearly separated objects with documented context boundaries and behavior.