Remote SSH connection fails when Node.js is installed via nvm: "No codex found in PATH" and silent app-server launch failure
Open 💬 5 comments Opened Apr 27, 2026 by danohn
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.422.30944 (2080)
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
Codex Desktop fails to connect to remote SSH hosts when Node.js (and the codex CLI) is installed via nvm. There are two distinct failures:
- "No
codexfound in PATH" — the PATH probe uses a login+interactive shell (/bin/bash -l -i) but nvm may not initialise, socodexisn't found even though it's installed.
- Silent ECONNRESET after the probe succeeds — even when the PATH probe passes (e.g. after symlinking
codexto/usr/local/bin), the app-server launch fails silently. Codex Desktop launches the server via a non-interactive SSH command using/usr/bin/env node, which can't findnodesince nvm isn't loaded. The WebSocket immediately closes with code 1006 (ECONNRESET) and no actionable error is shown in the UI. The actual error (/usr/bin/env: 'node': No such file or directory) is only visible in/tmp/codex-app-server-ssh-ws-v0.logon the remote.
What steps can reproduce the bug?
- Install Node.js via nvm on a remote Linux machine
- Install the
codexCLI via npm (npm install -g @openai/codex) - Add the remote host to
~/.ssh/configon the local macOS machine - Open Codex Desktop and attempt to enable the remote SSH connection
- Observe "No
codexfound in PATH" error - Symlink
codexto/usr/local/bin/codexon the remote to get past step 5 - Observe persistent connection failure with ECONNRESET — no actionable error shown in the UI
What is the expected behavior?
Codex Desktop should use the same shell environment for both the PATH probe and the app-server launch, so nvm-managed binaries work consistently without manual symlinks. If the launch does fail, the actual error from the remote (e.g. node not found) should be surfaced in the UI rather than a generic connection failure.
Additional information
- Codex Desktop version: 0.125.0-alpha.3 (macOS)
- Remote OS: Linux (Debian/Ubuntu), Node.js installed via nvm v24.15.0
- The workaround requires two symlinks on the remote machine:
ln -sf ~/.nvm/versions/node/$(node --version)/bin/codex /usr/local/bin/codex
ln -sf ~/.nvm/versions/node/$(node --version)/bin/node /usr/local/bin/node
- The real server-side error is logged to
/tmp/codex-app-server-ssh-ws-v0.logon the remote, which is not currently surfaced anywhere in Codex Desktop
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
The root cause is that
/bin/shon Debian/Ubuntu isdash, notbash. Codex Desktop'sPATH probe runs
/bin/sh -lc '...', which sources/etc/profileand~/.profilebutNOT
~/.bashrcwhere nvm is initialised. As a result, nvm's bin directory is absentfrom the PATH seen by Codex Desktop, even though it is present in regular interactive
SSH sessions.
Dash PATH (what Codex Desktop sees):
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Bash PATH (what a normal SSH session sees):
/root/.local/bin:/root/.nvm/versions/node/v24.15.0/bin:/usr/local/sbin:/usr/local/bin:...
@danohn Thanks for pointing that out. Here’s my workaround: add the NVM initialization to
~/.profilefrom~/.bashrc.this works
Adding one more data point: I hit the same underlying issue from the ChatGPT iPhone Codex UI connecting to a remote Linux host.
In my interactive shell, Codex worked because
nvmwas loaded:But a clean login-shell simulation could not find
codex:Instead of moving all
nvminitialization into~/.profile, this user-local wrapper also fixed it for me:Then the clean-shell check found:
After that, ChatGPT iPhone Codex UI was able to connect to the remote Linux host.
This works if
~/.local/binis already on the login-shell PATH, which is common on Linux via~/.profile. It avoidssudo, avoids changing/usr/local/bin, and avoids sourcing all ofnvmfrom~/.profile.The key difference from moving
nvminitialization into~/.profileis scope: this does not make every login shell loadnvm; it only makescodexwork when something tries to runcodex.