Why does Codex use the system node installation over NVM? Using node v16 constantly

I encountered the same problem on macOS. The workaround is to uninstall the system's Node, and then Codex will use the Node from NVM when executing CLI commands.

I encountered the same problem on macOS. The workaround is to uninstall the system's Node, and then Codex will use the Node from NVM when executing CLI commands.

That is an awful workaround :(, hoping the Codex team can fix this!

System node is needed for a lot of random mac processes, just like the system python is.

This is really annoying.

I've found the following in my AGENTS.md works:

This app uses Node v22, which can be accessed via nvm. If you are getting the wrong node version then run nvm use 22, change to this directory and then run npm run <command> in the same shell session. It is very important that you run NVM and the NPM command in the same shell session. If it is in another session you get the wrong version of node.

This is really annoying. I've found the following in my AGENTS.md works: > This app uses Node v22, which can be accessed via nvm. > If you are getting the wrong node version then run nvm use 22, change to this directory and then run npm run <command> _in the same shell session_. It is very important that you run NVM and the NPM command in the same shell session. If it is in another session you get the wrong version of node.

Not working for processes that spawns subprocesses, e.g. Cypress

This is a huge pain if you have to run any app or tool that needs a node version greater than 16, which is most things these days because v16 reached end of life in 2023 🫠

The worst part is that the agent will actually spend time trying to debug its own Node version before giving up and telling the user to run commands. Prefixing with nvm/fnm is a less destructive hack than uninstalling your system node, but it is a partial workaround.

This is still a considerable pain point and the workarounds are brittle. I'm guessing this will impede anyone working with codex in a JS/TS environment.

At minimum, it would help to clearly document the Node resolution behavior. Ideally, Codex should respect the Node version of the shell it’s launched from (or allow configuring this explicitly).

I'm still encountering the same issue with codex persistently using system node like v14 and have not found a good workaround that's sustainable.

This is kind of a weird issue that I spent the better part of a day working on. The solution for me was to add the sourcing to ~/.zshenv (instead of ~/.zshrc or ~/.zprofile).

I also added this to ~/.zprofile:

# macOS /etc/zprofile uses path_helper after zshenv, which can drop shims/PATH.
if [[ "$(uname)" == Darwin ]]; then
  unset __ZSHENV_SOURCED
  source "$HOME/.zshenv"
fi
__ZSHENV_SOURCED=1

This worked for both nvm and rbenv for me (I was having problems with both).

In my case it defaults to the NVM's default (likely because it's a default on OS level), but if a project uses other it first fails, then it realizes what's wrong and works with NVM.

I'm using this in AGENTS.md on project level:

Runtime baseline is Node version defined by `.nvmrc` and `package.json` (`engines.node`)

So: wastes time, but isn't stuck.
Maybe that will be a progress to someone

(gpt-5.3-codex, Codex.app 26.212.1823 (661))