Provide a first-class standalone installer for native Codex binaries

Problem

Codex currently has three practical installation paths:

• npm
• Homebrew
• manually downloading a binary from GitHub Releases

These are useful options, but they do not cover an important class of users: people who want to install a native Codex CLI binary without first installing another large package manager, and without manually unpacking release artifacts.

Codex is a native Rust CLI. For users who already have npm or Homebrew and are comfortable with those ecosystems, those installation paths are convenient. But they should not be the only ergonomic paths.

There are environments where installing npm or Homebrew is simply not an acceptable prerequisite:

• minimal VMs
• ephemeral containers
• CI images
• locked-down developer machines
• security-sensitive hosts
• systems where the user intentionally avoids npm, Homebrew, or both

For those users, the answer is not “install npm first” or “install Homebrew first.” Whatever the friction level is, they are not going to install a whole additional package-management ecosystem just to obtain one native binary.

This is not a claim that npm or Homebrew are unusable for everyone. It is just a mismatch for this use case. npm is a package manager and script-execution ecosystem, not merely a binary downloader. Homebrew is also a large package-management system with its own operational behavior and policy implications. Some users deliberately avoid putting either of them on certain machines.

Right now, those users are left with either manual GitHub release installation or building from source.

Problems with manual GitHub release installation

Downloading from GitHub Releases works, but it is not a good default user experience, especially on Linux.

The user has to:

• find the right release
• choose the correct OS and architecture
• choose between musl and glibc/Linux libc builds
• understand whether the glibc build is compatible with their system
• download and unpack the archive
• move the binary somewhere on $PATH
• possibly fix permissions
• repeat the process manually for upgrades

This is all solvable, but it is friction that a simple installer could eliminate.

For a CLI tool, users generally expect something closer to:

curl -LsSf https://.../install.sh | sh

rather than manually selecting and unpacking release artifacts.

curl | sh is not ideal for every threat model, but it is a common installation pattern for native CLI tools. It would still be narrower than requiring users to install npm or Homebrew first, and it could be paired with clear script contents, checksums, signatures, or documented manual steps for users who prefer not to pipe directly into a shell.

Problems with building from source

Codex can also be built from a local checkout using Cargo, but this is not currently a practical first-class installation path for normal users.

In my case, building from source had several problems:

• the build took a long time, around 10–15 minutes, even to only partially succeed
• the release profile uses lto = "fat", which makes the build substantially heavier
• the build required system packages that were only discovered partway through compilation
• the build was OOM-killed on a machine with 16 GiB of RAM, likely during LTO-heavy release compilation
• the default CLI build appears to compile additional components, such as the app server, which increases build time and memory usage

That makes cargo install / source installation feel more like an internal developer path than a supported user installation path. That may be fine for CI or developer machines set up specifically for Codex, but it is not a good default installation path for ordinary VMs or containers.

This is especially unfortunate because Codex is written in Rust. For Rust users, Cargo would be a natural installation mechanism. But at the moment, source installation is too large, too slow, too dependent on system packages, and too easy to fail late in the build.

Proposed solution

Please add a first-class standalone installer for the prebuilt native binaries, similar to the uv installer.

For example:

curl -LsSf https://.../install.sh | sh

The installer should:

• detect OS and architecture
• select the correct release artifact
• handle Linux target differences such as musl vs glibc where possible
• install the binary into a user-local directory such as ~/.local/bin
• print clear instructions if the install directory is not on $PATH
• support upgrades cleanly
• avoid requiring npm, Homebrew, or a source build

This would make the GitHub release binaries actually ergonomic for users who want a native binary but do not want npm or Homebrew on the machine.

Longer-term improvements

It would also be useful to support native Linux package managers eventually:

• apt
• dnf
• yum
• possibly apk

Separately, it would be nice to have a Rust-native install path such as:

cargo install <codex-cli-crate>

I understand that the codex crate name appears to be occupied, so this may require a different crate name.

For Cargo installation to work well, it would help to:

• avoid compiling nonessential components in the default CLI install
• avoid lto = "fat" for install-from-source use cases
• check required system dependencies at the beginning of the build
• document required packages for common distributions
• provide a smaller default feature set for the CLI binary

Summary

npm and Homebrew are useful installation channels, but they are not sufficient as the only ergonomic options.

Manual GitHub release installation is too cumbersome, especially on Linux.

Building from source is currently too heavy and failure-prone to serve as a normal user install path.

A standalone installer for prebuilt native binaries would close this gap without removing or replacing the existing npm/Homebrew installation methods.

Disclosure: GPT-5.5 helped edit this issue. The installation problems described here are from my own experience.