Windows tool shell contains PATH, breaking MSYS2 toolchain calling convention

Summary

On Windows, Codex (both CLI and msstore GUI) appears to launch commands with both PATH and Path present in the child process environment.

This breaks MSYS2 Git (installed with mingw-w64-ucrt-x86_64-git packaging) when Codex wants to run subcommands implemented as shell scripts, such as:

git submodule status

The same Git executable works correctly in a normal PowerShell 7 / Windows Terminal session.

Environment

• OS: Windows 10 22H2 19045.7417
• Shell: PowerShell 7
• Git executable: C:\msys64\cmd\git.exe
• Git exec path: C:/msys64/ucrt64/libexec/git-core
• Affected command: git submodule status
• Context where it fails: Codex-launched shell command
• Context where it works: normal Windows Terminal / PowerShell 7

Reproduction Commands

> Get-Command git -All | Format-List CommandType,Source,Definition,Path
CommandType : Application
Source      : C:\msys64\cmd\git.exe
Definition  : C:\msys64\cmd\git.exe
Path        : C:\msys64\cmd\git.exe

> where.exe git
C:\msys64\cmd\git.exe

> git --exec-path
C:/msys64/ucrt64/libexec/git-core

> cmd.exe /c set path
Path= ... ... ...
PATHEXT= ... ... ...
[no PATH in output]

git submodule status

Expected Behavior

Codex should run git submodule status the same way like the command does in a normal Windows Terminal / PowerShell 7 session using the same git.exe.

Actual Behavior

Inside Codex, git submodule status fails because the git-submodule shell script cannot find POSIX helper commands and Git shell setup files.

• Ran git submodule status
  └ C:/msys64/ucrt64/libexec/git-core\git-submodule: 行 7: basename: 未找到命令 (means command not found)
    C:/msys64/ucrt64/libexec/git-core\git-submodule: 行 7: sed: 未找到命令
    C:/msys64/ucrt64/libexec/git-core\git-submodule: 第 22 行：.: git-sh-setup: 未找到文件 (means file not found)

Working Comparison

In a normal Windows Terminal / PowerShell 7 session, the executable it self is resolved to:

C:\msys64\cmd\git.exe

and:

git --exec-path

returns:

C:/msys64/ucrt64/libexec/git-core

but git submodule status works.

Also, in the working Windows Terminal session:

cmd.exe /c set path

shows only a normal Path=... entry, not both PATH=... and Path=....

Diagnosis

The failure appears to be caused by Codex creating or preserving duplicate environment variables whose names differ only by case:

PATH=...
Path=...

Windows environment variable lookup is case-insensitive for most native Windows programs, but MSYS2/Cygwin-style runtimes import the Windows environment into a POSIX-like environment where PATH has special handling.

When both PATH and Path are present, MSYS2 Git appears to receive an inconsistent or incomplete POSIX PATH when executing shell-script Git subcommands.

git submodule status eventually runs:

C:/msys64/ucrt64/libexec/git-core/git-submodule

That script depends on POSIX tools and Git shell setup files, including:

basename
sed
. git-sh-setup

Inside Codex, those fail to resolve. In a clean MSYS2/UCRT64 shell environment, the same command works.

This suggests the repository and Git installation are not the root problem. The failure is specific to the environment block passed to commands by Codex on Windows.

Additional Evidence

Running the command through an explicit MSYS2/UCRT64 Bash session works:

$env:MSYSTEM='UCRT64'
$env:CHERE_INVOKING='1'
C:\msys64\usr\bin\bash.exe -lc 'cd /c/Users/[my/repo/path] && git submodule status'

This indicates that MSYS2 Git itself is functional when it receives a sane POSIX/MSYS2 environment.

A separate test using a manually constructed clean child-process environment also changed the failure mode away from missing basename / sed / git-sh-setup, further supporting that the issue is environment-related rather than repository-related.

Suggested Fix

Codex should avoid passing duplicate PATH/Path environment variables to child processes on Windows.

Before spawning shell commands, normalize the environment block so that only one canonical path variable exists, preferably preserving the normal Windows casing: Path, and removing any duplicate case variants such as: PATH

This should make Codex behavior consistent with normal Windows Terminal / PowerShell sessions and avoid breaking MSYS2/Cygwin-based tools.