codex - 💡(How to fix) Fix v0.134.0 Windows x64 binary fails to launch with EFTYPE / "not a valid Win32 application"

Summary

After upgrading to @openai/[email protected] on Windows 11 x64, every codex invocation crashes at the Node.js wrapper with spawn EFTYPE. The native codex.exe shipped via the optional dependency alias @openai/codex-win32-x64 (resolved from @openai/[email protected]) cannot be executed by Windows at all. Pinning to 0.133.0 fully resolves the issue, so this looks like a bad Windows binary shipped with the 0.134.0 release.

Environment

• OS: Windows 11 Business, 10.0.26200 (build 26200)
• CPU: AMD64
• Node.js: v22.18.0
• npm: 10.9.3
• Affected version: @openai/[email protected] (installed via npm install -g)
• Last known good: @openai/[email protected]

Reproduction

``` npm install -g @openai/[email protected] codex --version ```

Actual behavior

``` node:internal/child_process:420 throw new ErrnoException(err, 'spawn'); ^

Error: spawn EFTYPE at ChildProcess.spawn (node:internal/child_process:420:11) at spawn (node:child_process:786:9) at file:///C:/Users/.../.npm-global/node_modules/@openai/codex/bin/codex.js:184:15 ... errno: -4028, code: 'EFTYPE', syscall: 'spawn' } ```

Running codex.exe directly (bypassing the Node wrapper) also fails:

• From PowerShell:

  プログラム 'codex.exe' の実行に失敗しました: 指定された実行可能ファイルはこの OS プラットフォームに対して有効なアプリケーションではありません。 (English: "The specified executable is not a valid application for this OS platform.") `CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException`

• From Git Bash: `cannot execute binary file: Exec format error` (exit 126)

On Windows/libuv, `UV_EFTYPE = -4028` is consistent with `CreateProcessW` returning `ERROR_BAD_EXE_FORMAT` ("not a valid Win32 application"). I have not captured the raw `GetLastError()` value.

Expected behavior

`codex --version` prints `codex-cli 0.134.0` (consistent with `0.132.0` / `0.133.0`).

Diagnostic data

The binary's structural metadata looks valid — `file` is happy with it:

``` $ file codex.exe codex.exe: PE32+ executable for MS Windows 6.00 (console), x86-64, 7 sections ```

Magic bytes: `MZ` present, `e_lfanew` at `0x118`, `PE\0\0` signature OK, machine type x86-64.

No `Zone.Identifier` ADS (not Mark-of-the-Web blocked). No Defender quarantine entry observed for this file.

Binary comparison across recent versions on the same machine

(All three were tested on the same Windows 11 x64 machine. The `file` command reports the same subsystem version "MS Windows 6.00 (console)" for all three.)

SHA-256 of the broken binary

``` a0118d50a9ef34a955a23c12c572820679c2b7d79a447a67a6cefcf4f587e906 codex.exe (0.134.0) ac1462d39b8f2ecdb24e37c752b45b1765ae9d3bbd0eb1d0e086ee28d7834b84 codex.exe (0.133.0, working) ```

(Path: `<npm-global>/node_modules/@openai/codex/node_modules/@openai/codex-win32-x64/vendor/x86_64-pc-windows-msvc/bin/codex.exe`)

Workaround

Pin to the last known good release:

``` npm install -g @openai/[email protected] ```

After downgrading, `codex --version` returns `codex-cli 0.133.0` and the CLI works normally.

Possible causes (speculation)

Since `file` reports the binary as a valid x86-64 PE32+ console executable yet Windows refuses to load it, the most likely culprits are:

• A linker / build-toolchain change in the 0.134.0 Windows pipeline producing a PE that the Windows loader rejects (e.g. invalid optional-header field, bad import table, bad relocation table, or section flags Windows can't honor).
• An issue with how the native binary is bundled into the `@openai/[email protected]` package (truncation / re-packing).
• Less likely: a Defender / SmartScreen-driven heuristic block on the new binary's hash, though no quarantine event was observed locally.

A diff of the build flags / toolchain between `0.133.0-win32-x64` and `0.134.0-win32-x64` would probably surface this quickly.

(Reported with help from Claude Code while diagnosing why my agent runtime broke this evening.)