›_ Codex Issues
Codex Issues / #28174

Codex App on Windows + WSL incorrectly maps /mnt/e/... to C:\mnt\e\...

Open 💬 7 comments Opened Jun 14, 2026 by id0108887-star
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Version 26.609.41114

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Codex App on Windows with WSL runtime incorrectly maps a WSL project path from a non-C Windows drive.

My project is located on a non-C Windows drive.

Windows path pattern:

E:\path\to\project

WSL path pattern:

/mnt/e/path/to/project

After an app update/reset, Codex App started showing:

Current working directory is missing
The working directory for this chat no longer exists

The project still existed and worked correctly inside WSL. Git also worked normally from the WSL path.

The problem was that Codex App generated this project entry in config.toml:

[projects."c:\\mnt\\e\\path\\to\\project"]
trust_level = "trusted"

But this Windows path does not exist by default:

C:\mnt\e\path\to\project

It looks like Codex App converted:

/mnt/e/path/to/project

into:

C:\mnt\e\path\to\project

instead of mapping it to the actual Windows drive path:

E:\path\to\project

Deleting the bad c:\\mnt\\e... project entry from config.toml did not permanently solve the problem. Codex App recreated the same entry after restart or reopening the project.

What steps can reproduce the bug?

  1. Use Codex App on Windows with WSL2/Ubuntu.
  2. Set Agent runtime to Windows Subsystem for Linux.
  3. Set Integrated terminal shell to WSL.
  4. Use shared CODEX_HOME:
  • Windows: C:\Users\<windows-user>\.codex
  • WSL: /mnt/c/Users/<windows-user>/.codex
  1. Open a project located on a non-C Windows drive, for example:
  • Windows path: E:\path\to\project
  • WSL path: /mnt/e/path/to/project
  1. Start a new project chat.
  2. Restart Codex App or reopen the project.
  3. Check config.toml.

Actual result:

Codex App creates/recreates a project entry like:

[projects."c:\\mnt\\e\\path\\to\\project"]
trust_level = "trusted"

The UI may then show:

Current working directory is missing
The working directory for this chat no longer exists

Workaround:

Creating a Windows junction fixed the missing working directory warning:

C:\mnt\e -> E:\

After that, the generated path:

C:\mnt\e\path\to\project

became valid, and Codex App stopped showing the missing working directory warning.

What is the expected behavior?

When Codex App uses WSL runtime and a project under /mnt/e/..., it should either:

  1. Keep the project path as a WSL path internally, or
  2. Correctly map /mnt/e/... to E:\...

It should not generate C:\mnt\e\... unless that path actually exists.

Additional information

Related startup issue observed after update/reset:

Codex App also failed to start with:

Unable to locate the Codex CLI binary

This required reinstalling the Windows Codex CLI and explicitly setting CODEX_CLI_PATH to the Windows Codex CLI executable.

WSL also required a separate Codex CLI installation so that codex was available inside Ubuntu.

Final working workaround state:

  • Windows Codex CLI installed
  • WSL Codex CLI installed
  • WSL runtime enabled
  • Integrated terminal shell set to WSL
  • Shared CODEX_HOME used
  • Junction created: C:\mnt\e -> E:\
  • Project works from /mnt/e/path/to/project
  • No missing working directory warning after the junction workaround

Possibly related to #25799, but this issue is specifically about path normalization for /mnt/e/... on a non-C Windows drive.

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #28094
  • #28172

Powered by Codex Action

id0108887-star · 1 month ago

Thanks for the duplicate detection.

I reviewed #28094 and #28172. They look related, especially because they also involve Windows + WSL project paths being rewritten into invalid Windows paths and causing missing working directory / chat association issues.

However, I think this issue is not an exact duplicate.

The key difference here is that my case is specifically about a project on a non-C Windows drive mounted in WSL:

/mnt/e/path/to/project

Codex App rewrites it as:

C:\mnt\e\path\to\project

instead of resolving it to:

E:\path\to\project

So this issue may be a specific variant of the same path normalization bug, focused on /mnt/<drive-letter>/... paths for non-C drives.

The workaround that fixed it locally was creating:

C:\mnt\e -> E:\

So I’m leaving this issue open unless maintainers prefer to merge it into one of the related issues.

888luck8 · 1 month ago

Do you use the agent inside the WSL

Or like in windows or self

I recommend using the cli codex inside it

Inshallah best of luck 🌹

id0108887-star · 1 month ago

Thanks.

Yes, the agent is configured to run with WSL runtime in Codex App.

I also installed Codex CLI inside Ubuntu/WSL, and it works there:

command -v codex returns the WSL Codex binary, and codex --version returns codex-cli 0.139.0.

So the issue is not only about running Codex CLI inside WSL.

The specific problem is that Codex App creates/recreates a project entry that maps:

/mnt/e/path/to/project

to:

C:\mnt\e\path\to\project

instead of resolving it to:

E:\path\to\project

The project works correctly inside WSL from /mnt/e/..., and Git works there too. The missing working directory warning disappeared only after creating a Windows junction:

C:\mnt\e -> E:\

So this looks like a Codex App Windows/WSL path normalization issue for projects located on non-C drives.

AnhLead · 1 month ago

You need to downgrade codex app - New update broke the path.
Im running 26.527.60818 - which works and you dont lose any chat. - same as before , the newwest version broke it annd ask about codex cli path not found

Leonccaa · 1 month ago

We hit the same issue here with a project on D:\aidev\... / /mnt/d/aidev/.... Codex App mapped it to C:\mnt\d\aidev\..., so the working directory was reported missing.

Temporary workaround on our side was to create a Windows junction:

C:\mnt\d\aidev -> D:\aidev

After that, the generated C:\mnt\d\aidev\... path became valid and the chat could continue.

cyformatician · 1 month ago

Guys, this is yet another regression. It was rectified in previous releases but was recently reintroduced with v26.616.32156

When WSL is enabled for both agent and terminal, Codex app shouldn't be creating any folder, in this case "mnt", on the root of drives whether it's C:\, D:\ or whatever letter ... It's a path translation bug that needs redressing for once and for all!