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.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks. I reviewed both suggested issues.
I don't think this is a duplicate of #21872: that one is Windows-specific and the update succeeds, but npm cleanup leaves a temporary
.codex-*directory behind.#20572 is related because it is also about the updater targeting a different install than the active CLI, but this issue covers the Linux/npm root-owned global-prefix case where
codex updatefails withEACCESbefore updating anything.The common root is that the updater currently runs the package-manager command without first checking whether the target install location is writable and whether it corresponds to the active
codexbinary inPATH.