WinGet install exposes target-suffixed executable name instead of codex.exe

What version of Codex CLI is running?

codex-cli 0.98.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.3

What platform is your computer?

Microsoft Windows NT 10.0.26220.0 x64

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

PowerShell

What issue are you seeing?

After installing Codex via WinGet (winget install OpenAI.Codex) on Windows, the installed executable is target-suffixed (for example codex-x86_64-pc-windows-msvc.exe) instead of codex.exe.

This makes the default command name inconsistent and can require manual rename/shim setup.

No runtime stack trace appears; this is a packaging/install behavior issue.

What steps can reproduce the bug?

1. On Windows, run:

``powershell
winget install OpenAI.Codex
``

1. Check installed package metadata:

``powershell
winget show OpenAI.Codex
`
It references installer assets like:
codex-x86_64-pc-windows-msvc.exe.zip`

1. Inspect the installed files under:

%LOCALAPPDATA%\Microsoft\WinGet\Packages\OpenAI.Codex_*

1. Observe that the executable filename is target-suffixed (e.g., codex-x86_64-pc-windows-msvc.exe) instead of codex.exe.

What is the expected behavior?

After WinGet install, codex.exe should be present/provided directly so users can run codex without manually renaming files or creating a custom shim.

Additional information

• This appears tied to release packaging naming for Windows artifacts.
• In openai/codex, release workflow stages Windows binaries as codex-${{ matrix.target }}.exe.
• A minimal fix is to include codex.exe in the main Windows bundle zip in addition to the target-suffixed filename, keeping backward compatibility.
• I have a small patch ready and can submit a PR if invited (per contribution policy).