›_ Codex Issues
Codex Issues / #29045

Remote SSH bootstrap prefers stale ~/.local/bin/codex over newer /usr/bin/codex and reports version mismatch without selected path

Open 💬 2 comments Opened Jun 19, 2026 by jimmcguffinus

Summary

Codex Desktop Remote SSH failed because the remote bootstrap selected an old standalone Codex symlink from ~/.local/bin/codex even though a newer /usr/bin/codex existed and satisfied the required version.

The UI reported only a version mismatch:

Minimum required: 0.141.0
Currently installed: 0.130.0

But it did not show the selected path:

/home/jim/.local/bin/codex

or the newer candidate later in PATH:

/usr/bin/codex

This made the problem look like the remote host had not been updated, even though /usr/bin/codex had been updated correctly.

Environment

Client:

  • Windows Codex Desktop
  • Remote SSH target: Linux host clawprod

Remote host:

  • hostname: clawprod
  • user: jim
  • shell: bash
  • Codex involved in Remote SSH app-server bootstrap

What happened

The remote host had multiple Codex installs:

Old standalone Codex:
  /home/jim/.local/bin/codex
  -> /home/jim/.codex/packages/standalone/current/codex
  version: 0.130.0

New npm global Codex:
  /usr/bin/codex
  -> /usr/lib/node_modules/@openai/codex/bin/codex.js
  version: 0.141.0

After running:

sudo npm install -g @openai/codex@latest

the system Codex was updated successfully:

/usr/bin/codex -> ../lib/node_modules/@openai/codex/bin/codex.js
codex-cli 0.141.0

But Remote SSH still failed because the bootstrap path preferred the stale standalone symlink.

The running bootstrap process showed:

/bin/sh -c printf '%b' '...'; PATH="${CODEX_INSTALL_DIR:-$HOME/.local/bin}:$PATH"; export PATH; codex app-server proxy

That prepends ~/.local/bin to PATH, so the old standalone Codex won the PATH race.

Evidence from the remote host

Current resolution after removing the stale symlink:

codex-cli 0.141.0
/usr/bin/codex
/usr/bin/codex
/bin/codex
codex is /usr/bin/codex

System Codex symlink:

/usr/bin/codex -> ../lib/node_modules/@openai/codex/bin/codex.js
/bin/codex -> ../lib/node_modules/@openai/codex/bin/codex.js
Birth/Modify: 2026-06-18 21:46:04 -0700

Old standalone symlink that had been first in PATH:

/home/jim/.local/bin/codex
-> /home/jim/.codex/packages/standalone/current/codex
version: 0.130.0
Birth: 2026-05-18 14:39:36 -0700

The old symlink was moved aside to confirm the fix:

mkdir -p ~/.local/bin/old-codex
mv ~/.local/bin/codex ~/.local/bin/old-codex/codex-0.130.0
hash -r
codex --version

After that, codex --version resolved to 0.141.0 and Remote SSH worked.

Auth log confirms the system npm update was run by the user:

2026-06-18T21:45:22 clawprod sudo: jim : COMMAND=/usr/bin/npm install -g @openai/codex@latest
2026-06-18T21:46:02 clawprod sudo: jim : COMMAND=/usr/bin/npm install -g @openai/codex@latest

Root npm logs confirm the package installed was @openai/codex@0.141.0 and that /usr/bin/codex was updated:

verbose title npm install @openai/codex@latest
verbose argv "install" "--global" "@openai/codex@latest"
silly placeDep ROOT @openai/codex@0.141.0 OK
silly reify mark retired [ '/usr/lib/node_modules/@openai/codex', '/usr/bin/codex' ]

Why this is confusing

The Codex standalone installer itself defaults to:

BIN_DIR="${CODEX_INSTALL_DIR:-$HOME/.local/bin}"
BIN_PATH="$BIN_DIR/codex"
CODEX_HOME_DIR="${CODEX_HOME:-$HOME/.codex}"
STANDALONE_ROOT="$CODEX_HOME_DIR/packages/standalone"

and creates a visible command symlink at $BIN_DIR/codex.

The installer also warns that:

Multiple managed Codex installs can be ambiguous because PATH order decides which one runs.

That is exactly what happened here, but the Remote SSH UI did not show enough detail to diagnose it.

Expected behavior

When Codex Desktop Remote SSH rejects a remote CLI version, it should show:

Required version: >= 0.141.0
Selected codex path: /home/jim/.local/bin/codex
Selected codex version: 0.130.0
Other codex candidates:
  /usr/bin/codex = 0.141.0
  /bin/codex = 0.141.0

It should also offer a repair suggestion such as:

A stale standalone Codex was found first in PATH.
Update the standalone install, remove ~/.local/bin/codex, or set CODEX_INSTALL_DIR to the intended install directory.

Actual behavior

The UI showed only:

Minimum required: 0.141.0
Currently installed: 0.130.0

It did not show the selected binary path or the presence of a newer valid binary later in PATH.

Suggested fix

  1. During Remote SSH bootstrap, run and display:
command -v codex
codex --version
type -a codex
  1. If the selected Codex is too old but another candidate later in PATH satisfies the version requirement, report that clearly.
  1. Consider not unconditionally prepending ${CODEX_INSTALL_DIR:-$HOME/.local/bin} ahead of PATH when a newer valid codex already exists.
  1. At minimum, make the error actionable by showing exact path/version resolution.

View original on GitHub ↗

2 Comments

jimmcguffinus · 2 months ago

Addendum: clean reproduction and repair on claw2

I reproduced and repaired this on a second remote host, claw2. This is a cleaner reproduction than clawprod, because claw2 had only the standalone Codex install and was not modified by installing a second npm/system Codex.

Before repair

The only Codex install was:

/home/jim/.local/bin/codex
-> /home/jim/.codex/packages/standalone/current/codex
-> /home/jim/.codex/packages/standalone/releases/0.130.0-x86_64-unknown-linux-musl/codex

codex --version reported:

codex-cli 0.130.0

There were no system Codex candidates; all of these were absent:

/usr/bin/codex
/bin/codex
/usr/local/bin/codex

Codex Desktop Remote SSH required Codex CLI 0.141.0 or newer and rejected this host.

Repair

I ran the official standalone installer again, without sudo npm and without removing ~/.local/bin/codex.

Installer output:

Updating Codex CLI from 0.130.0 to 0.141.0
Installing standalone package to /home/jim/.codex/packages/standalone/releases/0.141.0-x86_64-unknown-linux-musl
Codex CLI 0.141.0 installed successfully.

After repair:

$ codex --version
codex-cli 0.141.0

$ command -v codex
/home/jim/.local/bin/codex

$ readlink -f "$(command -v codex)"
/home/jim/.codex/packages/standalone/releases/0.141.0-x86_64-unknown-linux-musl/bin/codex

Remote bootstrap simulation

PATH="${CODEX_INSTALL_DIR:-$HOME/.local/bin}:$PATH"
export PATH
command -v codex
codex --version
readlink -f "$(command -v codex)"

returned:

/home/jim/.local/bin/codex
codex-cli 0.141.0
/home/jim/.codex/packages/standalone/releases/0.141.0-x86_64-unknown-linux-musl/bin/codex

Codex Desktop still required a full desktop app close and relaunch before the claw2 remote turned green. This suggests the desktop app cached or reused the prior failed remote state.

Corrected root cause and repair guidance

The clean fix was not to install a second Codex with sudo npm. The clean fix was to update the active standalone install family already selected by Remote SSH:

~/.local/bin/codex
~/.codex/packages/standalone/current

The earlier clawprod reproduction became less clean after sudo npm install -g @openai/codex@latest created a second npm/system install at /usr/bin/codex.

Requested product improvements

  1. When Remote SSH reports a version mismatch, show the exact selected remote codex path.
  2. Show all discovered codex candidates from PATH.
  3. Distinguish a standalone install from an npm/system install.
  4. Suggest updating the active install family instead of blindly installing another Codex elsewhere.
  5. After a remote version repair, allow refresh/reprobe without requiring a full Codex Desktop restart, or clearly state that a restart is required.
jimmcguffinus · 2 months ago

Final cleanup result: clawprod normalized to standalone too

After the clean claw2 standalone repair, I normalized clawprod to the same final layout.

Originally, clawprod had been repaired with a dirty workaround during troubleshooting:

sudo npm install -g @openai/codex@latest

That created an npm/system Codex at:

/usr/bin/codex
/bin/codex

Then moving the stale ~/.local/bin/codex aside made /usr/bin/codex win PATH resolution. That worked, but it left mixed install families.

I have now cleaned that up.

clawprod final active Codex

After rerunning the standalone installer on clawprod, the active command is now:

codex-cli 0.141.0
command -v codex = /home/jim/.local/bin/codex

The symlink resolves to the standalone release:

/home/jim/.local/bin/codex
-> /home/jim/.codex/packages/standalone/current/bin/codex
-> /home/jim/.codex/packages/standalone/releases/0.141.0-x86_64-unknown-linux-musl/bin/codex

Remote bootstrap simulation also selects the standalone binary correctly:

PATH="${CODEX_INSTALL_DIR:-$HOME/.local/bin}:$PATH"
export PATH
command -v codex
codex --version
readlink -f "$(command -v codex)"

returned:

/home/jim/.local/bin/codex
codex-cli 0.141.0
/home/jim/.codex/packages/standalone/releases/0.141.0-x86_64-unknown-linux-musl/bin/codex

Removed accidental npm/system duplicate

The npm/system install created during troubleshooting was removed:

sudo npm uninstall -g @openai/codex
hash -r

After removal:

codex-cli 0.141.0
command -v codex = /home/jim/.local/bin/codex
which -a codex = /home/jim/.local/bin/codex

and these no longer appear:

/usr/bin/codex
/bin/codex
/usr/local/bin/codex

Final result

Both claw2 and clawprod now use the same clean standalone layout:

~/.local/bin/codex
-> ~/.codex/packages/standalone/current/bin/codex
-> ~/.codex/packages/standalone/releases/0.141.0-x86_64-unknown-linux-musl/bin/codex

Codex Desktop was restarted, and all remotes are green.

This confirms the clean local repair path is:

Update the active standalone install family.
Do not create or rely on a second npm/system Codex install.

The product request remains the same: when Remote SSH rejects a remote Codex version, the UI should show the selected binary path, selected version, and other PATH candidates, and should recommend updating the active install family rather than blindly installing another Codex elsewhere.