Codex updater should handle root-owned npm global installs and multiple install targets more explicitly

Open 💬 2 comments Opened May 9, 2026 by Komzpa

What version of Codex CLI is running?

codex-cli 0.130.0

What platform is your computer?

Linux x86_64, Debian-style system npm layout

What issue are you seeing?

Codex's self-updater runs:

npm install -g @openai/codex

This works only when the active npm global prefix is writable by the current user and matches the codex binary that is actually first in PATH.

On my machine, Codex had previously been installed system-wide under /usr/lib/node_modules/@openai/codex via sudo npm install -g @openai/codex. When Codex later offered to update itself, codex update ran plain npm install -g @openai/codex as the normal user and failed with EACCES while trying to rename the root-owned package directory.

There was also an older local install under ~/node_modules/@openai/codex, which could shadow or confuse updates depending on PATH / shell / package-manager setup.

This looks like the same family of problems as:

  • #10342: npm global install fails with EACCES
  • #18485: whether Codex really needs a global npm install
  • #12107: update loop when multiple Codex copies are installed
  • #16383: upgrade appears to run but the active version remains old
  • #16488: updater reports success even when the installed version does not actually change

What steps can reproduce the bug?

  1. Install Codex system-wide with npm, for example:

``bash
sudo npm install -g @openai/codex
``

  1. Confirm the active binary points into /usr:

``bash
command -v codex
readlink -f "$(command -v codex)"
codex --version
``

  1. Run the updater as the normal user:

``bash
codex update
``

  1. Observe that Codex runs:

``bash
npm install -g @openai/codex
``

  1. npm fails with EACCES because the global package directory is root-owned.

What is the expected behavior?

Codex should either:

  • detect that the active npm global prefix/package directory is not writable and give a clear remediation, e.g. configure a user-local npm prefix such as ~/.local, reinstall there, and ensure it is first in PATH; or
  • detect that Codex is installed in a root-owned/system prefix and explicitly tell the user to update using their system install method; or
  • avoid claiming/updating against a different install target than the active codex binary.

It would also help if the official npm install docs mentioned the user-local prefix path for Linux users whose npm global prefix points to /usr or /usr/local.

What actually fixed it locally?

I fixed my machine by moving npm global installs to a user-owned prefix and removing the system Codex copy:

npm config set prefix ~/.local
npm install -g @openai/codex
sudo npm --prefix /usr uninstall -g @openai/codex

After that:

command -v codex
# /home/kom/.local/bin/codex

npm prefix -g
# /home/kom/.local

codex update
# Updating Codex via `npm install -g @openai/codex`...
# changed 2 packages
# 🎉 Update ran successfully! Please restart Codex.

Additional information

This is partly an npm/Linux packaging footgun, but Codex currently has enough context to make the failure less confusing: it knows it is about to run npm install -g @openai/codex, and it can compare the active binary path, npm global prefix, and package directory ownership before trying the update.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗