›_ Codex Issues
Codex Issues / #24035

codex update uses standalone install.sh path instead of detecting npm-managed install

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

Environment

  • OS: Ubuntu 22.04.5 LTS
  • Codex before update: codex-cli 0.132.0
  • Codex after npm reinstall: codex-cli 0.133.0
  • npm package: @openai/codex@0.133.0

Related issue: #24034

Observed behavior

Running:

codex update

attempted to update Codex via:

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

The update then failed with:

Could not find SHA-256 digest for codex-package-x86_64-unknown-linux-musl.tar.gz in codex-package_SHA256SUMS.
Error: `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | sh'` failed with status exit status: 1

Before reinstalling with npm, the active Codex command resolved to:

/root/.codex/packages/standalone/releases/0.132.0-x86_64-unknown-linux-musl/codex

After running:

npm install -g @openai/codex@0.133.0

the same command resolved to:

/root/.local/lib/node_modules/@openai/codex/bin/codex.js

and:

codex --version

reported:

codex-cli 0.133.0

Expected behavior

If the active Codex installation is npm-managed, Codex should either:

  1. use npm-compatible update guidance, for example:

``bash
npm i -g @openai/codex@latest
``

  1. refuse self-update with a clear message explaining that this install should be updated through npm
  2. clearly state that the currently executing binary is standalone-managed, if that is the case

Actual problem

The update path was confusing because /root/.local/bin/codex stayed the visible command path, but the resolved target changed from a standalone binary to the npm package after reinstall. From the user perspective, Codex appeared npm-installed/managed, but codex update used the standalone install.sh path.

Why this matters

This creates a misleading mixed-install state and makes it unclear whether the user should use:

  • codex update
  • npm install -g @openai/codex@latest
  • install.sh / standalone updater

It also relates to #24034, where codex remote-control start used a stale standalone app-server even after the shell CLI had been upgraded via npm.

Suggested fix

Improve install-method detection and messaging:

  • detect npm-managed installs and recommend npm update
  • detect standalone installs and say explicitly that the standalone updater is being used
  • avoid silently using install.sh when the visible command path is a wrapper/symlink under ~/.local/bin
  • include resolved executable path and install method in the update output

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #24034

Powered by Codex Action

IliasAlmerekov · 3 months ago

Root cause confirmed: the background app-server daemon update loop runs the standalone installer unconditionally, regardless of install method.

update_once in codex-rs/app-server-daemon/src/update_loop.rs always calls install_latest_standalone(), which fetches https://chatgpt.com/codex/install.sh and pipes it to /bin/sh. For npm/bun/brew-managed installs this can fail with Could not find SHA-256 digest from scripts/install/install.sh (for example line 186). The loop is started for any install method via Daemon::bootstrap (codex-rs/app-server-daemon/src/lib.rs:589-593).

Note: foreground codex update is not the culprit. It already maps npm installs to npm install -g @openai/codex through UpdateAction::from_install_context (codex-rs/tui/src/update_action.rs:25). Only the hidden daemon updater runs install.sh.

Fix outline: gate the standalone installer call on install method:

if matches!(
InstallContext::current().method,
InstallMethod::Standalone { ... }
) {
install_latest_standalone().await?;
}

codex-install-context is already in the workspace.

Open question: bootstrap still returns auto_update_enabled: true (codex-rs/app-server-daemon/src/lib.rs:600) for non-standalone installs, which may be misleading after this guard.

preference-kim · 3 months ago

Hi, I ran into the same error and wanted to share a workaround that makes the standalone installer succeed even if it gets triggered.

sudo apt install gawk

Here are my shell logs showing the before and after:

``` shell
...

Before (same with you)

$ sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | sh'
...
==> Resolved version: 0.133.0
==> Downloading Codex CLI
Could not find SHA-256 digest for codex-package-x86_64-unknown-linux-musl.tar.gz in codex-package_SHA256SUMS.
Error: sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | sh' failed with status exit status: 1

Install gawk

$ sudo apt install gawk
...

After (fixed)

$ sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | sh'
...
==> Resolved version: 0.133.0
==> Downloading Codex CLI
==> Installing standalone package to /root/.codex/packages/standalone/releases/0.133.0-x86_64-unknown-linux-musl
==> /root/.local/bin is already on PATH
==> Current terminal: codex
==> Future terminals: open a new terminal and run: codex
Codex CLI 0.133.0 installed successfully.
Start Codex now? [y/N] y
==> Launching Codex

Done :)


My environment: Ubuntu 22.04 (Jammy), Docker container, x86_64.

The install script likely uses `gawk`-specific syntax for SHA-256 verification that isn't compatible with the default `awk` (mawk) on some Ubuntu images. This seems like a bug — the script should work regardless of whether `awk` or `gawk` is installed.