Codex updater should handle root-owned npm global installs and multiple install targets more explicitly
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?
- Install Codex system-wide with npm, for example:
``bash``
sudo npm install -g @openai/codex
- Confirm the active binary points into
/usr:
``bash``
command -v codex
readlink -f "$(command -v codex)"
codex --version
- Run the updater as the normal user:
``bash``
codex update
- Observe that Codex runs:
``bash``
npm install -g @openai/codex
- npm fails with
EACCESbecause 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 inPATH; 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
codexbinary.
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.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗