Skip to content

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

Open

Description

@id0108887-star

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
  5. 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
  6. Start a new project chat.

  7. Restart Codex App or reopen the project.

  8. 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

Activity

  1. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jun 14, 2026
  2. id0108887-star commented on Jun 14, 2026

    @id0108887-star
    Author

    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.

  3. 888luck8 commented on Jun 14, 2026

    @888luck8

    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 🌹

  4. id0108887-star commented on Jun 14, 2026

    @id0108887-star
    Author

    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.

  5. AnhLead commented on Jun 14, 2026

    @AnhLead

    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

  6. Leonccaa commented on Jun 14, 2026

    @Leonccaa

    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.

  7. cyformatician commented on Jun 19, 2026

    @cyformatician

    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!

  8. cyformatician commented on Aug 5, 2026

    @cyformatician

    This has been fixed in the latest release - version 26.730.61639

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions