Regression: VS Code extension codex.exe requires AVX-512 and crashes on Zen 3 (Ryzen 5000)

Open 💬 2 comments Opened Apr 11, 2026 by eemarwell

What version of the IDE extension are you using?

1.115.0

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Windwos 11

What issue are you seeing?

Codex crashes at startup because the binary requests CPU capabilities not present on Zen 3 CPUs.
Fatal Error: HW capability found: 0x..., but HW capability requested: 0x200000 0x00.
From behavior and CPU feature mapping, this appears to be an AVX-512 requirement in the shipped [codex.exe].

What steps can reproduce the bug?

Install/update to the affected canary/alpha version of openai.chatgpt.
Open VS Code and start Codex.
Observe immediate startup failure with HW capability requested error.

What is the expected behavior?

Codex should run on CPUs without AVX-512 (or gracefully provide a compatible binary / fallback).

Additional information

Please publish a Windows build compatible with non-AVX-512 CPUs (or document minimum CPU instruction requirements clearly if intentionally changed).

View original on GitHub ↗

2 Comments

rayanovelha · 4 months ago

I’m experiencing the same issue with any Codex version above 0.104.0, likely caused by AVX512 incompatibility.
Fatal Error: HW capability found: 0x178BFBFF 0xFED8320B, but HW capability requested: 0x200000 0x00.

I’m concerned because version 0.104 will eventually lose support, and I won’t be able to use codex anymore.

JasonSongPeng · 3 months ago

Confirming and broadening this bug — it is not limited to the VS Code extension, and not limited to AMD Zen 3.

New data point: Codex CLI on Intel i9-13900H (13th-gen Raptor Lake)

The bundled Windows codex.exe aborts with an illegal-instruction fault on a
current-generation Intel CPU whose AVX-512 is fused off (all 13th-gen consumer
"Raptor Lake" parts — both P and E cores — have no AVX-512). So the affected
surface is much wider than Zen 3 + the extension: it includes the plain
@openai/codex npm CLI on mainstream Intel laptops.

Environment

| Item | Value |
|---|---|
| Codex CLI | @openai/codex 0.130.0 (also reproduced on 0.80.0 / 0.105.0 / 0.120.0) |
| OS | Windows 11 Pro 25H2, build 26200.8457 |
| CPU | Intel Core i9-13900H (Raptor Lake; AVX-512 disabled in silicon) |
| Binary | npm-global @openai/codex-win32-x64/.../x86_64-pc-windows-msvc/codex/codex.exe (Authenticode valid, signer "OpenAI OpCo, LLC") |

Symptom

$exe = (Get-ChildItem (npm root -g) -Recurse -Filter codex.exe |
        Where-Object { $_.FullName -match 'x86_64-pc-windows-msvc' } |
        Select-Object -First 1).FullName

& $exe --version          # -> codex-cli 0.130.0   (exit 0, OK)
& $exe login --device-auth # -> NO output; exit -1073741795 == 0xC000001D (STATUS_ILLEGAL_INSTRUCTION)

--version works (light path); any real runtime (login, etc.) aborts

instantly with 0xC000001D STATUS_ILLEGAL_INSTRUCTION, zero output
even with RUST_BACKTRACE=full / RUST_LOG=debug (dies before logging).

Reproduced invoking codex.exe directly (node launcher not involved).

Strong evidence it is the Windows build's instruction selection, not the machine

The Linux build of the same Codex 0.130.0 runs perfectly in WSL2 Ubuntu
24.04 on the same physical CPU. Only the x86_64-pc-windows-msvc build faults.

Downgrading does NOT help on this CPU. Unlike the Zen 3 reports where
Codex ≤ 0.104.0 still works, on this Raptor Lake CPU every version tested
crashes identically with 0xC000001D: 0.95.0, 0.100.0, 0.104.0, 0.105.0,
0.120.0, 0.130.0. So the AVX-512 requirement reaches further back than 0.104,
and/or pinning the JS package version does not pin the bundled
@openai/codex-win32-x64 native binary — worth flagging, since "stay on
0.104.0" is the workaround others are relying on.

Ruled out (so triage doesn't re-tread): not Python; not a corrupted install
(clean reinstall); not Smart App Control / Exploit Protection / Code
Integrity — there are zero events in CodeIntegrity/Operational,
Security-Mitigations/{Kernel,User}Mode, Defender, or WER. It is a raw #UD,
not a blocked/terminated process.

Ask (same as OP): please ship a Windows build that does not require AVX-512
(e.g. an x86-64-v2 baseline, or runtime CPU-feature detection with a safe
fallback). This currently makes native Windows Codex unusable on a very common
modern Intel CPU; WSL2 (Linux build) is the only working path.

Happy to provide a crash dump or the exact faulting instruction/address on request.