Allow PowerShell or WSL execution environment to be selected per project and per chat

[MikeeeGit]

What variant of Codex are you using?

App

What feature would you like to see?

Title: Support per-project and per-chat Windows/WSL environments with reliable path handling

I regularly use Codex on Windows 11 with both Windows-native and WSL-native projects:

• C:\platform-tools requires the Windows agent and PowerShell.
• /home/mike/repos/PortfolioWatch requires the WSL agent and an Ubuntu-22.04 terminal.

Currently, changing the Agent or Integrated Terminal between PowerShell and WSL behaves like a global setting. Switching environments can make existing chats appear to disappear, disrupt project grouping, break file and attachment links, and cause the file browser to resolve paths using the wrong environment.

For example, Codex can incorrectly reinterpret WSL paths as Windows paths and produce invalid hybrids such as C:\home\... or C:\mnt\....

These path forms need to remain distinct and be translated deliberately:

• Windows native: C:\platform-tools
• WSL native: /home/mike/repos/PortfolioWatch
• Windows access to WSL: \\wsl.localhost\Ubuntu-22.04\home\mike\repos\PortfolioWatch
• WSL access to Windows: /mnt/c/...

Please add:

1. A default execution environment for each saved project:

   • Windows/PowerShell
   • WSL, including distribution selection
   • Inherit global default

2. A per-chat environment override when creating or reopening a chat.

3. Independent configuration of:

   • Agent execution environment
   • Integrated terminal shell

4. Persistent environment identity for every chat, including its working directory and path format.

5. Correct Windows-to-WSL and WSL-to-Windows path translation for the file browser, attachments and clickable file links.

6. A consistent task list where chats remain visible regardless of the currently selected environment.

Expected behaviour:

• Opening C:\platform-tools automatically restores the Windows agent and PowerShell terminal.
• Opening /home/mike/repos/PortfolioWatch automatically restores the Ubuntu-22.04 WSL agent and terminal.
• Windows-native and WSL-native chats can remain open simultaneously.
• Switching chats does not require changing a global setting or restarting Codex.
• Changing the integrated terminal does not reinterpret the chat’s working directory.
• The file browser never constructs invalid hybrid paths.
• Existing file and attachment links continue working after switching between Windows and WSL chats.

This would make Codex substantially more reliable for Windows power users who work across both native Windows and WSL projects every day.

Additional information

No response

[github-actions]

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

• Windows sandbox setup refresh fails for workspace on \\wsl.localhost UNC path #35380
• [Regression] Windows Desktop 26.721 scheduled automations create blank threads for WSL projects #35134
• New local folder based project Work chats default to Cloud chats #36062
• Codex Desktop: Recents threads disappear after deleting and recreating a Project with the same folders #35135

Powered by Codex Action

[tidytorch]

I am running into this exact problem on Windows 11 with WSL2 and would like to add a concrete workflow proposal.

I regularly work on both:

• Windows-native projects that need PowerShell, Windows-installed tools, and Windows path semantics.
• WSL-native repositories that need a Linux shell, Linux-installed tools, Linux paths, and repositories stored under /home/....

Today, the Codex desktop app treats the Agent Environment as a global setting. Moving between these projects requires opening Settings, switching between Windows native and WSL, and restarting the app. This is disruptive and makes it easy to run a command in the wrong environment. It also makes it difficult to keep Windows and WSL chats open at the same time.

The ideal solution would be similar to VS Code Remote - WSL:

1. Let each saved project/workspace bind to an execution target, such as:
   • Windows native / PowerShell
   • WSL2 / a selected distribution (for example, Ubuntu)
   • SSH or another remote target in the future
2. Automatically connect to or start the correct agent when the project is opened.
3. Allow chats for Windows and WSL projects to remain open concurrently, without changing a global setting or restarting Codex.
4. Persist the execution target, working directory, OS, shell, and path format as part of the project/chat identity.
5. Keep the Agent Environment and Integrated Terminal Shell independently configurable, while allowing a project profile to set both together by default.
6. Display the active target clearly in the UI and preserve correct Windows/WSL path translation for files, attachments, links, Git, and worktrees.

As a fallback or complementary solution, please consider supporting independent local configuration roots for the stable and beta desktop apps. At present, the two Windows app variants share %USERPROFILE%\\.codex, so settings such as the WSL agent selection affect both. An app-specific setting or environment variable could allow, for example:

• Stable: %USERPROFILE%\\.codex
• Beta: %USERPROFILE%\\.codex-beta

Ideally the desktop app would honor an app-specific CODEX_HOME (or provide an equivalent setting), with safe migration/copy support for auth, sessions, skills, and SQLite state.

Per-project execution targets would solve the underlying workflow problem for most users; independent stable/beta configuration would provide a useful isolation mechanism for users who intentionally use the two builds for different environments.

This is related to #23071 and #17173, but I wanted to add the VS Code Remote-style connection model and the stable/beta configuration fallback as one concrete user workflow.

[tidytorch]

One more important part of this request is the quality of the Windows-side WSL workflow itself. The current experience is not comparable to VS Code Remote - WSL.

For a WSL-native repository, the Windows app currently makes users manually navigate or type paths such as \\wsl.localhost\\Ubuntu\\home\\<user>\\<repo> in the Windows file picker. Opening a folder through the Windows UI does not reliably establish a durable WSL project connection, and the app can still treat the project as a Windows-side folder with /mnt/c or other hybrid path semantics.

The Open in VS Code workflow also does not behave like VS Code Remote - WSL: it should open a WSL remote window connected to the selected distribution and Linux working directory, rather than merely opening the UNC path as a Windows folder. For example, a project at /home/alice/src/project in Ubuntu should open as a VS Code WSL: Ubuntu workspace rooted at /home/alice/src/project.

A complete Windows + WSL experience should therefore include:

• A first-class WSL project picker that lists installed distributions and Linux home directories.
• A persistent project connection containing the distro, Linux path, and execution target.
• Automatic reconnection to the same WSL agent when the project is reopened.
• An Open in VS Code (WSL) action that uses the WSL remote connection semantics, not a Windows UNC folder open.
• Correct and explicit separation between /home/..., /mnt/c/..., and \\wsl.localhost\\... paths.
• File previews, attachments, Git, worktrees, and clickable links that preserve the project’s native path identity.
• The ability to keep a Windows-native project and a WSL-native project open concurrently.

This would remove the repeated manual path selection and environment switching that currently makes Windows-side Codex much less convenient than VS Code for mixed Windows/WSL development.