Windows CLI upgrade fails when Git for Windows tar precedes System32 in PATH

What version of Codex CLI is running?

Upgrading from 0.154.0 to 0.155.1 using the standalone Windows installer.

What subscription do you have?

Not supplied; this failure occurs during installation.

Which model were you using?

Not applicable.

What platform is your computer?

Windows x64. Windows PowerShell 5.1.26100.9444 was observed during diagnosis.

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

The upgrade failed in Git Bash first. I then tried PowerShell, which failed with the extraction errors below. The original Git Bash command/output was not retained in this report, so the detailed diagnosis below is based on the PowerShell attempt.

What issue are you seeing?

The Windows installer selects Git for Windows' tar when its usr\bin directory precedes Windows System32 in PATH. Extraction then fails with a drive-letter/remote-host error, followed by a misleading package-layout error.

Command run from PowerShell:

powershell -ExecutionPolicy Bypass -c '$env:CODEX_NON_INTERACTIVE=1; irm https://chatgpt.com/codex/install.ps1 | iex'

Output:

==> Updating Codex CLI from 0.154.0 to 0.155.1
==> Detected platform: Windows (x64)
==> Resolved version: 0.155.1
==> Downloading Codex CLI

tar (child): Cannot connect to C: resolve failed
gzip: stdin: unexpected end of file
/usr/bin/tar: Child returned status 128
/usr/bin/tar: Error is not recoverable: exiting now

Downloaded Codex package archive did not contain the expected package layout.
At line:1024 char:21
    + CategoryInfo          : OperationStopped: (Downloaded Code...package layout.:String) [], RuntimeException
    + FullyQualifiedErrorId : Downloaded Codex package archive did not contain the expected package layout.

Local diagnostics (Get-Command tar -All and where.exe tar) found this order:

C:\Program Files\Git\usr\bin\tar.exe
C:\Windows\System32\tar.exe

The error and executable resolution indicate that GNU tar interprets the colon in a Windows archive path such as C:\... as a remote archive reference and tries to connect to host C.

What steps can reproduce the bug?

1. On Windows x64 with Git for Windows installed, put C:\Program Files\Git\usr\bin before C:\Windows\System32 in PATH.
2. Confirm Get-Command tar selects Git's tar.
3. Run the standalone PowerShell installer command above to upgrade Codex.
4. Observe extraction failure and the subsequent package-layout error.

What is the expected behavior?

The Windows installer should work with Git for Windows tools on PATH, without requiring users to change PATH ordering. It should explicitly select an appropriate Windows extraction tool (for example, native System32 tar) or correctly handle Windows archive paths when GNU tar is selected.

It should also check extraction exit status and report extraction failure directly, rather than continuing to an expected-package-layout error.

Additional information

Installation eventually succeeded after launching a fresh PowerShell process with profiles disabled and System32 prepended to PATH:

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command '$env:PATH = [Environment]::SystemDirectory + [IO.Path]::PathSeparator + $env:PATH; $env:CODEX_NON_INTERACTIVE = 1; irm https://chatgpt.com/codex/install.ps1 | iex'

During troubleshooting, running the installer directly in an existing PowerShell session also hit The property ''OSArchitecture'' cannot be found on this object. That separate symptom already has reports (#20782 and #19559); this issue focuses on tar selection and extraction.

Related: #45273 reports the same drive-letter/GNU tar error in the Sites packaging helper, which is a different component. Searches of open and closed issues for the exact tar error, package-layout error, and Git Bash/installer terms did not find an existing CLI installer report for this failure.

Start with the install.ps1 script used by the standalone Windows installer, then reproduce the issue with Git's usr\bin before System32 in PATH and the reported PowerShell command. Trace tar selection and extraction-status handling. Done means the upgrade succeeds without changing PATH and extraction failures are reported directly rather than as a package-layout error.