Codex Windows app (WSL): non-interactive shell doesn’t load NVM, so node/pnpm are missing from PATH (command not found)

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

• #13556
• #13160

Powered by Codex Action

Mine started doing this last night and got very confused, started using increasingly convoluted path hacks to try and utilize npm etc that have always worked just fine

mine doesn't work at all. no responses. thinking without results, it's just broken on windows 11

I just installed the Codex App. Codex was running node/npm fine 10 minutes before in CLI and VS Extension. After installing the app every time I try to run it, I get: Assertion failed: ncrypto::CSPRNG(nullptr, 0)

I can confirm the exact same problem on an identical platform. Even the model itself confirms that it is running a non-interactive shell:

---
Yes, the comparison confirms it clearly: ~/.zshrc is not loaded in the shell I use by default, but it is loaded when I explicitly start an interactive zsh -i.

Comparison:

mode=current
SHELL=/usr/bin/zsh

In the current shell, neither ll nor node was available.

mode=interactive
SHELL=/usr/bin/zsh
alias ll='ls -lh'
/home/david/.nvm/versions/node/v22.18.0/bin/node
v22.18.0

This shows:

• In zsh -i, the alias ll='ls -lh' is set.
• nvm from zshrc is loaded.
• As a result, node is available and reports v22.18.0.

The additional error messages in zsh -i happened because the environment here is read-only and oh-my-zsh/compinit tried to create cache files. They are not relevant to the actual conclusion.

I'm Codex, and I was able to reproduce a very similar issue on Codex App on Windows with a WSL workspace.

What I observed:

• The app-level command runner does not behave like an already-initialized interactive terminal tab.
• In WSL, that means shell-managed runtime setup can be skipped depending on where it is defined.
• In my repro, a normal WSL terminal had Node/pnpm available, but Codex command execution initially fell back to the system Node / missing pnpm because the shell session did not load the same init path.

The important distinction is:

• If your Node toolchain is initialized only inside an interactive-only branch of ~/.zshrc / ~/.bashrc, Codex can miss it.
• A regular terminal still works because it is interactive.

For zsh users, the direction mentioned in older issues/comments still makes sense: put the minimal NVM/Node PATH setup into a file that non-interactive zsh actually loads (for example ~/.zshenv, with the usual caveats).

For bash users on Ubuntu/WSL, the equivalent workaround is not .zshenv, but moving the minimal shared toolchain setup above the interactive early-return in ~/.bashrc. Example pattern:

# shared env for both interactive and non-interactive shells
export NVM_DIR="$HOME/.nvm"
if [ -d "$HOME/.nvm/versions/node" ]; then
  for candidate in "$HOME/.nvm/versions/node"/v22*/bin; do
    if [ -x "$candidate/node" ]; then
      case ":$PATH:" in
        *":$candidate:"*) ;;
        *) export PATH="$candidate:$PATH" ;;
      esac
      break
    fi
  done
fi

# if not running interactively, stop here
case $- in
  *i*) ;;
    *) return;;
esac

After doing that and starting a fresh shell / fresh app session, node, npm, npx, and pnpm became available in Codex command execution as well.

So from my side this issue looks less like "NVM itself is broken" and more like "Codex App on Windows + WSL is not inheriting the same shell init path as a normal interactive terminal".

A product-level fix would ideally be one of:

1. Respect the user's actual shell startup path more consistently in WSL workspaces
2. Provide an explicit setting for shell init / env injection in the app
3. Document clearly that non-interactive Codex command sessions may skip interactive-only shell init, and provide shell-specific guidance (zshenv, BASH_ENV, etc.)

Hope this helps narrow it down.

我是 Codex，我在 Windows 上的 Codex App 中使用 WSL 工作区重现了非常类似的问题。 我的观察结果： 应用程序级别的命令运行器的行为与已初始化的交互式终端选​​项卡不同。 在 WSL 中，这意味着可以根据定义位置跳过 shell 管理的运行时设置。 在我的复现过程中，一个普通的 WSL 终端有 Node/pnpm 可用，但 Codex 命令执行最初回退到系统 Node / 缺少 pnpm，因为 shell 会话没有加载相同的初始化路径。 重要的区别在于： 如果您的 Node 工具链仅在 ~/.zshrc / ~/.bashrc 的交互式分支中初始化，则 Codex 可能无法识别它。 普通终端仍然可以工作，因为它具有交互性。 对于 zsh 用户来说，旧问题/评论中提到的方向仍然有意义：将最小的 NVM/Node PATH 设置放入非交互式 zsh 实际加载的文件中（例如 ~/.zshenv ，但需注意通常的注意事项）。 对于 Ubuntu/WSL 上的 bash 用户，等效的解决方法不是使用 .zshenv ，而是将_最小共享工具链配置_移到 ~/.bashrc 中交互式提前返回配置的上方。示例模式： # shared env for both interactive and non-interactive shells export NVM_DIR="$HOME/.nvm" if [ -d "$HOME/.nvm/versions/node" ]; then for candidate in "$HOME/.nvm/versions/node"/v22/bin; do if [ -x "$candidate/node" ]; then case ":$PATH:" in ":$candidate:") ;; ) export PATH="$candidate:$PATH" ;; esac break fi done fi # if not running interactively, stop here case $- in i) ;; ) return;; esac 完成上述操作并启动一个新的 shell / 一个新的应用程序会话后， node 、 npm 、 npx 和 pnpm 也可以在 Codex 命令执行中使用。 所以在我看来，这个问题与其说是“NVM 本身出了问题”，不如说是“Windows + WSL 上的 Codex 应用程序没有继承与普通交互式终端相同的 shell 初始化路径”。 理想的产品级修复方案应为以下几种： 1. 在 WSL 工作区中更一致地尊重用户的实际 shell 启动路径 2. 在应用程序中提供 shell 初始化/环境变量注入的明确设置 3. 明确说明非交互式 Codex 命令会话可以跳过仅用于交互式 shell 初始化，并提供特定于 shell 的指导（ zshenv 、 BASH_ENV 等）。 希望这能帮助缩小范围。

This is the issue I found, as well as his solution, after adjustments via Codex, it now works normally on my platform.

To the codex team that is potentially going to work on this, even though the temporary solution of changing ~/.profile or the bash login scripts for bash -lc works, this is a nuance bug that further breaks with subagents. The propagation is not properly set up. Subagent command shells inherit a stale environment from the Codex app server instead of starting with the profile/rc starting scripts no matter what. Because of that, shell startup-based PATH setup is skipped, so user-installed commands or program like node, may be missing even though they work in normal bash -lc or bash -ic shells in the main thread. You have to make sure your subagent shells also work!

I can reproduce the same class of issue on Windows + WSL, with fnm rather than nvm.

Environment:

• Codex Windows App package: 26.422.2437.0
• WSL bridge CLI: codex-cli 0.124.0-alpha.2
• Windows: 10.0.26200.8246
• WSL: 2.6.3.0
• Distro: Ubuntu 24.04.4 LTS, WSL2
• Shell: /usr/bin/zsh (zsh 5.9)
• Repo location: WSL filesystem/ext4, /home/<user>/.../<repo>, not /mnt/c
• Node manager: fnm 1.38.1
• Project has .node-version = 20.19.6
• No .nvmrc; nvm is not installed on this machine

Diagnostics:

• In the current Codex command session:
• command -v node -> not found
• node -v -> zsh: command not found: node
• command -v npm -> not found
• npm -v -> zsh: command not found: npm
• command -v pnpm -> not found
• pnpm -v -> zsh: command not found: pnpm
• command -v fnm -> not found

• With a non-login shell:
• zsh -c 'command -v node; node -v; command -v npm; npm -v'
• same result: Node/npm are not found

• With a login shell:
• zsh -lc 'command -v fnm; fnm --version; command -v node; node -v; command -v npm; npm -v; command -v corepack; corepack --version'
• finds fnm 1.38.1
• finds Node under /home/<user>/.local/share/fnm/aliases/default/bin/node
• node -v -> v20.19.6
• npm -v -> 10.8.2
• corepack --version -> 0.34.1

On this machine, fnm is initialized from ~/.profile, which adds the fnm directory and the default alias bin directory to PATH. That explains the difference: zsh -lc loads the login profile, while the command session / zsh -c path does not.

Root-cause hypothesis:

Codex command execution in the Windows App + WSL path appears to run a non-login/non-interactive shell. For Node installed via nvm/fnm, that commonly means the shell init that adds the Node toolchain to PATH is skipped, so node, npm, corepack, and pnpm disappear even though the same WSL environment works once the relevant profile/init has been loaded.

Low-risk fix direction:

• I would avoid forcing every command through a login shell by default, since that can have side effects for some users.
• A safer direction may be a configurable shell/env init hook for command execution, especially in WSL mode.
• At minimum, Codex could warn when a project contains .nvmrc or .node-version but node is not found in the command environment, and suggest configuring/sourcing the relevant nvm/fnm init.