Codex: update failed, wrong version, or installed with the wrong method

What you see

You already have a working codex — the command resolves and runs. The problem is the update itself. The shapes reported for this situation include:

Error: `powershell -ExecutionPolicy Bypass -c '$env:CODEX_NON_INTERACTIVE=1; irm https://chatgpt.com/codex/install.ps1 | iex'` failed with status exit code: 1

and, from the standalone installer’s own download fallback on Windows:

WARNUNG: Could not download or verify https://releases.openai.com/codex/releases/.../codex-package_SHA256SUMS; retrying from GitHub Releases.

A second shape is not an error line at all: after a desktop auto-update the tool reports Logged in using ChatGPT while a token refresh returns {"error":{"code":"refresh_token_invalidated"}}. Note the first warning appears in the reporter’s German locale; the English prefix is not quoted by any source read here, so treat the line above as the installer’s fallback behaviour, not as a fixed English string.

What it usually means

This is an install-state problem, not a “command does not exist” problem. The spine is the single most useful fact on this page:

There is no single update command. What you must run is decided by how you installed it. Codex documents four mutually exclusive install locations — the standalone shell/PowerShell installer, npm install -g @openai/codex, brew install --cask codex, and a manual release archive — and they land in different places. The documented update for a standalone install is simply to re-run the installer, while codex update only applies “when the installed release supports self-update”. If you installed by one method and update by another, you can end up with two copies in two directories.

The consequences below are reported, not confirmed:

• codex update fails on Windows. One report shows it shells out to powershell.exe (Windows PowerShell 5.1) internally, regardless of the shell you ran codex from; if that PowerShell’s Microsoft.PowerShell.Utility module fails to load, Get-FileHash is unavailable and the update fails even from pwsh 7.
• A desktop auto-update leaves a stale backend. One report shows the app launching the binary named by a user-level CODEX_CLI_PATH override pointing at a per-user copy under .codex/.sandbox-bin, which the MSIX package update does not refresh — so the backend stays old while the package is new.

Quick checks

1. Which install method do you have? This decides everything else — see the orientation section below.
2. Did the version actually change? The sources read here do not document a command that prints the installed version. Read the version from the client’s own About dialog or its startup banner instead of inventing a flag.
3. Did you mix methods? If codex came from npm or Homebrew and you then ran codex update (or the standalone installer), you may have a second copy in a different directory. Prefer one method and remove the others (see the reversible step in “What not to do”).
4. Is it a Windows Get-FileHash failure? If codex update fails with a PowerShell error, see the Windows branch below.
5. Does it say you are logged in but nothing works? That is the refresh_token_invalidated shape — see the desktop branch and the login guide linked below.

Which install method do you have?

The install method decides the update method. Identify yours first:

• Standalone installer (macOS/Linux): you ran curl -fsSL https://chatgpt.com/codex/install.sh | sh, or on Windows powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex".
• npm global: you ran npm install -g @openai/codex.
• Homebrew cask: you ran brew install --cask codex (its binary lands at bin/codex -> $HOMEBREW_PREFIX/bin/codex).
• Manual archive: you extracted a codex-*.tar.gz from GitHub Releases and renamed the entry to codex.

Note a contradiction the sources do not reconcile: the README documents a native Windows PowerShell installer, while docs/install.md states the supported Windows configuration is Windows 11 via WSL2. Both were read this session; this guide presents both and refuses to choose.

Fixes, by branch

If you installed via the standalone installer

The documented update for a standalone install is to re-run the same install command:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

On Windows the documented installer is:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

Warning: this downloads and pipes a remotely-fetched script with -ExecutionPolicy ByPass. It is the documented installer, not a generic fix, and it writes an executable to your machine. On a host that already has a package-manager install it can create a second copy (mechanism observed, consequence suggested) — see the removable step in “What not to do”.

You can force the GitHub Releases download source instead of releases.openai.com by setting CODEX_INSTALLER_USE_RELEASES_OPENAI_COM=false. That selects only the download source, not the target directory.

If you installed via npm

The documented upgrade command for a global npm install was not found in any source read here, so this guide cannot tell you a npm-specific update command. The install command npm install -g @openai/codex is documented, but re-running it as an update is not something the sources establish. Check the npm registry / the Codex releases page for the current guidance, and avoid mixing it with codex update (which would add a second copy). If the npm install was refused with a permission error, see the npm section below.

If you installed via Homebrew

The documented upgrade command for the Homebrew cask was not found in any source read here, so this guide cannot tell you a Homebrew-specific update command. The install command brew install --cask codex is documented; treat brew upgrade --cask codex as the obvious operation but do not present it as documented here. Check the Homebrew cask page for the current version rather than trusting any number frozen into this guide, and avoid mixing it with codex update.

If you installed via the manual archive

Replace the extracted binary with the current archive from GitHub Releases and rename the entry to codex again. The documented archive names bake the platform in, so the rename step is expected. There is no documented in-place self-update for this method in the sources read here.

If codex update fails on Windows (Get-FileHash)

One open report describes codex update always invoking powershell.exe (5.1) internally, so a broken PSModulePath that prevents Get-FileHash from loading makes the update fail even from pwsh 7. The reporter proposed two possible fixes — prefer pwsh over powershell.exe when on PATH, or compute the checksum via .NET ([System.Security.Cryptography.SHA256]) instead of the Get-FileHash cmdlet. These are the reporter’s proposals, not instructions and not endorsed fixes; this guide does not tell you to apply them. They are included so you recognise the shape.

If a desktop auto-update left a stale backend

One open report describes a per-user CODEX_CLI_PATH pointing at .codex/.sandbox-bin/codex.exe, which the MSIX update does not refresh. If you hit this, the remediation the reporter describes is to point CODEX_CLI_PATH at the refreshed package binary — but that is the reporter’s own forensics, not a confirmed or documented fix, so treat it as a lead. The companion refresh_token_invalidated symptom (you appear logged in but token refresh returns 401) is covered by the login guide linked below; this guide does not re-explain auth.

npm permission denied: what npm itself recommends

This whole section is npm’s documentation, not Codex’s. No Codex source addresses a permission-denied global install at all; every word below is npm’s recommendation for a generic global-install EACCES, and it applies to @openai/codex only because that package is installed globally. None of it is a Codex guarantee.

If you see an EACCES error installing a package globally, npm’s documentation says you can either:

• Reinstall npm with a node version manager (recommended), or
• Manually change npm’s default directory — npm’s exact steps:

npm config set prefix ~/.local
# add to ~/.profile:    PATH=~/.local/bin:$PATH
# for zsh also add to ~/.zprofile:  source ~/.profile
source ~/.profile
# test: npm install -g npm-check-updates  then  ncu -g

npm frames the correct procedure as installing without sudo. “Just use sudo” is a widely-repeated community reflex with no first-party support — npm’s own docs specify the opposite. The manual prefix route is explicitly not cross-platform: npm states it “does not apply to Microsoft Windows.” So no single npm fix may be presented for all platforms, and this guide does not claim one.

One caveat worth stating plainly: changing npm’s prefix changes where every global package installs, not just Codex.

What not to do

• Do not run sudo npm install -g @openai/codex. npm’s own documentation specifies installing without sudo; there is no first-party source recommending sudo for this, and none from OpenAI.
• Do not apply the reporter’s pwsh/.NET proposals from #46684 as if they were instructions. They are unendorsed proposals, not a confirmed fix.
• Do not invent a version-check command. codex --version / codex version was not found in any source read here; read the version from the client’s About dialog or startup banner.
• If you remove a duplicate install to keep only one method, move it aside, do not recursively delete it, and keep the action reversible:

# example, not a literal instruction for a fixed path:
mv /the/old/codex /the/old/codex.bak

Never run a broad recursive delete (for example rm -rf across package or home directories) to clear duplicates.

• Do not disable check_for_update_on_startup to stop update prompts casually; the docs discourage it (set it to false only when updates are centrally managed).

How to tell it worked

You are done when the same install method that you identified above reports the newer build from its own About dialog or startup banner, and the update no longer fails. Because the sources do not document a version-print command, confirm the version through the client itself, not through a flag this guide does not claim exists. If you had two copies, confirm only your chosen method’s binary remains on PATH.

If it is still failing

If codex update still fails on Windows with the PowerShell error, or the desktop still launches a stale backend after auto-update, report it with: your install method, your operating system, the exact error line, and whether the failure is the Get-FileHash shape or the stale-backend shape. The two reports behind this guide are open and unconfirmed, so a clean repro with those details is what makes a useful bug report. For the refresh_token_invalidated auth symptom, see the login guide linked below.

Known limits of this guidance

• Evidence level: documentary for the spine (install methods, the documented re-run-the-installer update, and codex update’s conditional) and for the npm half; the two failure reports (#46684, #46155) are single, open, unconfirmed reports included as observed context, not as established causes or confirmed fixes.
• The documented upgrade commands for npm and Homebrew installs were not found in any source read here. This guide says “not covered” for them and points at the releases / package pages rather than inventing npm update -g or brew upgrade --cask.
• No command that prints the installed version was found. The version is read from the client’s About dialog / startup banner, not from a flag this page invents.
• codex update’s flags and which install methods support self-update are not established; the reference only promises self-update “when the installed release supports self-update.”
• No source states that mixing install methods actually breaks anything. The mechanism (different install locations) is observed; the consequence (a second copy wins) is inference, not reported fact.
• No first-party Codex source addresses a permission-denied global install; the entire npm section is npm’s guidance, not Codex’s.
• The Homebrew cask version figure read on the day it was read drifts and is not frozen here. No release note was read, so nothing here establishes that any of these failures are fixed.
• The README’s native-Windows installer vs docs/install.md’s “Windows 11 via WSL2” contradiction is unresolved by any page read here. codex doctor is documented in the Windows help section only; its cross-platform availability and output schema are unknown.