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

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

• #35380
• #35134
• #36062
• #35135

Powered by Codex Action

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

1. Automatically connect to or start the correct agent when the project is opened.
2. Allow chats for Windows and WSL projects to remain open concurrently, without changing a global setting or restarting Codex.
3. Persist the execution target, working directory, OS, shell, and path format as part of the project/chat identity.
4. Keep the Agent Environment and Integrated Terminal Shell independently configurable, while allowing a project profile to set both together by default.
5. 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.

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.

Current-build reproducible failure: Windows-native task receives hybrid WSL/Windows runtime

I reproduced a concrete failure on 14 August 2026 (Europe/London) in Codex Desktop package 26.803.10989.0. This turns the environment-selection problem described in this issue into a command-blocking runtime defect.

Executive finding

A task presented as Windows native received all of the following simultaneously:

• a malformed mixed Windows/WSL working directory;
• Linux shell commands dispatched through a Windows process boundary;
• an explicit native PowerShell request rewritten to /bin/sh;
• Browser/Chrome/Computer Use failures at the same bridge;
• repeated approval prompts even after command prefixes were saved.

This was not a Windows ACL/UAC or ComfyUI problem. No reviewed failure contained Access denied, UAC refusal, Windows error 1385, or a sandbox policy denial. Process creation failed before the approved command could start.

Malformed task path

The task workspace was shaped like this (username/project redacted):

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0/app/resources/C:\Users\<user>\Documents\Codex\...

This concatenates:

1. a WSL path to the Windows Store package;
2. the app resources directory;
3. a second absolute Windows C:\Users\... path.

The task UI identified the task as Windows native, but its execution metadata and shell routing did not agree.

Exact command failures

A basic shell command failed before execution:

exec_command failed for `/bin/bash -lc pwd`:
CreateProcess { message: "Rejected(\"Failed to create unified exec process:
No such file or directory (os error 2)\")" }

Using an explicitly valid Linux work directory such as /tmp did not fix it, so the malformed default cwd was not the only fault.

An explicit PowerShell request was still rewritten to a Linux shell and failed:

exec_command failed for `/bin/sh -c '$PSVersionTable.PSVersion.ToString()'`:
CreateProcess { message: "Rejected(\"Failed to create unified exec process:
No such file or directory (os error 2)\")" }

Another observed failure was:

Unable to spawn /mnt/c/Users/<user>/.codex/tmp/arg0/.../codex-linux-sandbox
because it doesn't exist

Therefore the selected PowerShell executable was not being honoured. A Windows process boundary was trying to launch missing Linux paths.

Approval/full-access behaviour

Approvals were accepted and saved for ordinary commands and an explicit Windows PowerShell executable, including ls, find, jq, cp, ip, curl, and PowerShell itself. The task continued to prompt or fail.

This is consistent with failure during environment classification/shell construction, before approval policy can make the requested process runnable. Repeatedly granting permissions cannot repair that state, which is why the UI made this look like a user permissions problem when it was not.

Independent application proof

The blocked task needed to reach a healthy local Windows service at http://127.0.0.1:8188.

• WSL-side access through the inferred gateway timed out.
• A separately forced native Windows PowerShell process reached 127.0.0.1:8188/system_stats successfully.
• The Windows service reported healthy status and the expected GPU/runtime.
• The same native route successfully submitted and completed the workload.

That isolates the failure to Codex Desktop task/runtime routing rather than the local service, firewall, Windows account, or workload.

Reproduction

1. Run Codex Desktop on Windows and select Windows native.
2. Create/open a projectless task under C:\Users\<user>\Documents\Codex.
3. Observe a cwd shaped like /mnt/c/.../app/resources/C:\Users\....
4. Run pwd, including with /tmp as explicit workdir.
5. Observe /bin/bash -lc pwd failing through Windows CreateProcess with os error 2.
6. Explicitly select/call powershell.exe and request $PSVersionTable.PSVersion.
7. Observe dispatch rewritten to /bin/sh -c.
8. Save/approve the executable prefix and retry; the pre-execution failure persists.
9. Attempt Browser/Chrome/Computer Use against a healthy local Windows service; initialization fails through the same environment bridge.

Expected behaviour

Official documentation says the Windows app uses the Windows-native agent by default, where commands run in PowerShell; WSL is a separate agent selection that requires a restart. A Windows-native task must therefore have one coherent contract for host platform, agent platform, cwd namespace, shell, sandbox, plugins, and local-loopback access.

Likely fault boundary

High confidence: Desktop task creation/handoff plus app-server environment state, specifically:

• platform identity;
• cwd normalization;
• unified-exec shell dispatch;
• stale WSL state after switching back to Windows;
• propagation of the same bad namespace into Browser/Computer Use.

The task's local host ID was not sufficient to establish which OS runtime actually owned command execution.

User impact

• Multiple task handoffs failed to preserve the working Windows workflow.
• Browser and local service access were unavailable.
• A render that should take about one minute was blocked for hours.
• Repeated approvals consumed user time without affecting the fault.
• The resulting experience strongly suggested account/Windows permissions were at fault even though the evidence says otherwise.

Closely matching open reports

• #30435 — near-exact malformed .../app/resources/C:\Users\... cwd plus Browser/Computer Use failure.
• #22185 — exact Windows CreateProcess attempt for /bin/bash and ENOENT.
• #23894 — WSL app-server remains active after switching back to Windows.
• #26096 — Windows task/workspace binding runs the wrong platform and fails on /bin/bash.
• #34458 — Browser, Chrome, and Computer Use fail through the shared Windows/WSL bridge.
• #25216 — umbrella release-gate request for a single Windows/WSL environment contract.

This remains reproducible in the 26.803 package family. Please treat it as a current runtime bug, not only an enhancement request. Private task/thread IDs and sanitized logs can be supplied directly to OpenAI Support rather than posted publicly.