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

[GeorgeValle]

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

26.825.4187.0

What subscription do you have?

ChatGPT Prolite

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Codex Desktop on Windows with WSL2/Ubuntu is unable to create or correctly manage local projects whose repositories are located inside the WSL filesystem.

When attempting to create a project, the UI shows a generic toast:

Cannot create project

The issue appears to be related to the Codex Desktop project subsystem and Windows/WSL path handling.

Environment

• Codex Desktop: 26.825.4187.0
• Windows 11 x64
• WSL2
• Ubuntu
• Repositories stored inside the native WSL filesystem under paths such as /home/<user>/projects/...
• Codex configured to execute through WSL

Main error

During Codex Desktop startup, the logs consistently show:

[host-app-server-projects] Local app-server project migration failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

This occurs after the WSL transport and Codex CLI initialize successfully.

For example, the logs show:

[AppServerConnection] Transport start success
[AppServerConnection] initialize_handshake_result ... outcome=success
[AppServerConnection] Codex CLI initialized

Immediately afterwards:

[host-app-server-projects] Local app-server project migration failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

WSL filesystem watcher errors

There are also many repeated filesystem watcher errors involving WSL paths.

For example:

[git-repo-watcher] Failed to watch git path
errorCode=EISDIR
errorMessage="EISDIR: illegal operation on a directory, watch '\\wsl$\Ubuntu\home\<user>\projects\...'"

The same error occurs while attempting to watch:

.git
.git/refs
.git/refs/heads
.git/info

This happens across multiple repositories, so it does not appear to be repository-specific.

Additional filesystem errors

The app also occasionally reports:

method=fs/readDirectory
errorCode=-32603
message="No such file or directory (os error 2)"

This may indicate that paths are being translated incorrectly between Windows/UNC paths and Linux/WSL paths.

Expected behavior

Codex Desktop should be able to create and manage Projects whose repositories are located in WSL, using paths such as:

/home/<user>/projects/<repository>

without failing project migration or filesystem watching.

Actual behavior

Creating a Project fails with:

Cannot create project

and the logs contain:

Invalid request: AbsolutePathBuf deserialized without a base path

along with repeated EISDIR errors involving \\wsl$\Ubuntu\....

Reproduction steps

1. Run Codex Desktop on Windows 11.
2. Enable WSL2 with Ubuntu.
3. Configure/use Codex through WSL.
4. Keep Git repositories inside the WSL filesystem under /home/<user>/projects/....
5. Open Codex Desktop.
6. Attempt to create a new Project using one of those repositories.
7. Codex displays a "Cannot create project" toast.
8. Check the Codex Desktop logs.

Regression / multiple builds

I reproduced the same project migration error on at least these Codex Desktop builds:

• 26.825.3734.0
• 26.825.4187.0

Updating from the first build to the second did not resolve the issue.

Notes

WSL itself appears to initialize correctly and the Codex CLI successfully connects through the WSL stdio transport.

The failure appears specifically after initialization, when the local app-server project subsystem performs project migration/path handling.

I have attached sanitized Codex Desktop logs containing the relevant errors. Personal identifiers, repository names, usernames, email addresses, conversation IDs, and credential-like values have been redacted.

What steps can reproduce the bug?

1. Run Codex Desktop on Windows 11.

2. Enable WSL2 with Ubuntu.

3. Configure Codex Desktop to use WSL.

4. Store Git repositories inside the native WSL filesystem, for example:

/home/<user>/projects/<repository>

5. Open Codex Desktop.

6. Attempt to create a new Project using one of the repositories stored inside WSL.

7. Codex Desktop shows a generic toast:

Cannot create project

8. Restarting Codex Desktop does not resolve the issue.

9. The Codex Desktop logs show that the WSL transport and Codex CLI initialize successfully:

[AppServerConnection] Transport start success
[AppServerConnection] initialize_handshake_result ... outcome=success
[AppServerConnection] Codex CLI initialized

10. Immediately afterwards, the Project subsystem fails with:

[host-app-server-projects] Local app-server project migration failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

11. Repeated filesystem watcher errors are also generated for WSL paths:

[git-repo-watcher] Failed to watch git path
errorCode=EISDIR
errorMessage="EISDIR: illegal operation on a directory, watch '\\wsl$\Ubuntu\home\<user>\projects\...'"

The error occurs across multiple repositories, so it does not appear to be repository-specific.

What is the expected behavior?

Codex Desktop should be able to create and manage Projects whose repositories are stored inside the native WSL filesystem.

Paths such as:

/home/<user>/projects/<repository>

should be handled correctly when Codex is configured to run through WSL.

The Project should be created normally, the repository should remain accessible, and Codex Desktop should be able to watch the repository and its .git directory without path conversion or filesystem errors.

The Windows host and WSL filesystem paths should be translated consistently without producing AbsolutePathBuf, EISDIR, or fs/readDirectory errors.

Additional information

The problem does not appear to be caused by WSL failing to start.

WSL is detected correctly and the Codex CLI successfully initializes through the WSL stdio transport before the Project subsystem fails.

The most relevant error is:

[host-app-server-projects] Local app-server project migration failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

There are also repeated filesystem watcher errors involving the Windows UNC representation of WSL paths:

\\wsl$\Ubuntu\home\<user>\projects\...

with:

EISDIR: illegal operation on a directory

and occasional filesystem calls failing with:

method=fs/readDirectory
errorCode=-32603
message="No such file or directory (os error 2)"

This suggests a possible Windows ↔ WSL path translation or base-path handling issue in the Codex Desktop Project subsystem.

I reproduced the same Project migration error on at least these Codex Desktop builds:

• 26.825.3734.0
• 26.825.4187.0

Updating between these builds did not resolve the issue.

I am attaching sanitized Codex Desktop logs containing the relevant errors. Personal identifiers, usernames, repository names, email addresses, conversation/task IDs, and credential-like values have been redacted.

codex-logs-sanitized-for-openai.zip

[github-actions]

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

• [Windows][WSL][26.825.31414] Project creation and removal fail after switching Agent Environment to WSL #41290
• WSL agent mode fails when creating a new chat with AbsolutePathBuf deserialized without a base path #40786

Powered by Codex Action

[QuentinAd]

I can confirm this is still reproducible in Codex for Windows build 26.825.6671.0, upgraded from 26.825.4187.0. The local project registry contains a mix of normal Windows roots (C:\\...) and WSL UNC roots (\\\\wsl$\\Ubuntu\\...). On every startup, the desktop log records:

[host-app-server-projects] Local app-server project migration failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

After that migration failure, both project operations are broken:

• Creating a local project shows Failed to create project.
• Editing an existing local project shows Failed to save project.

The legacy .codex-global-state.json remains readable and writable, and Codex can list the existing projects, so this is not a filesystem permission failure. Inspection of the bundled flow shows that createLocal() and editLocal() both call ensureProjectsReady() before the legacy cache write. Since initializeProjects() fails during the new app-server project migration, neither operation reaches the cache update. Restarting and removing duplicate legacy project entries do not fix it.

This regression prevents all local project maintenance, not only creation of a project rooted inside WSL.

[forallthis]

Additional isolation on Codex Desktop 26.825.6671.0 with Windows 11, WSL2, and Ubuntu 24.04:

1. I repaired the project migration identity mismatch so startup now completes successfully:

[host-app-server-projects] Local app-server project migration completed projectCount=5

2. Even after migration succeeds, creating another WSL project from the Desktop UI still fails. The app-server trace records the incoming project/create request, but no project is written.

3. Sending project/create directly to the same bundled WSL app-server version with a native Linux root such as:

/home/<user>/code/<repo>

succeeds immediately and emits project/changed.

4. After adding the corresponding Desktop compatibility mapping and restarting, the project is listed normally and startup reports projectCount=6.

This separates the remaining creation failure from the migration failure and narrows it to the Desktop-to-WSL project root representation. The Desktop-side record uses a WSL UNC path such as \\wsl$\Ubuntu-24.04\home\<user>\code\<repo>, while the Linux app-server accepts the equivalent /home/<user>/code/<repo> path.

[GeorgeValle]

• Creating a local project shows Failed to create project.
• Editing an existing local project shows Failed to save project.

Since initializeProjects() fails during the new app-server project migration, neither operation reaches the cache update. Restarting and removing duplicate legacy project entries do not fix it.

This regression prevents all local project maintenance, not only creation of a project rooted inside WSL.

---

Thanks for confirming and for narrowing this down.

This matches my environment exactly: the local registry contains both Windows roots and WSL UNC roots, and the failure happens before project cache updates. I can also confirm that both project creation and editing are affected after the startup migration fails.

One additional detail that may be useful: I can still recover and reuse chats that belonged to older local projects, but only through the remote/mobile Codex flow.

What I found is that the remote Codex feature available from mobile can still open those existing project chats. Once I open one of those chats remotely, the conversation becomes active again and I can continue using it from Codex Desktop.

So, for me, the current workaround is:

1. Open Codex from mobile / remote mode.
2. Access an existing chat that belonged to an older local project.
3. Open or interact with that chat remotely.
4. Return to Codex Desktop.
5. The previously inaccessible project chat is effectively reactivated and can be used again.

I discovered this while investigating the Codex app-related errors.

This workaround only helps with existing project conversations. It does not restore normal local project maintenance: creating a new local project or editing/saving an existing local project still fails.

This may suggest that the conversations themselves remain intact and accessible through the remote thread infrastructure, while the local project registry/migration layer is what is broken.

I’ll keep the environment unchanged for now and can provide additional sanitized logs if needed.

[odlfg]

I am experiencing this exact critical regression. Forcing projects into C:\ completely destroys modern containerized development workflows.

Running Docker containers and automated tests inside WSL2 while mounting files from C:\ via /mnt/c/ creates a massive I/O performance bottleneck. Test suites that used to take seconds now take minutes. My host Windows machine is 100% clean; everything relies on the WSL2 filesystem.

This was working flawlessly during August. I can also confirm that this issue completely blocks both local project creation and editing/saving operations due to the underlying AbsolutePathBuf path migration failure on startup. Please fix this path deserialization bug soon!

Associated OpenAI App Feedback ID: no-active-thread-01a05b4f-3244-7cc0-b856-468e1fcdf777

[sdp0825]

I cannot create a new project. The message "Failed to create project" appears when I attempt to create one.

[pisceskkk]

Additional confirmation from a slightly different WSL environment:

• Codex Desktop package: 26.825.6671.0
• Bundled WSL Codex CLI: 0.151.0-alpha.7.2
• WSL2 distribution: Ubuntu 26.04
• runCodexInWindowsSubsystemForLinux = true

Selecting a directory through Add project consistently ends with Failed to create project. In contrast, creating an SSH remote project succeeds.

The selected directories are valid and readable from WSL, including both native Linux roots under /home/<user>/... and Windows-mounted roots under /mnt/c/Users/<user>/.... Existing local projects can still be listed, so this does not appear to be a Git repository or filesystem-permission problem.

The desktop log contains the same migration failure:

[host-app-server-projects] Local app-server project migration failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

It also records Windows-side watcher failures after converting a Linux project root to a WSL UNC path:

[git-repo-watcher] Failed to watch git path
errorCode=EISDIR
errorMessage="EISDIR: illegal operation on a directory, watch '\\\\wsl$\\Ubuntu-26.04\\home\\<user>\\<repo>'"

The fact that remote project creation works while local creation fails further suggests that the failure is in the Desktop-to-WSL local project registration/path representation layer.