Agent environment and integrated terminal shell tied to the project rather than general setting for windows codex app

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

• #16285
• #16579
• #16717

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Support alternate WSL distros besides the default #16285 Windows: allow configuring the default session shell via config #16579 * feat: configurable Windows agent shell (powershell/git-bash) #16717 _Powered by Codex Action_

The issue with other issues is not matching but they are overlapping, so if the implementation is done per session wise i think that will solve the other issues discussed in #16285 #16579 #16717 but they are other issues with current implementation so I think my request is more broader in general, solving multiple issues with one solution.

But if others think this is a duplicate I am happy to close the issue

I have the same need with a concrete mixed Windows + WSL workflow.

I use Codex Desktop on Windows with both WSL-native repositories and Windows-native projects.

Environment

• OS/Runtime: Windows 11 host with WSL2
• Codex Desktop version: 26.506.31421
• Windows-native project path example: C:\Users\<user>\Dev\Playground
• WSL distro: Ubuntu 24.04.4 LTS
• Kernel: 6.6.87.2-microsoft-standard-WSL2
• WSL-native repository path example: /home/<user>/Dev/<repo>

Use case

Examples:

• WSL-native repositories:
• https://github.com/scramble-robot/questix
• https://github.com/Yuichiroh-Kobayashi/VAMeter-Edu
• expected agent environment: WSL
• expected integrated terminal shell: WSL / bash

• Windows-native project:
• local Playground / experiments under C:\Users\...\Dev\...
• expected agent environment: Windows native
• expected integrated terminal shell: PowerShell

Current problem

The current global setting makes this difficult and error-prone.

If I set Codex Desktop globally to WSL:

• WSL-native repositories work as expected.
• Windows-native projects are opened with WSL assumptions, for example /mnt/c/... path semantics and a WSL terminal.

If I set Codex Desktop globally to Windows native:

• Windows-native projects would use the expected Windows environment.
• WSL-native repositories would lose the expected Linux environment, shell, paths, and tooling assumptions.

In practice, switching between projects requires manually changing global settings and checking carefully that commands are not being run in the wrong environment.

Why this matters

This is more than a shell preference. These project types differ in:

• path semantics
• shell syntax
• environment variables
• toolchain location
• Git / GitHub CLI configuration
• expected working directory

For WSL-native repositories, I expect Linux paths, Linux shell behavior, and Linux-side tools/configuration.

For Windows-native projects, I expect Windows paths, PowerShell behavior, and Windows-side tools/configuration.

Using one global setting for both makes mixed Windows + WSL development fragile.

Expected behavior

Codex Desktop should remember the Agent environment and Integrated terminal shell per project/workspace, while keeping the current global setting as the default fallback.

For example:

| Project type | Path type | Agent environment | Integrated terminal |
|---|---|---|---|
| WSL-native repository | /home/<user>/Dev/... | WSL | WSL / bash |
| Windows-native project | C:\Users\<user>\... | Windows native | PowerShell |

Optional auto-detection would also help:

• WSL paths such as /home/... or \\wsl.localhost\... default to WSL
• Windows paths such as C:\... default to Windows native
• users can override the detected setting per project

Related issues

This request is narrower than the broader WSL compatibility/worktree issues such as #14468 and #18506.

Those are related, but this issue is specifically about remembering the Agent environment and Integrated terminal shell per project/workspace.

Additional data point after further testing:

With my current global Agent environment set to WSL, I opened the local Playground folder through the Windows GUI flow:

• New project
• Use existing folder
• Selected the folder through the Windows folder picker

I expected this Windows-side folder to either open with a Windows-native runtime or provide an obvious per-project way to choose the runtime. However, the resulting Codex chat still ran under WSL.

Observed from that Playground chat:

runtime: WSL2
shell: /bin/bash
git: /usr/bin/git
gh: /usr/bin/gh
PWD: /mnt/c/Users/<user>/Dev/Playground

So even when the folder is selected through the Windows GUI, the project can still end up running with WSL runtime assumptions when the global Agent environment is set to WSL.

This is the concrete failure mode behind my earlier comment: for mixed Windows + WSL workflows, Codex Desktop needs to remember or allow overriding the Agent environment and integrated terminal shell per project/workspace, instead of only globally.