openai / openai/codex

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

Open
#41,463 61 comments 34 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server bug windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

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>
  1. Open Codex Desktop.

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

  3. Codex Desktop shows a generic toast:

Cannot create project
  1. Restarting Codex Desktop does not resolve the issue.

  2. 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
  1. 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"
  1. 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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the failure with a Windows 11 WSL2/Ubuntu repository under /home//projects and inspect the project migration flow after the successful AppServerConnection handshake. Compare the AbsolutePathBuf, \wsl$ watcher, and fs/readDirectory errors across the reported builds. Done means projects can be created and watched in the native WSL filesystem without these path or watcher errors.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.