WinGet package omits code-mode host, exposes no reliable `codex` command, and declares helpers as entry points

[AlexanderBartash]

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

codex-x86_64-pc-windows-msvc doctor --json

{
  "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
    }
  }
}

What issue are you seeing?

Hello. I was looking into why Codex winget updates regularly fail validation (microsoft/winget-pkgs#413497 (comment)), 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:

1. The ZIP omits codex-code-mode-host.exe, which can make Code Mode unavailable when the in-process fallback is disabled.
2. 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 to PATH. This leads to a very confusing experience where the documented codex command does not exist in the system and the user has to figure out that they need to use codex-x86_64-pc-windows-msvc instead.
3. The generated WinGet manifest declares internal helper executables under NestedInstallerFiles, causing WinGet validation to execute them as standalone applications and report Validation-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.

🤖 GPT-5.6-Sol (low): Summary of the issue

Environment

• Codex CLI: 0.147.0
• Package: OpenAI.Codex
• OS: Windows x64
• WinGet PR: New version: OpenAI.Codex version 0.147.0 microsoft/winget-pkgs#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:

• Portable installers are not renamed in non-symlinked installations microsoft/winget-cli#3437
• Use hardlinks for portable aliases without renaming originals microsoft/winget-cli#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.
• codex works when WinGet creates its alias link.
• codex also works through WinGet's PATH fallback because the real file is named codex.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.

What steps can reproduce the bug?

🤖 GPT-5.6-Sol (low): Steps to reproduce

1. Install Codex CLI 0.147.0 through WinGet:

   winget install --id OpenAI.Codex --exact

2. Start a new PowerShell session and check the installed package:

   winget list --id OpenAI.Codex --exact

3. Check whether the expected command exists:

   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.

4. Locate the package directory:

   $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

5. Observe that the package contains:

   codex-x86_64-pc-windows-msvc.exe
   codex-command-runner.exe
   codex-windows-sandbox-setup.exe
   

   but does not contain:

   codex.exe
   codex-code-mode-host.exe
   

6. Run Codex using its actual installed filename:

   codex-x86_64-pc-windows-msvc

7. Start a session that uses Code Mode and request a tool-backed operation, such as:

   Run `cmd.exe /c echo OK`.
   

8. When the in-process fallback is unavailable, observe the startup or tool error:

   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.
   

9. Confirm the missing-host diagnosis by downloading the official host from the same release:

   $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:

   37C23A542037E1BCFD0FA7EB4A150C697229D7FF31BF675C519D5BFF7226B191
   

10. Copy the verified host beside the WinGet-installed Codex executable:

    $hostTarget = Join-Path $packageRoot.FullName 'codex-code-mode-host.exe'
    
    Copy-Item `
      -LiteralPath $hostDownload `
      -Destination $hostTarget

11. Verify that external-host execution now works:

    & (Join-Path $packageRoot.FullName 'codex-x86_64-pc-windows-msvc.exe') `
      sandbox -- cmd.exe /c echo OK

    Expected output:

    OK
    

The final copy is a diagnostic workaround only, not a proposed installation method.

What is the expected behavior?

1. WinGet updates do not cause validation errors and are approved quickly, delivering fixes and new features to users.
2. Users can launch codex using codex rather than codex-x86_64-pc-windows-msvc. When I first tried using codex, this caused a lot of frustration.

Additional information

🤖 GPT-5.6-Sol (low): Release automation and source references

WinGet submission ownership

Codex submits OpenAI.Codex to WinGet from its own release workflow using winget-releaser.

Relevant workflow:

• https://github.com/openai/codex/blob/main/.github/workflows/rust-release.yml

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:

• https://github.com/openai/codex/blob/main/.github/workflows/rust-release-windows.yml

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:

• https://github.com/openai/codex/blob/main/scripts/codex_package/README.md

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:

• https://github.com/openai/codex/blob/main/codex-rs/code-mode/src/remote_session.rs

Therefore a host installed elsewhere, such as under a plugin directory, does not satisfy resolution for the WinGet-installed Codex executable.

🤖 GPT-5.6-Sol (low): Why the missing host was not visible in Codex 0.146.1

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:

• [0.144] Backport installer and code-mode reliability fixes #31913

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:

• Allow disabling the in-process code-mode host fallback #35266
• Honor disabled code mode fallback without a process host #35721

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.

🤖 GPT-5.6-Sol (low): WinGet validation history and local manifest test

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.

🤖 GPT-5.6-Sol (low): Related issues and previous PRs

OpenAI Codex

• WinGet install exposes target-suffixed executable name instead of codex.exe #11283 — WinGet install exposes target-suffixed executable name instead of codex.exe
  WinGet install exposes target-suffixed executable name instead of codex.exe #11283

• fix(release): include codex.exe in windows bundle zip #11286 — attempted to include codex.exe in the Windows ZIP; closed unmerged
  fix(release): include codex.exe in windows bundle zip #11286

• [0.144] Backport installer and code-mode reliability fixes #31913 — added missing-host fallback and related packaging repairs
  [0.144] Backport installer and code-mode reliability fixes #31913

• Allow disabling the in-process code-mode host fallback #35266 — added the ability to disable the in-process fallback
  Allow disabling the in-process code-mode host fallback #35266

• Honor disabled code mode fallback without a process host #35721 — returns a clear error when both process hosting and fallback are unavailable
  Honor disabled code mode fallback without a process host #35721

WinGet

• Portable alias fallback issue
  Portable installers are not renamed in non-symlinked installations microsoft/winget-cli#3437

• Proposed hardlink-based alias implementation
  Use hardlinks for portable aliases without renaming originals microsoft/winget-cli#6308

• Codex 0.147.0 automated manifest PR
  New version: OpenAI.Codex version 0.147.0 microsoft/winget-pkgs#413497

[jdcodes1]

All three problems trace to one packaging step in the release workflow, and the fixes are small. On main @ 1f41cc5, the WinGet zip is assembled in the "Compress artifacts" step of rust-release-windows.yml:

codex/.github/workflows/rust-release-windows.yml

Lines 340 to 409 in 1f41cc5

	- name: Compress artifacts
	shell: bash
	run: |
	# Path that contains the uncompressed binaries for the current
	# ${{ matrix.target }}
	dest="dist/${{ matrix.target }}"
	repo_root=$PWD
	target="${{ matrix.target }}"
	export dest repo_root target
	# For compatibility with environments that lack the `zstd` tool we
	# additionally create a `.tar.gz` and `.zip` for every Windows binary.
	# The end result is:
	# codex-<target>.zst
	# codex-<target>.tar.gz
	# codex-<target>.zip
	# Variables in the single-quoted script expand in the child shell.
	# shellcheck disable=SC2016
	printf '%s\0' "$dest"/* |
	xargs -0 -n1 -P2 bash -c '
	set -euo pipefail
	f=$1
	base="$(basename "$f")"
	# Skip files that are already archives (should not happen, but be
	# safe).
	if [[ "$base" == *.tar.gz || "$base" == *.tar.zst || "$base" == *.zip || "$base" == *.dmg ]]; then
	exit 0
	fi
	# Do not try to compress signature bundles.
	if [[ "$base" == *.sigstore ]]; then
	exit 0
	fi
	# Create per-binary tar.gz
	tar -C "$dest" -czf "$dest/${base}.tar.gz" "$base"
	# Create zip archive for Windows binaries.
	# Must run from inside the dest dir so 7z does not embed the
	# directory path inside the zip.
	if [[ "$base" == "codex-${target}.exe" ]]; then
	# Bundle the sandbox helper binaries into the main codex zip so
	# WinGet installs include the required helpers next to codex.exe.
	# Fall back to the single-binary zip if the helpers are missing
	# to avoid breaking releases.
	bundle_dir="$(mktemp -d)"
	runner_src="$dest/codex-command-runner-${target}.exe"
	setup_src="$dest/codex-windows-sandbox-setup-${target}.exe"
	if [[ -f "$runner_src" && -f "$setup_src" ]]; then
	cp "$dest/$base" "$bundle_dir/$base"
	cp "$runner_src" "$bundle_dir/codex-command-runner.exe"
	cp "$setup_src" "$bundle_dir/codex-windows-sandbox-setup.exe"
	# Use an absolute path so bundle zips land in the real dist
	# dir even when 7z runs from a temp directory.
	(cd "$bundle_dir" && 7z a "$repo_root/$dest/${base}.zip" .)
	else
	echo "warning: missing sandbox binaries; falling back to single-binary zip"
	echo "warning: expected $runner_src and $setup_src"
	(cd "$dest" && 7z a "${base}.zip" "$base")
	fi
	rm -rf "$bundle_dir"
	else
	(cd "$dest" && 7z a "${base}.zip" "$base")
	fi
	# Keep raw executables and produce .zst alongside them.
	"${GITHUB_WORKSPACE}/.github/workflows/zstd" -T0 -19 "$dest/$base"
	' _
	- uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0

The relevant branch (only for codex-<target>.exe) builds a bundle dir with exactly three files:

cp "$dest/$base" "$bundle_dir/$base"                                  # keeps target-qualified name!
cp "$runner_src" "$bundle_dir/codex-command-runner.exe"               # renamed to bare name
cp "$setup_src"  "$bundle_dir/codex-windows-sandbox-setup.exe"        # renamed to bare name

which maps 1:1 onto your findings:

1. Missing codex-code-mode-host.exe — it is built and staged for Windows (WINDOWS_BINARIES at the top of the same workflow includes it, and it lands in the same dist/<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. One cp line fixes it.

2. No bare codex command — 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 no codex.exe to find. The fix is the same one-liner in the other direction: cp "$dest/$base" "$bundle_dir/codex.exe" (with the manifest's RelativeFilePath/PortableCommandAlias updated to match). This is also the cleaner resolution to WinGet install exposes target-suffixed executable name instead of codex.exe #11283.

3. Helpers declared as entry points / Validation-Executable-Error — the WinGet publish job (rust-release.yml L1600-L1629) delegates manifest generation to vedantmgoyal9/winget-releaser over the zip matched by installers-regex. With three top-level exes in the archive, the generated NestedInstallerFiles enumerates all of them, so validation executes codex-command-runner.exe/codex-windows-sandbox-setup.exe as if they were standalone portables. Fixing this means constraining the manifest to declare only codex.exe as 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 from NestedInstallerFiles by 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 = single NestedInstallerFile entry pointing at codex.exe with alias codex. All of it lives in the two workflow files above — no product code changes required.