›_ Codex Issues
Codex Issues / #19171

Windows: Codex 0.123.0 injects both PATH and Path into the shell environment, breaking PowerShell Env provider and causing intermittent shell startup failures

Open 💬 4 comments Opened Apr 23, 2026 by TiidSizaan
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.123.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows x64

What terminal emulator and version are you using (if applicable)?

Codex Desktop app on Windows, with the npm-installed codex also on PATH

What issue are you seeing?

On Windows, Codex appears to construct a malformed process environment for shell execution by injecting both PATH and Path into the same process environment block.

Because Windows environment variables are case-insensitive, PowerShell's Env: provider treats this as a duplicate-key collision and fails with:

Get-ChildItem : An item with the same key has already been added.

In earlier threads on the same machine, this also correlated with Codex shell startup failures before command execution, including:

Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d.

So the root problem here appears to be malformed Windows env var merging in Codex, not a repo-specific issue.

What steps can reproduce the bug?

In a Codex Windows session:

  1. Confirm the installed CLI version:

``powershell
codex --version
`
Observed:
`text
codex-cli 0.123.0
``

  1. Confirm the npm package version:

``powershell
npm list -g @openai/codex --depth=0
`
Observed:
`text
@openai/codex@0.123.0
``

  1. Inspect the effective process environment from within the Codex shell context:

``powershell
cmd /c "set PATH & set Path"
`
Observed: both PATH= and Path=` are present in the same process environment.

  1. Try enumerating the PowerShell env provider:

``powershell
Get-ChildItem Env:
`
Observed:
`text
Get-ChildItem : An item with the same key has already been added.
``

  1. Compare against the actual Windows environment sources:

``powershell
reg query "HKCU\Environment"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
`
Observed: only Path exists in the registry sources, not a separate uppercase PATH`.

What is the expected behavior?

Codex should normalize Windows environment variables case-insensitively before spawning the shell.

Expected behavior:

  • only one canonical Path entry should be present in the spawned process environment
  • Get-ChildItem Env: should succeed normally
  • shell startup should not intermittently fail due to malformed env state

What do you see instead?

Codex spawns a shell environment that includes both PATH and Path, which breaks PowerShell env enumeration and appears to contribute to intermittent shell startup failures.

Additional information

Concrete local evidence:

  • where codex resolves the npm global install first:
  • C:\Users\hnili\AppData\Roaming\npm\codex
  • In the Codex shell process, both PATH and Path are present.
  • In HKCU\Environment and HKLM\...\Environment, only Path exists.
  • So the duplicate is being introduced during Codex environment construction, not inherited directly from Windows registry state.

This looks distinct from the broader 8009001d symptom reports because it provides a narrower repro and a likely root cause.

Possibly related:

  • #19100
  • #13917
  • #14057
  • #18465

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19100
  • #18248
  • #17325
  • #18465

Powered by Codex Action

doublemover · 4 months ago

I think this is confusing the shit out of 5.5 on 0.124 too, things like gh issue view don't work (401 Try authenticating with: gh auth login), and with full permissions enabled nothing works (same error), but when it asks for permissions to ie check stuff in via gh, those commands work fine without any weird path/auth issues.

I'd really prefer that gh continues working normally and that you don't funnel codex into using the damned git app, which has more issues than gh itself and I will not be reporting bugs for other than that I can't seem to disable it or make it stop trying to use it.

sharp-confusion · 3 months ago

Same Issue. This also breaks vstest.console.exe

VSTest-Version 18.5.1 (x64)

Die Testausführung wird gestartet, bitte warten...
Insgesamt 1 Testdateien stimmten mit dem angegebenen Muster überein.
1,3733

Fehler beim Starten von Testhost: System.ArgumentException: Das Element wurde bereits hinzugefügt. Schlüssel im Wörterbuch: "Path". Hinzuzufügender Schlüssel: "PATH".
   bei System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add)
   bei System.Diagnostics.ProcessStartInfo.get_EnvironmentVariables()
   bei Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.ProcessHelper.<>c__DisplayClass9_0.<LaunchProcess>g__InitializeAndStart|0() in /_/src/Microsoft.TestPlatform.PlatformAbstractions/common/System/ProcessHelper.cs:Zeile 118.
   bei Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.ProcessHelper.LaunchProcess(String processPath, String arguments, String workingDirectory, IDictionary`2 envVariables, Action`2 errorCallback, Action`1 exitCallBack, Action`2 outputCallBack) in /_/src/Microsoft.TestPlatform.PlatformAbstractions/common/System/ProcessHelper.cs:Zeile 71.
   bei Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Hosting.DefaultTestHostManager.LaunchHost(TestProcessStartInfo testHostStartInfo, CancellationToken cancellationToken) in /_/src/Microsoft.TestPlatform.TestHostProvider/Hosting/DefaultTestHostManager.cs:Zeile 543.
   bei Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Hosting.DefaultTestHostManager.LaunchTestHostAsync(TestProcessStartInfo testHostStartInfo, CancellationToken cancellationToken) in /_/src/Microsoft.TestPlatform.TestHostProvider/Hosting/DefaultTestHostManager.cs:Zeile 171.
   bei Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(IEnumerable`1 sources, String runSettings) in /_/src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyOperationManager.cs:Zeile 185.
Testlauf abgebrochen.
KKSAma-G · 16 days ago

I can reproduce the same root cause in current Codex Desktop on Windows, with an additional deterministic downstream failure in pnpm exec.

Environment:

  • Windows x64, build 26200.8655
  • PowerShell 7.6.4
  • Node 24.16.0
  • pnpm 11.9.0 (also reproduced with pnpm 11.16.0)

Inside a fresh Codex task:

[Environment]::GetEnvironmentVariables('Process').Keys |
  Where-Object { $_ -ceq 'PATH' -or $_ -ceq 'Path' }
# Path
# PATH

The Windows user and machine environment sources contain only one Path, so the duplicate is introduced in the Codex-spawned environment.

A deterministic consequence:

  • pnpm bin reports the correct project node_modules\.bin
  • pnpm exec eslint --version and pnpm exec vitest --version fail because the local commands are not found
  • the local .cmd shims and direct Node entry points work
  • pnpm run lint works

This matches Node's documented Windows behavior: when an env object contains case variants such as PATH and Path, only the first case-insensitive match after sorting is passed to the child process. pnpm adds node_modules\.bin to one variant, while the child process receives the other.

Normalizing the process environment to a single Path immediately before invoking pnpm makes pnpm exec, lint, typecheck, and tests pass consistently.

I also tried using Codex shell_environment_policy to exclude inherited PATH and explicitly set one Path, then fully restarted Desktop. Fresh tasks still received both PATH and Path, suggesting Desktop adds the second key after that policy is applied.

This is not repository-specific and can affect any Windows tool that treats environment keys case-insensitively or modifies one PATH variant before spawning a child process.