Linux Homebrew install lags behind latest Codex CLI release

Open 💬 5 comments Opened May 19, 2026 by dcominottim
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.130.0 via Homebrew on Linux (/home/linuxbrew/.linuxbrew).

This report is specifically about the Linux Homebrew/Linuxbrew install path, not the macOS Cask user experience. The installed artifact on this machine is the Linux binary variant (codex-x86_64-unknown-linux-musl).

Latest upstream version observed at filing time:

  • GitHub release: rust-v0.131.0 / 0.131.0, published 2026-05-18T17:39:34Z
  • npm @openai/codex latest: 0.131.0, modified 2026-05-18T22:00:51.726Z
  • Linux Homebrew still installs/reports 0.130.0 on 2026-05-19

What subscription do you have?

N/A / not subscription-specific.

Which model were you using?

N/A / installation and update-path issue.

What platform is your computer?

Linux 7.0.4-200.fc44.x86_64 x86_64 unknown

What terminal emulator and version are you using (if applicable)?

Linux terminal session. TERM=xterm-256color, COLORTERM=truecolor; no tmux/zellij detected.

Codex doctor report

{
  "status": "not_available",
  "reason": "The installed Codex CLI version does not support `codex doctor --json`; it exits with `error: unexpected argument '--json' found`. Running `codex doctor` in this non-interactive session exits with `Error: stdin is not a terminal`."
}

What issue are you seeing?

Homebrew is a documented/user-facing installation path for Codex CLI, but the Linux Homebrew/Linuxbrew path can lag behind the latest Codex CLI release. Right now, 0.131.0 is available from the GitHub release and npm package, while Homebrew on Linux still serves 0.130.0.

This should not be treated as only a macOS Cask duplicate. The affected environment here is Linux, using the Linux Homebrew prefix /home/linuxbrew/.linuxbrew, and the installed Codex artifact is the Linux unknown-linux-musl binary.

There is some confusing Homebrew packaging metadata here: on Linux, brew info --formula codex reports that no formula is available and that codex was migrated from homebrew/core to homebrew/cask. brew info codex then shows metadata from Homebrew/homebrew-cask. However, the user-visible impact is still on Linux Homebrew installs: Linux users cannot upgrade Codex CLI to the current release through Homebrew.

This creates an awkward failure mode for users following the CLI issue template's instruction to make sure they are running the latest version: Linux users installed through Homebrew cannot update to the latest release even after brew update, and it is not obvious whether they should wait, switch install methods, or assume the release pipeline is stuck.

Local evidence from this Linux machine:

$ uname -mprs
Linux 7.0.4-200.fc44.x86_64 x86_64 unknown

$ command -v codex
/home/linuxbrew/.linuxbrew/bin/codex

$ codex --version
codex-cli 0.130.0

$ brew info --formula codex
Error: No available formula with the name "codex". Did you mean coder, codec2, ode or cortex?
It was migrated from homebrew/core to homebrew/cask.
You can access it again by running:
  brew tap homebrew/cask
And then you can install it by running:
  brew install --cask codex

$ brew info codex
==> codex (Codex): 0.130.0
OpenAI's coding agent that runs in your terminal
https://github.com/openai/codex
Installed (on request)
/home/linuxbrew/.linuxbrew/Caskroom/codex/0.130.0 (218.7MB)
  Installed using the formulae.brew.sh API on 2026-05-08 at 23:38:28
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/c/codex.rb
==> Artifacts
codex-x86_64-unknown-linux-musl -> codex (Binary)

Current Homebrew metadata at filing time still contains:

version "0.130.0"
url "https://github.com/openai/codex/releases/download/rust-v#{version}/codex-#{arch}-#{os}.tar.gz"
os macos: "apple-darwin", linux: "unknown-linux-musl"

What steps can reproduce the bug?

  1. On Linux, install Codex CLI through Homebrew/Linuxbrew. At filing time, the formula has been migrated away and Homebrew directs users to the cask-backed package:
brew install --cask codex
  1. Run brew update or let Homebrew auto-update.
  2. Run brew info --formula codex and observe that there is no Linux formula.
  3. Run brew info codex or brew info --cask codex.
  4. Run codex --version.
  5. Compare the Linux Homebrew version with the latest GitHub release and npm package version.

Observed on Linux on 2026-05-19:

$ gh release view --repo openai/codex --json tagName,name,publishedAt,url,isPrerelease
{"isPrerelease":false,"name":"0.131.0","publishedAt":"2026-05-18T17:39:34Z","tagName":"rust-v0.131.0","url":"https://github.com/openai/codex/releases/tag/rust-v0.131.0"}

$ npm view @openai/codex version dist-tags.latest time.modified
version = '0.131.0'
dist-tags.latest = '0.131.0'
time.modified = '2026-05-18T22:00:51.726Z'

$ brew info codex
==> codex (Codex): 0.130.0

What is the expected behavior?

Linux Homebrew users should be able to install or upgrade to the current released Codex CLI through Homebrew shortly after release, using the Linux artifact (unknown-linux-musl).

If Linux Homebrew is expected to lag because it depends on a separate Homebrew/homebrew-cask review or automation process, the install/update docs and issue template should say that clearly and recommend the preferred install path for Linux users who need the latest CLI immediately.

Additional information

I searched open issues for Homebrew/version lag before filing. The duplicate suggestion around macOS Cask does not appear to cover the same Linux behavior: this issue is about the Linux Homebrew path and Linux binary artifact.

This has reportedly happened before as a multi-day lag, so this may be a release-process reliability issue rather than a one-off delay for 0.131.0.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23366
  • #23392

Powered by Codex Action

dcominottim · 3 months ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #23366 - #23392 Powered by Codex Action

This issue is not a duplicate.

chenrui333 · 3 months ago
dcominottim · 3 months ago
technically duplicate of https://github.com/openai/codex/issues/23366

Not really, since that issue affects MacOS/cask, whereas this issue affects Linux for different reasons.

yanjinzheng2005-gif · 11 days ago

A release guard for this class of problem needs to test the consumer side after publishing, not only whether each upload job succeeded. The useful assertions from this report seem to be:

  1. Resolve npm, GitHub Release, and Homebrew versions at the same recorded time.
  2. Actually install the Linuxbrew artifact on a clean runner.
  3. Record the executable that wins on PATH, its observed version, and a side-effect-free launch probe.
  4. Uninstall it and report any stale executable or residue.

Disclosure: this issue was one of the concrete cases that led me to build an open-source CLI/GitHub Action for producing that JSON/Markdown receipt: https://github.com/yanjinzheng2005-gif/cli-channel-parity

I have not rerun this exact Codex/Linuxbrew incident, so the project is not evidence that the lag still exists today, and it does not fix the Homebrew publishing pipeline. If a Codex-specific channel config would be useful for future releases, I can add one that compares npm, GitHub Release, and Linuxbrew without turning an upload-success signal into a consumer PASS.