›_ Codex Issues
Codex Issues / #24752

v0.134.0 Windows x64 binary fails to launch with EFTYPE / "not a valid Win32 application"

Open 💬 0 comments Opened May 27, 2026 by TakutoAshida

Summary

After upgrading to @openai/codex@0.134.0 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/codex@0.134.0-win32-x64) 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/codex@0.134.0 (installed via npm install -g)
  • Last known good: @openai/codex@0.133.0

Reproduction

\\\
npm install -g @openai/codex@0.134.0
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

| Version | Published (UTC) | Size (bytes) | \file\ output | Runs? |
|---|---|---|---|---|
| 0.132.0 | 2026-05-20T02:38:33Z | 239,207,216 | PE32+ x86-64, 8 sections | ✅ |
| 0.133.0 | 2026-05-21T17:12:35Z | 239,604,528 | PE32+ x86-64, 7 sections | ✅ |
| 0.134.0 | 2026-05-26T19:33:23Z | 240,159,536 | PE32+ x86-64, 7 sections | ❌ \EFTYPE\ |

(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/codex@0.133.0
\\\

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/codex-win32-x64@0.134.0-win32-x64\ 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.)

View original on GitHub ↗