Codex Cannot Create a Project in WSL? Recover Safely

If Codex Desktop on Windows says Cannot create project after you switch the Agent Environment to WSL, do not delete the repository, rewrite its .git directory, or clear Codex state. First prove that WSL and the repository still work. Then separate an app project-registration failure from a Git failure and continue from the Linux-native Codex CLI while the Desktop path boundary is unresolved.

Two fresh reports in OpenAI's Codex issue tracker describe this exact family of failures. One report reproduced project creation and removal failures after switching the Agent Environment to WSL, even when it selected a normal Windows folder. Another reproduced Cannot create project for repositories under /home/... while the WSL transport and Codex CLI initialized successfully. Its logs then showed AbsolutePathBuf deserialized without a base path and repeated watcher errors against the Windows \\wsl$ representation.

Those reports are evidence of a current regression, not proof that every WSL project failure has the same cause. Use the checks below to classify your own case before changing anything.

Confirm that this is the same failure family

This guide fits when all of these are true:

• Codex Desktop runs on Windows and its Agent Environment is set to WSL.

• A valid WSL or Windows repository fails only while the WSL Agent Environment is active.

• Adding or removing the repository as a Desktop project fails.

• WSL starts normally, and Git still reads the repository from a WSL shell.

The most useful current log signatures are:

Cannot create project
Invalid request: AbsolutePathBuf deserialized without a base path
EISDIR: illegal operation on a directory, watch '\\wsl$\Ubuntu\home\...'

If git status also fails inside WSL, stop here and diagnose Git or the repository instead. If Desktop reports Git is unavailable but project creation itself works, use the narrower Codex WSL Git guide.

1. Record the environment before changing it

In Windows, open About Codex and record the full app build. Then use PowerShell to list the installed WSL distributions:

wsl --status
wsl --list --verbose

Record:

• the selected Agent Environment;

• the selected WSL distribution;

• whether the project was first added under Windows or WSL;

• the path exactly as Desktop displays it;

• the Linux path returned by WSL;

• the exact operation that fails: add, open, remove, or all three.

OpenAI's current Windows guidance says Codex can select among installed WSL distributions. If you have more than one, do not assume Desktop selected the same distribution that your terminal uses.

Expected result: you can name one app build, one WSL distribution, one project path, and one failing operation.

2. Prove that the repository is healthy inside WSL

Open the selected distribution and run read-only checks from the exact repository:

cd /home/you/projects/app
pwd -P
git --version
git rev-parse --show-toplevel
git rev-parse --is-inside-work-tree
git status --short --branch

Expected results:

• pwd -P and git rev-parse --show-toplevel identify the same Linux project root;

• git rev-parse --is-inside-work-tree prints true;

• git status shows the real branch and any local changes.

Save the output, but redact usernames, private repository names, remotes, and customer paths before sharing it. If the commands succeed, the evidence says the repository remains readable in WSL. It does not prove that Desktop's project catalog can translate or watch that path.

3. Preserve local work and avoid destructive repairs

Before another app test, record the change surface:

git status --short --branch
git diff --stat
git diff --cached --stat

Commit or copy irreplaceable work through your normal repository policy. Do not:

• delete .git;

• delete or hand-edit Codex's local database;

• clear the entire %USERPROFILE%\.codex directory;

• repeatedly register both /home/... and \\wsl$\... forms of the same repository;

• move an active repository between filesystems as an experiment;

• download an older Desktop package from an untrusted source.

Project registration is metadata about a repository. Removing that metadata should never require deleting the repository itself.

4. Run a controlled Windows-versus-WSL test

Fully quit Codex Desktop before changing the Agent Environment. Reopen it, confirm the selected environment, and test with a disposable repository rather than the affected one.

Use three separate controls:

Do not point any two controls at different path spellings of the same folder. Microsoft recommends keeping Linux-tool projects in the Linux filesystem and Windows-tool projects in the Windows filesystem. The test should preserve that ownership rather than introducing /mnt/c as a third variable.

Create, open, and remove only the disposable entries. Then fully quit Desktop, switch environments once, reopen, and repeat the same three operations.

If Windows-native project management succeeds and both WSL-mode tests fail, you have reproduced the environment-switch failure reported in issue 41290. If only the WSL-native path fails, your result is closer to issue 41463 and its path-handling evidence. If all three fail, capture that difference and look for a broader Desktop project-catalog problem.

5. Check diagnostics without editing app state

OpenAI documents codex doctor as the Windows diagnostic for startup, connectivity, and performance problems. From the same WSL distribution, run:

codex doctor

Also inspect the Desktop logs around one fresh reproduction. Search for the exact strings from the failure rather than uploading the entire log directory. Preserve a short sequence showing:

1. WSL transport startup;

2. Codex CLI initialization;

3. project migration or registration failure;

4. any AbsolutePathBuf, EISDIR, or fs/readDirectory error.

Expected result: you can tell whether the failure occurs before WSL starts, during CLI initialization, or later in the Desktop project subsystem. In the strongest current report, initialization succeeded before project migration failed.

6. Continue safely inside WSL

When the repository checks pass but Desktop project registration does not, continue from the repository's Linux path:

cd /home/you/projects/app
codex

This keeps the executable, working directory, Git process, and project path in one Linux environment. It is a containment step, not a claim that Desktop has been repaired.

If Codex CLI is missing, follow OpenAI's current installation guidance from the WSL shell. Do not install an unrelated package with the same command name.

If you must use Desktop project features, wait for an official update and retest the disposable WSL control first. A separate Windows-native clone can be a last-resort temporary workspace only when the authoritative remote is current and all local work is preserved. Never edit two clones concurrently without an explicit synchronization plan.

7. Retest after an official fix

Watch the matching OpenAI issues and release notes. After an official update:

1. record the new build;

2. fully quit and reopen Desktop;

3. select the intended WSL distribution;

4. add and remove the disposable WSL project;

5. confirm no matching migration or watcher error appears;

6. open the real repository only after the control passes.

If chat history or existing project associations disappear after the environment change, do not recreate everything immediately. Use the Codex chat recovery guide to distinguish a path-identity mismatch from missing data. For a separate Windows multi-folder startup failure, use the second-folder recovery guide.

Turn the verified recovery into a reusable team procedure

Once the control passes, save the approved sequence as a small team runbook: capture the build and distribution, verify Git inside WSL, test one disposable project, use the WSL CLI fallback, and retest after an official update. Keep credentials and private logs out of the procedure.

Set up Aident Loadout and ask your agent to find the current read-only GitHub issue search Action, inspect its schema, preflight the exact query, and return the latest matching OpenAI Codex issues. One attributable setup start is the measurable next step. The connected Action keeps the GitHub credential outside the repository while the result remains reviewable.

Conclusion

When Codex Desktop cannot create or remove a WSL project but WSL and Git remain healthy, treat the repository as intact. Preserve local work, isolate the failure with separate Windows-native and WSL-native controls, capture the narrow log signature, and keep working from Codex CLI inside WSL. Retest Desktop only after an official update, and never turn a project-registration failure into repository data loss.

Sources

• OpenAI: Using Codex with your ChatGPT plan

• OpenAI Codex issue #41463: Cannot create WSL projects

• OpenAI Codex issue #41290: Project creation and removal fail after switching to WSL

• Microsoft: Working across Windows and Linux file systems