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

Open Codex Desktop on Windows.
Open the project selector and choose Create project.
Choose a source folder.
In the native Windows folder picker, browse through:
Network > wsl.localhost > Ubuntu > home > <user> > projects > <repo>
Click Select Folder.
Confirm that the repository appears in the Create project form.
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

Codex Desktop project chat history disappears after update due to WSL cwd/path migration mismatch #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.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Windows + WSL] Cannot create projects – AbsolutePathBuf deserialized without a base path #41463

Powered by Codex Action

Still reproducible in a much newer build.

Environment

Codex Desktop: 26.908.40834
Bundled Codex CLI: 0.154.0
Windows: 10.0.26200 x64
WSL2: Ubuntu
Agent environment: WSL
Repository: valid non-bare Git repository stored on the native WSL filesystem under /home/<user>/<repo>
Folder picker path: \\wsl.localhost\Ubuntu\home\<user>\<repo>

Current behavior

Submitting the Create Project dialog consistently shows the localized generic error Projekt konnte nicht erstellt werden (Project could not be created). Restarting Codex Desktop does not help. The repository is readable, has a valid main branch and commit, and has the same owner/permissions as other WSL repositories that already work in Codex.

Additional diagnostic evidence

This appears to be a persistence/reconciliation failure between the app-server project database and Electron's legacy global project state:

The failed UI attempt leaves an entry in app-server-project-id-by-legacy-project-id-by-host.
The corresponding legacy project is missing from both local-projects and project-order, so it remains invisible in the sidebar and project picker.
Calling the Windows app-server project/create method directly succeeds, emits project/changed with changeType: created, and persists the UNC root in state_5.sqlite.
Despite that successful app-server creation, the Desktop UI and project listing still omit the project.
Manually restoring the missing local-projects and project-order entries is not durable: after restarting Codex Desktop, the app rewrites the global state and removes those entries again while retaining an orphaned legacy-to-app-server mapping.

No repository-specific contents appear relevant. The failure is reproducible with a minimal Git repository containing only a README and an initial commit.

This suggests the UNC canonicalization issue also causes the Electron migration/persistence layer to leave a partially created project and then discard the visible legacy state on restart.

Still reproducible in an even newer build, with two additional failure modes and one important correction to the workaround findings above.

Environment

Codex Desktop: 26.924.2738.0 (Microsoft Store)
Bundled WSL app-server: 0.158.0-alpha.2.1
Windows 11 + WSL2 (Ubuntu), runCodexInWindowsSubsystemForLinux = true

Additional failure mode 1 — "Start from scratch" (blank project) fails with a different, explicit error

Besides the silent UNC failure, creating a blank project always fails immediately with this exception in the Electron main process (desktop log, %LOCALAPPDATA%\Packages\OpenAI.Codex_*\LocalCache\Local\Codex\Logs):

Error: Creating a default workspace is only supported for local hosts
    at createDefaultWorkspaceRoot (...app.asar/.vite/build/main-*.js)

The UI shows "Failed to create project" and — same as the UNC case — no project/create request ever reaches the app-server. The function throws early when the host is the WSL environment, before asking the (WSL-capable) backend to create anything. So in WSL mode neither creation path works at all.

Additional failure mode 2 — downstream sandbox breakage when an UNC root does get persisted

When a project is created with a \\wsl$\… / \\wsl.localhost\… root, every agent command fails afterwards because the Windows sandbox helper cannot set NTFS ACLs on WSL 9P paths (%USERPROFILE%\.codex\.sandbox\sandbox.*.log):

write ACE grant failed on \\?\UNC\wsl.localhost\Ubuntu\home\...\<proj>:
  GetSecurityInfo failed ... (error 1)
deny ACE failed on \\wsl.localhost\Ubuntu\home\...\<proj>\.git:
  GetNamedSecurityInfoW failed ... (error 1)
setup error: setup refresh had errors

→ exec_command / apply_patch all fail with helper_unknown_error: setup refresh had errors. The renderer also logs EISDIR every ~5 s from git-init-watcher / git-repo-watcher trying to fs.watch() a \\wsl$\... path.

Correction to the "manually restoring local-projects is not durable" finding

The earlier comment says a manually restored project is removed again on restart. That matches my experience when the restored root is an UNC path — the app discards/rewrites it.

However, restoring the entry with a WSL-native root is durable and fully working:

// %USERPROFILE%\.codex\.codex-global-state.json
"local-projects": {
  "<uuid>": {
    "id": "<uuid>",
    "name": "my project",
    "rootPaths": ["/home/<user>/<repo>"],   // WSL-native, not \\wsl$\...
    "createdAt": 0, "updatedAt": 0
  }
}

Quit the app, edit, relaunch: the project appears, is imported into the app-server, and the agent works — no sandbox errors, no watcher errors. This strongly supports the canonicalization hypothesis: once the root is stored in WSL-native form, the whole pipeline (project sync, app-server, sandbox, watchers) works. The bug is confined to the Desktop creation/persistence flow handing through Windows-side path forms that are never converted to the WSL-native form the running backend expects.

(Also confirmed broken on 26.825.51511 / app-server 0.151.x — same behavior across both builds, and the blank-project path throws the same error.)

happy to share the script
codex-add-project.py

Navigation Menu

Repository navigation

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

Summary

Environment

Steps to reproduce

Actual behavior

Expected behavior

Diagnostic evidence

Related issue

Suggested fix areas

Environment

Current behavior

Additional diagnostic evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Steps to reproduce

Actual behavior

Expected behavior

Diagnostic evidence

Related issue

Suggested fix areas

Activity

github-actions commented on Aug 31, 2026

CaarLo1337 commented on Sep 13, 2026

Environment

Current behavior

Additional diagnostic evidence

lzp6778-code commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions