Codex Desktop injects both Path and PATH into command environment on Windows, breaking MSBuild/Roslyn

Open 💬 4 comments Opened Mar 21, 2026 by yuenchiusouk

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary
On Windows, Codex Desktop launches shell commands with both Path and PATH environment variables present in the same process. Normal PowerShell on the same machine only has Path. This causes .NET/MSBuild/Roslyn builds to fail with duplicate-key environment handling errors.

Environment

OS: Windows 11
Codex Desktop version: OpenAI.Codex_26.313.5234.0_x64
Shell used by Codex: cmd / pwsh
Project type affected: ASP.NET WebForms / MSBuild / Roslyn build
Steps to reproduce

Open Codex Desktop on Windows.
Run:
cmd /c set | findstr /r /c:"^PATH=" /c:"^Path="
Observe that both PATH= and Path= are present.
Run an MSBuild-based .NET build in Codex Desktop.
Observe build failure.
Expected result

Only one path environment variable should exist in the child process, effectively Path.
Actual result

Codex command processes contain both Path and PATH.
MSBuild/Roslyn fails with:
error MSB3883: Unexpected exception
Item has already been added. Key in dictionary: 'Path' Key being added: 'PATH'
Control comparison

In normal Windows PowerShell outside Codex Desktop:
Get-ChildItem Env: | Where-Object { $_.Name -match '^(?i)path$' }
only shows Path.
The same SFInsurance.csproj build succeeds outside Codex Desktop.
Extra detail

Inside Codex, PATH appears to include an extra prepended C:\Program Files\PowerShell\7, while Path contains the normal inherited Windows value.
The process chain observed in Codex includes codex-command-runner.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 5 months ago

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

#15295

Powered by Codex Action

jasondegraw · 4 months ago

I'm also seeing this on Windows 11 with Codex 26.325.31654 with a plain C++ solution.

gotoh · 21 days ago

I can reproduce this independently in a newer Codex Desktop build (MSIX package OpenAI.Codex_26.730.8199.0_x64) on Windows.

The following investigation was performed by Codex Desktop itself in the affected environment. It inspected the current process environment, compared it with a normal Command Prompt on the same machine, invoked Visual Studio MSBuild directly, and inspected the installed Codex package and sandbox helper files.

This is not only an MSBuild PATH-discovery problem. Invoking Visual Studio MSBuild by its full path still reaches Roslyn and then fails with MSB3883 because the child environment contains both keys. Roslyn imports environment variables into a case-insensitive dictionary:

MSB3883: Unexpected exception:
System.ArgumentException: An item with the same key has already been added.
Dictionary key: 'PATH'  Key being added: 'Path'

Outside Codex, the same user's normal Command Prompt has only Path; the duplicate is introduced into the Codex command environment. Codex Desktop's own inspection also found windows-sandbox-rs/src/env.rs, PATH, and .sbx-denybin strings in the packaged executable, and confirmed the injected sandbox/runtime paths in the Codex child environment. This is evidence of the environment construction path, not merely a shell configuration issue.

Impact: this blocks validation/build of ordinary .NET Framework and SDK-style projects in Codex Desktop. A clean, manually constructed child environment containing exactly one case-insensitive Path variable makes the same build succeed, confirming the cause. That workaround is not viable for normal users.

Suggested fix: when sandbox/runtime paths are injected on Windows, merge them into the inherited Path variable rather than creating PATH; before CreateProcess, canonicalize/deduplicate environment variable names using ordinal case-insensitive comparison. Please add a regression test that asserts no Windows child process receives duplicate environment keys under case-insensitive comparison.

AFayziev · 9 days ago

Issue exists for weeks now in Codex App.