CodexHowSupport Us

Installing and Updating the Codex CLI

Installing the Codex CLI is a one-line command on macOS and Linux, and the same command is also how you update it later — worth knowing up front, because it means there's no separate "update" step to remember, just re-running the install.

The install itself

The published install command pipes a script from chatgpt.com/codex/install.sh through your shell. If your environment is cautious about piping remote scripts directly into a shell — a reasonable default posture on a shared or production-adjacent machine — downloading the script first and reading it before running it is a fine substitute; the command itself doesn't do anything the script's own contents wouldn't tell you.

Windows, npm and Homebrew

The curl-to-shell command is the macOS/Linux path specifically. A dedicated Windows installer is offered as an alternative on Windows, and npm and Homebrew installs are both offered as tabs alongside the primary install method for anyone who'd rather manage the CLI through a package manager they already use for other tools. Whichever path you pick, stick with it for future updates — mixing install methods (installing fresh via npm after an earlier curl install, say) is a common source of "which version is actually running" confusion, since you can end up with two separate binaries on your PATH and no clear signal which one a bare codex command resolves to.

Confirming what you actually have installed

After installing or updating, codex --version is the source of truth for what's actually running — more reliable than assuming an update succeeded just because the command completed without an error. If you've mixed install methods in the past, checking which codex (or the Windows equivalent) alongside the version can surface a stale binary earlier in your PATH shadowing the one you meant to update.

Updating is the same command, run again

Because install and update are the same command, there's no separate changelog check built into the process — running the install script again simply fetches and installs whatever the current version is. If you want to know what changed before updating, checking the CLI's own release notes or changelog first (rather than the install script, which won't tell you) is worth the extra step for anything beyond a routine "get the latest" update.

Why staying current actually matters here

This site's own standing practice is to treat anything about the CLI as a fact that needs periodic re-verification, not a one-time read — flag names, default behaviors and subcommands have changed release to release faster than most static documentation tracks reliably. Running an old CLI version against documentation (this site's own guides included) written against a newer one is a real, if usually minor, source of mismatches; keeping current isn't just about new features, it's about staying aligned with whatever guide you're actually following.

Verifying the CLI is actually working post-install

A quick sanity check — running codex with no arguments and confirming it starts a session and reports a model in its banner — is worth doing immediately after any install or update, before relying on it for real work. Catching an install that silently failed, or that installed but can't reach the network correctly, in a two-second check is much better than discovering it partway through a task you actually needed done.

If the install script's own domain is unfamiliar

The install command's domain — chatgpt.com — is the correct, official one; a script from anywhere else claiming to install "the Codex CLI" is not something this site can vouch for, and installing developer tooling from an unfamiliar source is exactly the kind of thing worth double-checking against the CLI's own official documentation before running, regardless of how it was shared with you.

Multiple machines, multiple versions

If you work across several machines — a laptop, a CI runner, a remote development environment — it's worth checking codex --version on each rather than assuming they're all current just because one of them recently got updated. A team hitting inconsistent behavior across environments is worth checking for a version mismatch before assuming it's a configuration difference; an outdated CLI on one machine behaving differently from a current one on another is a genuinely common, easy-to-miss cause.

Automating the update as part of a broader setup

A team standardizing developer environments — a setup script, a dev-container image, an onboarding checklist for new hires — is a reasonable place to pin the install command as a step, but it's worth deciding deliberately whether that step always fetches "the latest" or targets a specific known-good version. Always-latest keeps everyone current automatically but means a breaking change in a new release reaches your whole team the moment anyone re-runs setup; a pinned version is more predictable but needs someone to deliberately bump it, or it quietly becomes the outdated version this page already warned about.

Uninstalling or rolling back

If a fresh install or update introduces a regression specific to your workflow, knowing how to remove it — or reinstall a prior version through whichever package manager path you used — is worth understanding before you need it under pressure. Homebrew and npm both support installing a specific prior version directly; the curl-based install script generally fetches whatever is current, which makes a version pin harder through that path specifically, and is itself a reason some teams prefer a package-manager install for anything beyond individual, ad hoc use.

Why this is a small thing worth getting right

None of this is complicated once you've done it — install once, update the same way, check the version, done. The value in treating it deliberately rather than casually is entirely about avoiding the quiet failure modes: a stale binary shadowing a newer one on your PATH, a team running mismatched versions without realizing it, a script referencing behavior from a version nobody's running anymore. Getting the install and update habit right once removes a whole category of "why is this behaving differently on my machine" conversations later.

Verified 2026-08-09 against CodexHow facts module (src/data/facts/) — see /about/#accuracy.