›_ Codex Issues
Codex Issues / #20810

Codex Desktop WSL runtime fails to activate WSL fnm Node/npm and falls back to Windows npm

Open 💬 0 comments Opened May 2, 2026 by Yusuf007R

What version of the Codex App are you using (From “About Codex” dialog)?

26.429.20946

What subscription do you have?

PRO

What platform is your computer?

Windows host with Ubuntu WSL2.

WSL distro output:

NAME              STATE           VERSION
* Ubuntu          Running         2
  docker-desktop  Stopped         2

Inside the Codex WSL tool shell:

uname -a
Linux Yukariko 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

What issue are you seeing?

When using Codex Desktop on Windows with the agent runtime set to WSL, commands launched by Codex do not correctly activate the WSL-side fnm Node.js environment.

Inside the Codex tool shell, node is not found:

node --version
zsh:1: command not found: node

npm resolves to the Windows-side fnm/npm shim under /mnt/c/... instead of the WSL-side npm:

which npm
/mnt/c/Users/Yusuf/AppData/Roaming/fnm/aliases/default/npm

Running npm then fails with a misleading WSL error:

npm --version
WSL 1 is not supported. Please upgrade to WSL 2 or above.
Could not determine Node.js install directory

The distro is actually WSL2, as shown above by both wsl --list --verbose and uname -a.

The WSL-side fnm install exists and has Linux Node versions installed:

/home/yusuf/.local/share/fnm/fnm list
* v18.20.8
* v20.11.1
* v20.18.0
* v22.5.1
* v22.7.0
* v22.9.0
* v22.10.0
* v22.19.0
* v22.22.0 default
* v23.2.0
* v24.4.0
* system

But fnm env fails inside the Codex command sandbox:

/home/yusuf/.local/share/fnm/fnm env --use-on-cd --shell zsh
error: Can't create the symlink for multishells at "/home/yusuf/.local/state/fnm_multishells/2_1777746760013". Maybe there are some issues with permissions for the directory? Read-only file system (os error 30)

Because that activation fails, the WSL Node path is not added to PATH, and Codex falls through to Windows PATH entries mounted under /mnt/c.

Manual direct activation works:

PATH=/home/yusuf/.local/share/fnm/aliases/default/bin:$PATH node --version
v22.22.0

PATH=/home/yusuf/.local/share/fnm/aliases/default/bin:$PATH npm --version
10.9.4

Also, redirecting fnm state to /tmp works inside the Codex sandbox:

XDG_STATE_HOME=/tmp /home/yusuf/.local/share/fnm/fnm env --shell zsh

This outputs a valid fnm multishell PATH under /tmp/fnm_multishells/....

So this looks like a Codex Desktop WSL runtime environment/sandbox issue:

  • WSL-side shell startup does not successfully activate fnm.
  • The sandbox prevents fnm from writing to ~/.local/state/fnm_multishells.
  • Windows PATH entries remain available inside the WSL command environment, so Windows npm is selected as a fallback.

What steps can reproduce the bug?

  1. On Windows, install Codex Desktop.
  2. Enable WSL agent runtime and select an Ubuntu WSL2 distro.
  3. In WSL, use fnm installed under the Linux home directory, for example:

/home/yusuf/.local/share/fnm/fnm

  1. Configure shell startup with fnm, for example in ~/.zshrc:
export PATH="/home/yusuf/.local/share/fnm:$PATH"
eval "$(fnm env --use-on-cd --shell zsh)"
  1. Open a repo that lives inside WSL, for example:

/home/yusuf/code/ifudis/ifudis

  1. Ask Codex to run:
node --version
npm --version
which npm
/home/yusuf/.local/share/fnm/fnm env --use-on-cd --shell zsh

Observed result:

  • node is not found.
  • npm resolves to /mnt/c/Users/Yusuf/AppData/Roaming/fnm/aliases/default/npm.
  • npm fails with WSL 1 is not supported, even though the distro is WSL2.
  • fnm env fails because it cannot create ~/.local/state/fnm_multishells/... due to read-only filesystem restrictions.

What is the expected behavior?

When Codex Desktop is running the agent in WSL mode:

  • WSL shell startup should be able to activate the WSL-side Node.js version manager.
  • node and npm should resolve to Linux binaries inside WSL, not Windows binaries under /mnt/c.
  • The sandbox should either allow required version-manager state paths such as ~/.local/state/fnm_multishells, or provide/document a supported writable state location.
  • Windows PATH entries should not take precedence over missing or failed WSL toolchain activation in a way that silently invokes Windows npm from inside WSL.

Additional information

Related issues:

View original on GitHub ↗