codex - 💡(How to fix) Fix Codex Desktop WSL runtime fails to activate WSL fnm Node/npm and falls back to Windows npm [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20810Fetched 2026-05-03 04:45:01
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Error Message

/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)

Root Cause

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.

Fix Action

Fix / Workaround

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

Code Example

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

---

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

---

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

---

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

---

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

---

/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

---

/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)

---

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

---

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

---

export PATH="/home/yusuf/.local/share/fnm:$PATH"
eval "$(fnm env --use-on-cd --shell zsh)"

---

node --version
npm --version
which npm
/home/yusuf/.local/share/fnm/fnm env --use-on-cd --shell zsh
RAW_BUFFERClick to expand / collapse

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
  4. 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
  2. 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:

extent analysis

TL;DR

The issue can be worked around by redirecting fnm state to a writable location, such as /tmp, to allow successful activation of the WSL-side Node.js environment.

Guidance

  • Verify that the WSL-side fnm install exists and has Linux Node versions installed by running /home/yusuf/.local/share/fnm/fnm list.
  • Redirect fnm state to a writable location, such as /tmp, by setting XDG_STATE_HOME=/tmp before running fnm env --shell zsh.
  • Manually activate the WSL-side Node.js environment by running PATH=/home/yusuf/.local/share/fnm/aliases/default/bin:$PATH node --version and PATH=/home/yusuf/.local/share/fnm/aliases/default/bin:$PATH npm --version.
  • Check the Codex documentation for any supported writable state locations or workarounds for the sandbox restrictions.

Example

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

This command redirects fnm state to /tmp and activates the WSL-side Node.js environment.

Notes

The issue seems to be related to the Codex Desktop WSL runtime environment/sandbox restrictions, which prevent fnm from writing to ~/.local/state/fnm_multishells. The workaround of redirecting fnm state to /tmp allows successful activation of the WSL-side Node.js environment.

Recommendation

Apply the workaround by redirecting fnm state to a writable location, such as /tmp, to allow successful activation of the WSL-side Node.js environment. This workaround is necessary due to the sandbox restrictions in the Codex Desktop WSL runtime environment.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop WSL runtime fails to activate WSL fnm Node/npm and falls back to Windows npm [1 participants]