WinGet package omits code-mode host, exposes no reliable `codex` command, and declares helpers as entry points
What version of Codex CLI is running?
codex-cli 0.147.0
What subscription do you have?
ChatGPT Pro 5x
Which model were you using?
_No response_
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
PowerShell 7.6.5
Codex doctor report
<details>
<summary>codex-x86_64-pc-windows-msvc doctor --json</summary>
{
"schemaVersion": 1,
"generatedAt": "1786958898s since unix epoch",
"overallStatus": "warning",
"codexVersion": "0.147.0",
"checks": {
"app_server.status": {
"id": "app_server.status",
"category": "app-server",
"status": "ok",
"summary": "background server is not running",
"details": {
"control socket": "C:\\Users\\alexa\\.codex\\app-server-control\\app-server-control.sock",
"daemon state dir": "C:\\Users\\alexa\\.codex\\app-server-daemon",
"mode": "ephemeral",
"pid file": "C:\\Users\\alexa\\.codex\\app-server-daemon\\app-server.pid (missing)",
"settings": "C:\\Users\\alexa\\.codex\\app-server-daemon\\settings.json (missing)",
"status": "not running",
"update-loop pid file": "C:\\Users\\alexa\\.codex\\app-server-daemon\\app-server-updater.pid (missing)"
},
"remediation": null,
"durationMs": 0
},
"auth.credentials": {
"id": "auth.credentials",
"category": "auth",
"status": "ok",
"summary": "auth is configured",
"details": {
"auth file": "C:\\Users\\alexa\\.codex\\auth.json",
"auth storage mode": "File",
"stored API key": "false",
"stored ChatGPT tokens": "true",
"stored agent identity": "false",
"stored auth mode": "chatgpt"
},
"remediation": null,
"durationMs": 0
},
"config.load": {
"id": "config.load",
"category": "config",
"status": "ok",
"summary": "config loaded",
"details": {
"CODEX_HOME": "C:\\Users\\alexa\\.codex",
"config.toml": "C:\\Users\\alexa\\.codex\\config.toml",
"config.toml parse": "ok",
"cwd": "C:\\Users\\alexa",
"enabled feature flags": "<redacted>",
"feature flag overrides": "apps=false",
"feature flags enabled": "38",
"log dir": "C:\\Users\\alexa\\.codex\\log",
"mcp servers": "17",
"model": "gpt-5.6-sol",
"model provider": "openai",
"sqlite home": "C:\\Users\\alexa\\.codex"
},
"remediation": null,
"durationMs": 0
},
"git.environment": {
"id": "git.environment",
"category": "git",
"status": "ok",
"summary": "git version 2.55.0.windows.3",
"details": {
"PATH git #1": "C:\\Program Files\\Git\\cmd\\git.exe",
"PATH git entries": "1",
"git build options": "git version 2.55.0.windows.3; cpu: x86_64; built from commit: 52ca1113d651127f89477a8763f86ab20f645e1d; sizeof-long: 4; sizeof-size_t: 8; shell-path: D:/git-sdk-64/usr/bin/sh; rust: disabled; feature: fsmonitor--daemon; gettext: enabled; libcurl: 8.21.0; OpenSSL: OpenSSL 3.5.7 9 Jun 2026; zlib: 1.3.2; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1",
"git exec path": "C:/Program Files/Git/mingw64/libexec/git-core",
"git version": "git version 2.55.0.windows.3",
"repo detected": "false",
"selected git": "C:\\Program Files\\Git\\cmd\\git.exe"
},
"remediation": null,
"durationMs": 52
},
"installation": {
"id": "installation",
"category": "install",
"status": "ok",
"summary": "installation looks consistent",
"details": {
"current executable": "C:\\Users\\alexa\\AppData\\Local\\Microsoft\\WinGet\\Packages\\OpenAI.Codex__DefaultSource\\codex-x86_64-pc-windows-msvc.exe",
"install context": "other",
"managed by bun": "false",
"managed by npm": "false",
"managed by pnpm": "false",
"managed package root": "not set"
},
"remediation": null,
"durationMs": 52
},
"mcp.config": {
"id": "mcp.config",
"category": "mcp",
"status": "warning",
"summary": "MCP configuration has optional issues",
"details": {
"configured servers": "17",
"disabled servers": "12",
"optional reachability failed": "perplexity: https://api.perplexity.ai/mcp (HEAD request timed out; GET request timed out)",
"stdio servers": "2",
"streamable_http servers": "15"
},
"remediation": "Set the missing MCP env vars or disable the affected server.",
"durationMs": 8173
},
"network.env": {
"id": "network.env",
"category": "network",
"status": "ok",
"summary": "network-related environment looks readable",
"details": {
"proxy env vars": "none"
},
"remediation": null,
"durationMs": 0
},
"network.provider_reachability": {
"id": "network.provider_reachability",
"category": "reachability",
"status": "ok",
"summary": "active provider endpoints are reachable over HTTP",
"details": {
"ChatGPT base URL": "https://chatgpt.com/backend-api/ reachable (HTTP 403)",
"reachability mode": "ChatGPT auth"
},
"remediation": null,
"durationMs": 121
},
"network.websocket_reachability": {
"id": "network.websocket_reachability",
"category": "websocket",
"status": "ok",
"summary": "Responses WebSocket handshake succeeded",
"details": {
"DNS": "2 IPv4, 0 IPv6, first IPv4",
"auth mode": "chatgpt",
"connect timeout": "15000 ms",
"endpoint": "wss://chatgpt.com/backend-api/<redacted>",
"handshake result": "HTTP 101 Switching Protocols",
"model provider": "openai",
"models etag present": "true",
"provider name": "OpenAI",
"proxy env vars": "none",
"reasoning header": "false",
"server model present": "false",
"supports websockets": "true",
"wire API": "responses"
},
"remediation": null,
"durationMs": 728
},
"runtime.provenance": {
"id": "runtime.provenance",
"category": "runtime",
"status": "ok",
"summary": "running local build on windows-x86_64",
"details": {
"commit": "unknown",
"current executable": "C:\\Users\\alexa\\AppData\\Local\\Microsoft\\WinGet\\Packages\\OpenAI.Codex__DefaultSource\\codex-x86_64-pc-windows-msvc.exe",
"install method": "other",
"platform": "windows-x86_64",
"version": "0.147.0"
},
"remediation": null,
"durationMs": 0
},
"runtime.search": {
"id": "runtime.search",
"category": "search",
"status": "ok",
"summary": "search is OK (system)",
"details": {
"search command": "rg.exe",
"search command readiness": "ripgrep 15.2.0 (rev e89fff89ac)",
"search provider": "system"
},
"remediation": null,
"durationMs": 16
},
"sandbox.helpers": {
"id": "sandbox.helpers",
"category": "sandbox",
"status": "ok",
"summary": "sandbox configuration is readable",
"details": {
"approval policy": "OnRequest",
"codex-linux-sandbox helper": "none",
"execve wrapper helper": "none",
"filesystem sandbox": "restricted",
"network sandbox": "enabled"
},
"remediation": null,
"durationMs": 0
},
"state.paths": {
"id": "state.paths",
"category": "state",
"status": "ok",
"summary": "state paths and databases are inspectable",
"details": {
"CODEX_HOME": "C:\\Users\\alexa\\.codex (dir)",
"active rollout files": "93 files, 217537856 total bytes, 2339116 average bytes",
"archived rollout files": "2 files, 810149 total bytes, 405074 average bytes",
"goals DB": "C:\\Users\\alexa\\.codex\\goals_1.sqlite (file)",
"goals DB integrity": "ok",
"log DB": "C:\\Users\\alexa\\.codex\\logs_2.sqlite (file)",
"log DB integrity": "ok",
"log dir": "C:\\Users\\alexa\\.codex\\log (missing)",
"memories DB": "C:\\Users\\alexa\\.codex\\memories_1.sqlite (file)",
"memories DB integrity": "ok",
"queue DB": "C:\\Users\\alexa\\.codex\\queue_1.sqlite (file)",
"queue DB integrity": "ok",
"sqlite home": "C:\\Users\\alexa\\.codex (dir)",
"state DB": "C:\\Users\\alexa\\.codex\\state_5.sqlite (file)",
"state DB integrity": "ok",
"thread history DB": "C:\\Users\\alexa\\.codex\\thread_history_1.sqlite (file)",
"thread history DB integrity": "ok"
},
"remediation": null,
"durationMs": 937
},
"state.rollout_db_parity": {
"id": "state.rollout_db_parity",
"category": "threads",
"status": "ok",
"summary": "rollout files and state DB thread inventory agree",
"details": {
"default model provider": "openai",
"rollout DB active files": "93",
"rollout DB active rows": "93",
"rollout DB archive mismatches": "0",
"rollout DB archived files": "2",
"rollout DB archived rows": "2",
"rollout DB duplicate DB paths": "0",
"rollout DB duplicate rollout thread ids": "0",
"rollout DB malformed file names": "0",
"rollout DB missing active rows": "0",
"rollout DB missing archived rows": "0",
"rollout DB model providers": "openai=92, custom-gateway=3",
"rollout DB rows": "95",
"rollout DB scan cap reached": "false",
"rollout DB scan errors": "0",
"rollout DB sources": "cli=87, vscode=5, subagent:thread_spawn=3",
"rollout DB stale rows": "0"
},
"remediation": null,
"durationMs": 82
},
"system.environment": {
"id": "system.environment",
"category": "system",
"status": "ok",
"summary": "OS language en-US",
"details": {
"EDITOR": "not set",
"VISUAL": "not set",
"os": "Windows 10.0.26200 (Windows 11 Professional) [64-bit]",
"os language": "en-US",
"os type": "Windows",
"os version": "10.0.26200"
},
"remediation": null,
"durationMs": 0
},
"terminal.env": {
"id": "terminal.env",
"category": "terminal",
"status": "ok",
"summary": "terminal metadata was detected",
"details": {
"WT_SESSION": "present",
"color output": "enabled",
"console input code page": "850",
"console output code page": "850",
"stderr console mode": "0x00000007 (VT processing: true)",
"stderr is terminal": "true",
"stdin is terminal": "true",
"stdout console mode": "0x00000007 (VT processing: true)",
"stdout is terminal": "true",
"terminal": "Windows Terminal",
"terminal size": "291x77"
},
"remediation": null,
"durationMs": 0
},
"terminal.title": {
"id": "terminal.title",
"category": "title",
"status": "ok",
"summary": "terminal title default",
"details": {
"terminal title activity": "true",
"terminal title items": "activity, project-name",
"terminal title project source": "cwd",
"terminal title project value": "alexa",
"terminal title source": "default"
},
"remediation": null,
"durationMs": 0
},
"updates.status": {
"id": "updates.status",
"category": "updates",
"status": "ok",
"summary": "update configuration is locally consistent",
"details": {
"cached latest version": "0.147.0",
"check for update on startup": "true",
"last checked at": "2026-08-16T15:24:31.285704800Z",
"latest version": "0.147.0",
"latest version status": "current version is not older",
"update action": "manual or unknown",
"version cache": "C:\\Users\\alexa\\.codex\\version.json"
},
"remediation": null,
"durationMs": 312
}
}
}
</details>
What issue are you seeing?
Hello. I was looking into why Codex winget updates regularly fail validation (https://github.com/microsoft/winget-pkgs/pull/413497#issuecomment-5314336140), causing very long delays in the updates and found a couple of issues.
I could prepare a PR, but the repository's contribution policy does not allow it. So here we go:
Three related problems:
- The ZIP omits
codex-code-mode-host.exe, which can make Code Mode unavailable when the in-process fallback is disabled. - The main executable is
codex-<target>.exe. If (happens in my case) WinGet cannot create its alias link and falls back to adding the package directory toPATH. This leads to a very confusing experience where the documentedcodexcommand does not exist in the system and the user has to figure out that they need to usecodex-x86_64-pc-windows-msvcinstead. - The generated WinGet manifest declares internal helper executables under
NestedInstallerFiles, causing WinGet validation to execute them as standalone applications and reportValidation-Executable-Error, causing those update delays.
I reproduced all three problems with Codex CLI 0.147.0.
The fix requires changes to both the release process and WinGet manifest generation.
Related issue: #11283 covers the target-qualified executable name, but not the missing code-mode host or helper entries in the generated manifest.
<details>
<summary>🤖 GPT-5.6-Sol (low): Summary of the issue</summary>
Environment
- Codex CLI:
0.147.0 - Package:
OpenAI.Codex - OS: Windows x64
- WinGet PR: https://github.com/microsoft/winget-pkgs/pull/413497
- Release: https://github.com/openai/codex/releases/tag/rust-v0.147.0
Actual package contents
The official x64 WinGet ZIP:
codex-x86_64-pc-windows-msvc.exe.zip
contains:
codex-x86_64-pc-windows-msvc.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe
It does not contain:
codex-code-mode-host.exe
Problem 1: missing code-mode host
After installing the package, Codex reported:
Code Mode is unavailable because failed to spawn code-mode host
...\OpenAI.Codex__DefaultSource\codex-code-mode-host.exe:
host executable was not found.
Code mode will fail closed; enable `features.code_mode_host` and install
`codex-code-mode-host`.
I downloaded the official host from the same 0.147.0 release:
https://github.com/openai/codex/releases/download/rust-v0.147.0/codex-code-mode-host-x86_64-pc-windows-msvc.exe
Its SHA-256 matched the published release asset:
37C23A542037E1BCFD0FA7EB4A150C697229D7FF31BF675C519D5BFF7226B191
Its Authenticode signature was valid and signed by OpenAI OpCo, LLC.
After copying it beside the WinGet-installed Codex executable as:
codex-code-mode-host.exe
this succeeded:
codex-x86_64-pc-windows-msvc sandbox -- cmd.exe /c echo OK
Output:
OK
This confirms that the WinGet ZIP is missing the external host required by that session.
Problem 2: codex is not reliably available
The manifest requests:
PortableCommandAlias: codex
but the installed executable is named:
codex-x86_64-pc-windows-msvc.exe
On my system, WinGet did not create:
%LOCALAPPDATA%\Microsoft\WinGet\Links\codex.exe
It instead added the package directory to the user PATH.
Consequently:
Get-Command codex
failed, while:
Get-Command codex-x86_64-pc-windows-msvc
codex-x86_64-pc-windows-msvc --version
succeeded.
This is related to the WinGet portable-alias fallback behavior tracked in:
- https://github.com/microsoft/winget-cli/issues/3437
- https://github.com/microsoft/winget-cli/pull/6308
OpenAI can avoid depending on a future WinGet fix by naming the primary executable codex.exe inside the WinGet ZIP.
Problem 3: helpers are declared as portable entry points
Previous generated manifests, including 0.146.1, declare all three executables:
NestedInstallerFiles:
- RelativeFilePath: codex-command-runner.exe
- RelativeFilePath: codex-windows-sandbox-setup.exe
- RelativeFilePath: codex-x86_64-pc-windows-msvc.exe
PortableCommandAlias: codex
This causes WinGet executable validation to try to run all three files independently.
The first two files are internal helpers requiring arguments and runtime context. They are not user-facing application entry points. Their independent execution returns errors and causes Validation-Executable-Error.
I tested a reduced manifest containing only:
NestedInstallerFiles:
- RelativeFilePath: codex-x86_64-pc-windows-msvc.exe
PortableCommandAlias: codex
WinGet still extracted the complete ZIP, including both helpers.
Therefore the helpers must remain in the archive but should not be listed under NestedInstallerFiles.
Expected package
The architecture-specific WinGet ZIP should contain:
codex.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe
codex-code-mode-host.exe
Only the public entry point should appear in the manifest:
NestedInstallerFiles:
- RelativeFilePath: codex.exe
PortableCommandAlias: codex
This would provide the following behavior:
- WinGet extracts every required runtime file.
- Validation executes only the public Codex entry point.
- Code Mode can start the external host.
codexworks when WinGet creates its alias link.codexalso works through WinGet's PATH fallback because the real file is namedcodex.exe.
Proposed release-workflow change
The WinGet ZIP creation should copy the release executables approximately as follows:
main_src="$dest/codex-${target}.exe"
runner_src="$dest/codex-command-runner-${target}.exe"
setup_src="$dest/codex-windows-sandbox-setup-${target}.exe"
host_src="$dest/codex-code-mode-host-${target}.exe"
cp "$main_src" "$bundle_dir/codex.exe"
cp "$runner_src" "$bundle_dir/codex-command-runner.exe"
cp "$setup_src" "$bundle_dir/codex-windows-sandbox-setup.exe"
cp "$host_src" "$bundle_dir/codex-code-mode-host.exe"
Archive generation should fail if any required executable is absent rather than publishing a reduced ZIP.
The WinGet submission step must also generate NestedInstallerFiles containing only codex.exe. If the current winget-releaser/Komac integration cannot select the primary nested executable, it may require a generator option, a post-generation edit, or a custom submission step.
</details>
What steps can reproduce the bug?
<details>
<summary>🤖 GPT-5.6-Sol (low): Steps to reproduce</summary>
- Install Codex CLI
0.147.0through WinGet:
``powershell``
winget install --id OpenAI.Codex --exact
- Start a new PowerShell session and check the installed package:
``powershell``
winget list --id OpenAI.Codex --exact
- Check whether the expected command exists:
``powershell``
Get-Command codex -All
On a system where WinGet cannot create its portable command link, codex is not found because the package contains only the target-qualified executable.
- Locate the package directory:
``powershell
$packageRoot = Get-ChildItem
-LiteralPath "$env:LOCALAPPDATA\Microsoft\WinGet\Packages"
-Directory
-Filter 'OpenAI.Codex_*' |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1
Get-ChildItem -LiteralPath $packageRoot.FullName -File |
Select-Object Name, Length
```
- Observe that the package contains:
``text``
codex-x86_64-pc-windows-msvc.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe
but does not contain:
``text``
codex.exe
codex-code-mode-host.exe
- Run Codex using its actual installed filename:
``powershell``
codex-x86_64-pc-windows-msvc
- Start a session that uses Code Mode and request a tool-backed operation, such as:
``textcmd.exe /c echo OK
Run .``
- When the in-process fallback is unavailable, observe the startup or tool error:
```text
Code Mode is unavailable because failed to spawn code-mode host
...\OpenAI.Codex__DefaultSource\codex-code-mode-host.exe:
host executable was not found.
Code mode will fail closed.
```
- Confirm the missing-host diagnosis by downloading the official host from the same release:
```powershell
$hostDownload = Join-Path $env:TEMP 'codex-code-mode-host-0.147.0-x64.exe'
Invoke-WebRequest
-Uri 'https://github.com/openai/codex/releases/download/rust-v0.147.0/codex-code-mode-host-x86_64-pc-windows-msvc.exe'
-OutFile $hostDownload
Get-FileHash -LiteralPath $hostDownload -Algorithm SHA256
Get-AuthenticodeSignature -LiteralPath $hostDownload
```
Expected SHA-256:
``text``
37C23A542037E1BCFD0FA7EB4A150C697229D7FF31BF675C519D5BFF7226B191
- Copy the verified host beside the WinGet-installed Codex executable:
```powershell
$hostTarget = Join-Path $packageRoot.FullName 'codex-code-mode-host.exe'
Copy-Item
-LiteralPath $hostDownload
-Destination $hostTarget
```
- Verify that external-host execution now works:
``powershell
& (Join-Path $packageRoot.FullName 'codex-x86_64-pc-windows-msvc.exe')
sandbox -- cmd.exe /c echo OK
```
Expected output:
``text``
OK
The final copy is a diagnostic workaround only, not a proposed installation method.
</details>
What is the expected behavior?
- WinGet updates do not cause validation errors and are approved quickly, delivering fixes and new features to users.
- Users can launch codex using
codexrather thancodex-x86_64-pc-windows-msvc. When I first tried using codex, this caused a lot of frustration.
Additional information
<details>
<summary>🤖 GPT-5.6-Sol (low): Release automation and source references</summary>
WinGet submission ownership
Codex submits OpenAI.Codex to WinGet from its own release workflow using winget-releaser.
Relevant workflow:
The WinGet job selects:
^codex-(?:x86_64|aarch64)-pc-windows-msvc\.exe\.zip$
and submits the resulting package through openai-oss-forks.
Windows ZIP construction
The Windows release workflow builds:
codex
codex-code-mode-host
codex-responses-api-proxy
codex-windows-sandbox-setup
codex-command-runner
codex-app-server
Relevant workflow:
However, the main target-specific Codex ZIP currently copies only:
codex-<target>.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe
The workflow comment states that the helpers are included so WinGet installations have the required executables beside Codex, but codex-code-mode-host.exe is not copied.
Canonical Codex package documentation
The repository's package-builder documentation describes a canonical package containing:
bin/
├── <entrypoint>[.exe]
└── codex-code-mode-host[.exe]
codex-resources/
├── codex-command-runner.exe
└── codex-windows-sandbox-setup.exe
Source:
It specifically states that release jobs should provide the signed code-mode host so that it is included beside the signed entry point.
The dedicated WinGet ZIP currently differs from this documented package structure by omitting the host.
Host resolution
Codex resolves the process host relative to the current executable, using the filename:
codex-code-mode-host.exe
Source:
Therefore a host installed elsewhere, such as under a plugin directory, does not satisfy resolution for the WinGet-installed Codex executable.
</details>
<details>
<summary>🤖 GPT-5.6-Sol (low): Why the missing host was not visible in Codex 0.146.1</summary>
The 0.146.1 WinGet ZIP also omitted codex-code-mode-host.exe.
Starting with the 0.144.1 line, Codex could fall back to its embedded, in-process V8 implementation when the external host executable was not found:
The effective behavior was:
Host absent → use embedded fallback → Code Mode continues
Later changes added support for disabling the in-process fallback and returning an error when neither implementation is available:
The tested 0.147.0 session explicitly reported that Code Mode would fail closed. The user's explicit config.toml did not disable code_mode_host; the exact effective configuration source that prohibited fallback was not identified.
The result was:
0.146.1:
host absent → embedded fallback → incomplete package remains unnoticed
0.147.0 tested session:
host absent → fallback unavailable → Code Mode fails
The reduced test manifest did not cause this behavior. Installing it coincided with changing from 0.146.1 to 0.147.0.
</details>
<details>
<summary>🤖 GPT-5.6-Sol (low): WinGet validation history and local manifest test</summary>
The published 0.146.1 manifest contains:
NestedInstallerFiles:
- RelativeFilePath: codex-command-runner.exe
- RelativeFilePath: codex-windows-sandbox-setup.exe
- RelativeFilePath: codex-x86_64-pc-windows-msvc.exe
PortableCommandAlias: codex
Its validation attempted to execute the main executable and both helpers. The validation reported errors, but the PR was later approved and merged manually.
This means that the previous version being present in WinGet does not establish that the manifest structure is correct.
For 0.147.0, I created a local manifest listing only the primary executable. Validation succeeded:
winget validate --manifest 'D:\tmp\codex-0.147.0-manifest'
WinGet installed the package successfully and extracted every archive member despite the manifest identifying only the primary executable.
Installed package:
Name: Codex CLI
Id: OpenAI.Codex
Version: 0.147.0
Source: winget
Extracted files before the manual host repair:
codex-command-runner.exe
codex-windows-sandbox-setup.exe
codex-x86_64-pc-windows-msvc.exe
This demonstrates the distinction between:
- archive contents, which WinGet extracts completely; and
NestedInstallerFiles, which identifies portable application entry points.
</details>
<details>
<summary>🤖 GPT-5.6-Sol (low): Related issues and previous PRs</summary>
OpenAI Codex
- #11283 — WinGet install exposes target-suffixed executable name instead of
codex.exe
https://github.com/openai/codex/issues/11283
- #11286 — attempted to include
codex.exein the Windows ZIP; closed unmerged
https://github.com/openai/codex/pull/11286
- #31913 — added missing-host fallback and related packaging repairs
https://github.com/openai/codex/pull/31913
- #35266 — added the ability to disable the in-process fallback
https://github.com/openai/codex/pull/35266
- #35721 — returns a clear error when both process hosting and fallback are unavailable
https://github.com/openai/codex/pull/35721
WinGet
- Portable alias fallback issue
https://github.com/microsoft/winget-cli/issues/3437
- Proposed hardlink-based alias implementation
https://github.com/microsoft/winget-cli/pull/6308
- Codex
0.147.0automated manifest PR
https://github.com/microsoft/winget-pkgs/pull/413497
</details>
2 Comments
All three problems trace to one packaging step in the release workflow, and the fixes are small. On
main@ 1f41cc5d92, the WinGet zip is assembled in the "Compress artifacts" step ofrust-release-windows.yml:https://github.com/openai/codex/blob/1f41cc5d92722748e45cae9cecc6d883a4e7cbb1/.github/workflows/rust-release-windows.yml#L340-L409
The relevant branch (only for
codex-<target>.exe) builds a bundle dir with exactly three files:which maps 1:1 onto your findings:
codex-code-mode-host.exe— it is built and staged for Windows (WINDOWS_BINARIESat the top of the same workflow includes it, and it lands in the samedist/<target>dir), but the bundle step simply never copies it. The comment above the block ("Bundle the sandbox helper binaries … so WinGet installs include the required helpers next to codex.exe") shows the intent; code-mode-host just wasn't on the list. Onecpline fixes it.codexcommand — the helpers get renamed to bare names but the main binary is copied as$base, i.e.codex-x86_64-pc-windows-msvc.exe, verbatim. When WinGet's alias creation fails and it falls back to PATH, there is nocodex.exeto find. The fix is the same one-liner in the other direction:cp "$dest/$base" "$bundle_dir/codex.exe"(with the manifest'sRelativeFilePath/PortableCommandAliasupdated to match). This is also the cleaner resolution to #11283.Validation-Executable-Error— the WinGet publish job (rust-release.ymlL1600-L1629) delegates manifest generation tovedantmgoyal9/winget-releaserover the zip matched byinstallers-regex. With three top-level exes in the archive, the generatedNestedInstallerFilesenumerates all of them, so validation executescodex-command-runner.exe/codex-windows-sandbox-setup.exeas if they were standalone portables. Fixing this means constraining the manifest to declare onlycodex.exeas the portable command — either via the action's configuration if it supports selecting nested files, or by generating/patching the installer manifest in the workflow before the PR is opened. (Renaming per (2) doesn't remove the helpers fromNestedInstallerFilesby itself.)Since the helpers must ship next to codex.exe for the sandbox to work, the end-state that satisfies both WinGet validation and runtime is: zip =
codex.exe+codex-code-mode-host.exe+ the two sandbox helpers, manifest = singleNestedInstallerFileentry pointing atcodex.exewith aliascodex. All of it lives in the two workflow files above — no product code changes required.Winget releases are currently blocked, possibly because of this.
https://github.com/microsoft/winget-pkgs/pull/413497#issuecomment-5376053475