Windows tool shell contains both Path and PATH, breaking Start-Process with redirected stdio

Open 💬 2 comments Opened Jun 10, 2026 by sosplease

Summary

Codex Desktop on Windows launches tool shells with both Path and PATH in the process environment. Windows environment variable lookup is case-insensitive, and this duplicate breaks PowerShell/.NET APIs that copy the environment into a case-insensitive dictionary.

Environment

OS: Windows
Codex Desktop package observed: OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0
Workspace shell: Windows PowerShell

Reproduction

In a normal PowerShell session outside Codex:

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

Observed outside Codex:

Path

Inside a Codex tool shell, run the same command:

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

Observed inside Codex:

Path
PATH

The two values are identical except for Codex-added path entries.

Then attempt a normal background launch with redirected stdio:

$out = Join-Path (Get-Location) 'server.out.log'
$err = Join-Path (Get-Location) 'server.err.log'
Start-Process -FilePath node -ArgumentList 'server.mjs' -WorkingDirectory (Get-Location) -WindowStyle Hidden -RedirectStandardOutput $out -RedirectStandardError $err -PassThru

Observed error:

Start-Process : Item has already been added. Key in dictionary: 'Path'  Key being added: 'PATH'

Expected behavior

On Windows, Codex should normalize environment variable keys case-insensitively before launching tool shells/commands. It should preserve the canonical Windows Path key and update that key when prepending Codex paths, rather than creating a separate PATH key.

Why this matters

This prevents Codex from using normal PowerShell Start-Process patterns for local dev servers with redirected stdout/stderr. Foreground node server.mjs works, but normal detached process launching from Codex fails because of the duplicate environment key.

Suggested fix

Before spawning Windows shell/tool commands, normalize env keys case-insensitively. For the path variable specifically, keep one canonical key:

function normalizeWindowsEnv(env: Record<string, string>) {
  if (process.platform !== 'win32') return env;

  const output: Record<string, string> = {};
  const seen = new Map<string, string>();

  for (const [key, value] of Object.entries(env)) {
    const lower = key.toLowerCase();

    if (lower === 'path') {
      const canonical = seen.get('path') ?? 'Path';
      output[canonical] = value;
      seen.set('path', canonical);
      continue;
    }

    if (!seen.has(lower)) {
      seen.set(lower, key);
      output[key] = value;
    }
  }

  return output;
}

Then prepend Codex-specific path entries to the retained Path value instead of adding PATH.

View original on GitHub ↗

2 Comments

Dimmu141 · 1 month ago

Confirmed on Codex Desktop for Windows with app package 26.721.4979.0_x64 and codex-command-runner-0.146.0-alpha.3.1.exe.

The process environment inside the Codex tool shell contains both Path and PATH, while the Windows user and machine environments each contain only the normal Path key. In this reproduction, the duplicate values were identical.

A bounded test after fully restarting Codex produced:

Start-Process without redirected streams: succeeds and exits normally.
The same launch with -RedirectStandardOutput and -RedirectStandardError: fails with Item has already been added. Key in dictionary: 'Path' Key being added: 'PATH'.
Restarting Codex did not remove the duplicate process-level keys.

This appears to be injected by the Codex command-runner environment rather than by the user's Windows environment. No environment values or project data are included here.

eglis007 · 29 days ago

I can confirm that this issue is still reproducible on my machine.

Environment

Windows: Microsoft Windows NT 10.0.26200.0
Windows PowerShell: 5.1.26100.8972
PowerShell edition: Desktop
Codex: Windows desktop app

Control test outside Codex

In a normal Windows PowerShell window opened directly from Windows:

Only one canonical Path environment variable exists.
The following Start-Process test succeeds with exit code 0.

$probe = Start-Process `
  -FilePath $env:ComSpec `
  -ArgumentList @("/d", "/c", "exit", "0") `
  -WindowStyle Hidden `
  -Wait `
  -PassThru

$probe.ExitCode

Result:

0
Behavior inside the Codex tool shell

Inside a PowerShell tool process launched by the Codex desktop app, the process environment contains both:

Path
PATH

The two variables have identical values and lengths.

When Codex runs Start-Process, PowerShell throws:

An item with the same key has already been added.
Existing key: Path
Key being added: PATH

I also checked the Windows user and system environment settings:

HKCU\Environment
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Both contain only one canonical Path entry. There is no duplicate PATH entry in the Windows registry.

Normalizing the Codex PowerShell process environment so that only one canonical Path entry remains immediately fixes Start-Process.

This issue affected a local Node/Vite development server workflow involving background process startup, redirected stdout/stderr, PID tracking, and an HTTP health check.

Based on the comparison between normal PowerShell and the Codex tool shell, the duplicate variable appears to be introduced when Codex constructs or merges the Windows tool-process environment.

I have attached a screenshot of the successful control test in normal Windows PowerShell.

<img width="928" height="355" alt="Image" src="https://github.com/user-attachments/assets/6ff0e083-2767-4b5e-815b-512734004e78" />