Linux x86_64 glibc distro fails to execute bundled x86_64-unknown-linux-musl binary → ENOENT

I ran into the same issue for 0.54 on my ubuntu desktop (using the x86_64-unknown-linux-gnu build). I got codex running again by reverting back to 0.53

More context:
OS: Ubuntu 24.04.2 LTS
Node: v24.6.0
npm: v11.6.0

exactly same issue I experience as well:
error: spawn /home/.../tools/image/packages/@openai/codex/lib/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex/codex ENOENT at ChildProcess._handle.onexit (node:internal/child_process:285:19) at onErrorNT (node:internal/child_process:483:16) at process.processTicksAndRejections (node:internal/process/task_queues:90:21) { errno: -2, code: 'ENOENT', syscall: 'spawn /home/.../tools/image/packages/@openai/codex/lib/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex/codex', path: '/home/.../tools/image/packages/@openai/codex/lib/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex/codex', spawnargs: [] }

Ubuntu 22.04
Tried to install sudo apt install -y musl, than codex stopped loading at all. No errors. Downgraded to 0.53 and it work again

the same here

Same error in Debian GNU/Linux 13 (trixie) with npm 10.9.4 and nodejs 20.19.2

<img width="923" height="144" alt="Image" src="https://github.com/user-attachments/assets/6c1aee63-7db1-4950-80ef-175939147947" />

they forgot to add the glibc binary for Ubuntu/Debian, downgrade back to 0.52/0.53 for the time being and it will work.

Thanks for the detailed bug report.

The offending change was reverted:

https://github.com/openai/codex/pull/6222

and the new build with the fix is in flight:

https://github.com/openai/codex/actions/runs/19081250342

Bug Report: CLI fails on Linux due to incorrect path and missing dependency

Package: @openai/codex

Summary

The @openai/codex CLI tool is currently unusable on standard Linux distributions for two main reasons:

1. Incorrect Path Resolution: The CLI wrapper script incorrectly constructs the path to the native binary, adding an extra space, which leads to an ENOENT (file not found) error.
2. Undocumented musl Dependency: The binary is dynamically linked against the musl C library. This dependency is not documented. On systems that use glibc by default (like most Linux distributions), the binary fails to execute with a cannot execute: required file not found error, because the musl interpreter is missing.

Steps to Reproduce

1. On a standard Linux system (e.g., Ubuntu, Debian, Fedora) that does not have the musl C library pre-installed.
2. Install Node.js (e.g., v20.19.5 or later).
3. Install the package globally:

``bash
npm install -g @openai/codex
``

1. Attempt to run the CLI:

``bash
codex --version
``

Expected Behavior

The CLI should either:

• Run successfully and print the version number.
• Or, fail with a clear error message stating the missing musl dependency and providing instructions on how to install it.

Actual Behavior

The command fails with the following error due to the incorrect path:

Error: spawn /home/user/.nvm/versions/node/v20.19.5/lib/node_modules/ @openai/codex/vendor/x86_64-unknown-linux-musl/codex/codex ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:285:19)
    at onErrorNT (node:internal/child_process:483:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn /home/user/.nvm/versions/node/v20.19.5/lib/node_modules/ @openai/codex/vendor/x86_64-unknown-linux-musl/codex/codex',
  path: '/home/user/.nvm/versions/node/v20.19.5/lib/node_modules/ @openai/codex/vendor/x86_64-unknown-linux-musl/codex/codex',
  spawnargs: [ '--version' ]
}

If the path issue is manually corrected (e.g., by creating a symlink), a second error occurs because of the missing dependency:

$ codex-fixed --version
bash: /home/user/.nvm/versions/node/v20.19.5/bin/codex-fixed: cannot execute: required file not found

System Information

• Operating System: Linux (e.g., Ubuntu, Fedora)
• Node.js Version: v20.19.5 (via NVM)
• @openai/codex Version: Latest available on npm

Analysis

The executable is an ELF 64-bit LSB pie executable, dynamically linked with the musl interpreter, as shown by the file command:

$ file ~/.nvm/.../codex/codex
ELF 64-bit LSB pie executable, x86-64, dynamically linked, interpreter /lib/ld-musl-x86_64.so.1

This confirms that the missing /lib/ld-musl-x86_64.so.1 is the cause of the second error.

Recommended Solutions

1. Fix the Path: Correct the wrapper script to properly resolve the path to the binary without adding a space. The path should be .../node_modules/@openai/codex/....
2. Address the Dependency:

• Option A (Recommended): Statically link the codex binary during compilation. This would create a dependency-free executable that runs on any standard Linux distribution without requiring users to install additional libraries.
• Option B: Clearly document the musl dependency in the README.md file, including installation instructions for major Linux distributions (e.g., sudo apt-get install musl for Debian/Ubuntu, sudo dnf install musl-libc for Fedora/CentOS).

Thanks for the detailed bug report. The offending change was reverted: #6222 and the new build with the fix is in flight: https://github.com/openai/codex/actions/runs/19081250342

We're back in business!

That's crazy. I can now imagine how the Codex degradation happened.

but honestly, this happens to the best of us

This has been fixed in v0.55.0, and v0.54.0 has been marked as deprecated. Thanks for the speedy reports folks.

Still not working on 0.63.0 on OpenSUSE with neither npm -g nor with deno compile 🙄

 {
  errno: -2,
  code: "ENOENT",
  syscall: "spawnSync /tmp/deno-compile-codex/.deno_compile_node_modules/localhost/@openai/codex/0.63.0/vendor/x86_64-unknown-linux-musl/codex/codex",
  path: "/tmp/deno-compile-codex/.deno_compile_node_modules/localhost/@openai/codex/0.63.0/vendor/x86_64-unknown-linux-musl/codex/codex",
  spawnargs: []
}

So much for """10x developers""", how many SWE's are needed to statically link binaries against musl in Rust? Go kinda does it for free, but I guess that's too much to ask for a vibe-coded vibecoding tool 🙃 but hey ItS MeM0ry S4Fe 🤡