Codex Desktop WSL agent still creates projectless workspaces under /mnt/c instead of the WSL home

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

OpenAI.Codex MSIX 26.803.10989.0

What subscription do you have?

Not relevant to this local filesystem behavior.

What platform is your computer?

• Windows, x64
• Codex Desktop agent mode: WSL
• WSL2 distribution: Ubuntu 26.04
• WSL kernel: 6.18.33.2-microsoft-standard-WSL2

What issue are you seeing?

When Codex Desktop is configured to run the agent in WSL, a new standalone/projectless chat still receives an automatically generated working directory on the Windows filesystem:

/mnt/c/Users/<windows-user>/Documents/Codex/<date>/<chat-name>

The shell and agent runtime are correctly inside WSL:

SHELL=/bin/bash
WSL_DISTRO_NAME=Ubuntu-26.04
uname: Linux ... microsoft-standard-WSL2

However, the generated projectless workspace is not WSL-native. This means selecting WSL changes the execution runtime but not the default workspace storage location.

For a WSL workflow, the expected default should be under the Linux home, for example:

/home/<wsl-user>/Documents/Codex/<date>/<chat-name>

or another user-configurable WSL-native directory.

I inspected the installed desktop package to understand the behavior. The projectless workspace root is constructed conceptually as:

path.join(os.homedir(), "Documents", "Codex")

On Windows, os.homedir() resolves to the Windows user profile. When WSL mode is active, Codex converts that Windows path to its WSL-mounted representation, producing /mnt/c/Users/.../Documents/Codex. It does not select the WSL user's $HOME.

Other findings:

• Changing CODEX_HOME does not change the projectless workspace root.
• The Agent and Integrated Terminal selectors do not expose a default projectless workspace directory.
• A filesystem symlink is not a reliable workaround because the projectless root is validated as a real directory and symlinks are rejected.
• Launching Codex with a process-local USERPROFILE override pointing at \\wsl.localhost\<distro>\home\<user> may work as an unsupported workaround, but changing the Windows user profile for this purpose is brittle and can affect unrelated application behavior.

What steps can reproduce the bug?

1. Install Codex Desktop on Windows.

2. Ensure WSL2 is installed and a Linux distribution is available.

3. Open Codex Settings.

4. Change the agent from Windows native to WSL.

5. Restart Codex, as required for the agent change.

6. Create a new standalone/projectless chat from Recents.

7. Ask the agent to run:

   echo "$WSL_DISTRO_NAME"
   uname -srm
   pwd
   

8. Observe that the runtime is Linux/WSL, but pwd is under:

   /mnt/c/Users/<windows-user>/Documents/Codex/...
   

What is the expected behavior?

When the selected agent environment is WSL, Codex Desktop should either:

1. Default new projectless chat workspaces to the WSL user's native home, such as $HOME/Documents/Codex; or
2. Provide a supported setting for the projectless/standalone chat workspace root, preferably per execution environment.

A possible UI could be:

Settings → General → Standalone chats → Default workspace directory

It would also be useful to expose a supported config key, with separate Windows-native and WSL values if needed.

The change should apply to newly created chats and should not silently move existing workspaces.

Why this matters

OpenAI's WSL documentation recommends keeping repositories and development work under the Linux home rather than /mnt/c for faster I/O and fewer symlink and permission problems. Projectless chats can create scripts, temporary assets, generated files, work directories, and sometimes Git repositories, so placing them under /mnt/c undermines a major reason for selecting WSL.

This also creates surprising behavior: the UI says the agent is running in WSL, but the app-owned default workspace remains tied to the Windows user profile.

Related issues

• #19909 — general request to make the Chats project directory configurable.
• #19913 — default parent folder for “Start from scratch” projects.
• #22532 — problems with Windows/OneDrive-backed default project locations.
• #33515 — Windows Documents Known Folder handling and a related request for WSL-native defaults.

This report specifically isolates the Windows Desktop + WSL agent mismatch for automatically generated standalone/projectless chat workspaces.

Start by tracing the projectless workspace-root construction described in the issue, including the os.homedir() path and WSL path conversion, then inspect how the root is validated. Reproduce the standalone-chat flow on Windows with a WSL agent; done means new WSL chats use a WSL-native home path without moving existing workspaces.