Codex Desktop silently fails to create WSL project selected via wsl.localhost UNC path

Summary

Codex Desktop on Windows silently fails to create a local project when the selected WSL repository is returned by the native folder picker as a \\wsl.localhost\... UNC path.

The picker can browse the repository, the selected folder is added to the Create project form, and the submit button is accepted, but the project is not persisted and no user-facing error is shown.

A previously working WSL project on the same machine is stored using the \\wsl$\... alias. This suggests that project creation does not consistently canonicalize the equivalent \\wsl.localhost, \\wsl$, and Linux /home/... forms.

Environment

• Product: Codex Desktop for Windows
• Desktop version: 26.825.51511
• Windows version: 10.0.26200
• WSL distribution: Ubuntu (WSL2)
• Repository location: WSL ext4 under /home/<user>/projects/<repo>
• Repository type: ordinary non-bare Git repository

Steps to reproduce

1. Open Codex Desktop on Windows.
2. Open the project selector and choose Create project.
3. Choose a source folder.
4. In the native Windows folder picker, browse through:
   Network > wsl.localhost > Ubuntu > home > <user> > projects > <repo>
5. Click Select Folder.
6. Confirm that the repository appears in the Create project form.
7. Submit the form.

Actual behavior

• The selected repository is not added to the persisted local project list.
• Reopening the project selector shows that the project was not created.
• No validation or error message is shown.
• Repeating the operation produces the same result.

The selected Windows path is:

\\wsl.localhost\Ubuntu\home\<user>\projects\<repo>

Expected behavior

Codex should create the project and canonicalize the selected WSL path to a stable internal representation, regardless of whether Windows returns:

\\wsl.localhost\Ubuntu\home\<user>\projects\<repo>
\\wsl$\Ubuntu\home\<user>\projects\<repo>
/home/<user>/projects/<repo>

If the path cannot be normalized, the UI should show an actionable error rather than silently discarding the project.

Diagnostic evidence

• Windows PowerShell Test-Path returns true for both the \\wsl.localhost\... and \\wsl$\... forms of the same repository.
• The repository is readable from WSL and has the same ext4 filesystem, owner, and permissions as another WSL repository that Codex can use successfully.
• git rev-parse confirms that it is a normal, non-bare work tree.
• Codex UI telemetry records the source-folder selection, the repository being added to the form, and the submit click.
• After submission, Codex local project state still has no entry for the selected repository.
• A working WSL project in the same local state is persisted with a \\wsl$\Ubuntu\... root.

Related issue

• #24364 reports the same broader class of Windows/WSL cwd canonicalization mismatch, including inconsistent handling and duplication of \\wsl$ and \\wsl.localhost roots. That issue concerns existing chat history becoming invisible; this report concerns failure to persist a newly created local project.

Suggested fix areas

• Canonicalize \\wsl.localhost\<distro>\... and \\wsl$\<distro>\... before validating or persisting a local project.
• Use the same canonical representation in project creation, project listing, thread cwd filtering, and local project state.
• Surface path-conversion and persistence failures in the Create project dialog.
• Add a Windows regression test where the native picker returns a \\wsl.localhost path for a WSL2 repository.

Start at the Create project flow and local project state handling, tracing path validation and persistence for the selected source folder. Reproduce with a Windows picker returning a \wsl.localhost path, then add the suggested Windows regression test; done means the project is persisted using a stable WSL representation or an actionable error is shown.