codexコマンドが急に見つからなくなった
理由
（nvmとsudo npm installの衝突）

Codex CLIを使っていたLinux Mint機で、ある日突然 codex コマンドが動かなくなりました。

$ codex resume
コマンド 'codex' が見つかりませんCode language: JavaScript (javascript)

which codex も空です。
もう一度インストールし直すと動くのですが、原因が気になったので調べてみました。

1. 直接の原因はPATH解決の失敗

「PATH（コマンドを探すディレクトリの並び）」上に codex の実体が存在しない状態でした¹。
codex resume でも codex --version でも同じエラーになるので、Codex自体が壊れたのではなく、シェルが実行ファイルを見つける段階で失敗していたことになります。

原因を切り分けるために、次のコマンドを実行しました。

command -v codex
type -a codex
npm config get prefix
npm root -g
npm list -g --depth=0 | grep codex
echo "$PATH" | tr ':' '\n'Code language: Bash (bash)

結果を見ると、通常ユーザーのnpmグローバルインストール先は ~/.nvm/versions/node/v24.18.0 でしたが、そこには @openai/codex が入っていませんでした。
以前の codex は、nvmで管理しているNode環境の中に入っていたと考えられます。

2. nvm環境とsudo npm installは別管理になる

ここで一度、sudo npm install -g @openai/codex で入れ直したところ、codex は動くようになりました。
ただしその実体は /usr/bin/codex で、リンク先は /usr/lib/node_modules/@openai/codex/bin/codex.js でした。

つまり、これは同じ @openai/codex パッケージでも、インストール先がまったく別の場所になったということです。

nvmは、ユーザーのホームディレクトリ配下にNodeとnpmを丸ごと持っていて、npm install -g の実行先もそこに切り替わります²。
一方 sudo npm install -g は、root権限で動くシステム標準のnpmを使うため、/usr 配下にインストールされます。
どちらも codex というコマンド名で登録されますが、実体もパッケージ管理の系統も別物です。

Nodeのバージョン切り替えやnvm設定の変更、あるいはCodex側の更新処理の失敗によって、以前入っていたnvm側の codex がPATHから見えなくなった。
そこに sudo npm install -g を実行したことで、root管理下の codex が新たに作られて動くようになった、という流れです。

似たような報告は、CodexのGitHub Issueにもあります。
古いstandalone版の ~/.local/bin/codex のシンボリックリンクがPATH上で先に見つかり、実際にnpmで管理している新しいCodexとは別物を指していたという事例です³。
インストール経路が複数混在すると、どのCodexが実際に呼ばれているのか分かりにくくなります。

sudoで一度root管理下に入れた後、通常ユーザーの権限で更新しようとして失敗する事例も報告されています⁴。

3. nvm管理に統一する

sudo なしで運用したかったので、root側のインストールを削除し、nvm配下に入れ直しました。

sudo npm uninstall -g @openai/codex
hash -r
npm install -g @openai/codex
hash -rCode language: Bash (bash)

hash -r は、bashが一度解決したコマンドの場所を覚えているキャッシュを破棄するためのものです⁵。
インストールとアンインストールを同じセッションで連続実行する場合は、はさんでおくと安全です。

確認結果です。

$ command -v codex
/home/chii/.nvm/versions/node/v24.18.0/bin/codex

$ npm config get prefix
/home/chii/.nvm/versions/node/v24.18.0

$ npm list -g --depth=0 | grep codex
├── @openai/codex@0.142.5Code language: Bash (bash)

codex の実体、npmのprefix、グローバルパッケージの一覧、すべてがnvm配下に揃いました。
この状態であれば、今後は npm update -g @openai/codex や npm uninstall -g @openai/codex を通常ユーザーの権限で実行できます。

4. 再発を防ぐには

原因を1文でまとめると、nvm管理のnpmとシステム標準のnpmが両方存在していて、インストール先が途中で切り替わったことです。

対策は、インストール経路を1つに固定することです。
Codex CLI自体、npm・Homebrew・スタンドアロンインストーラ・GitHubリリースの直接ダウンロードなど複数の導入方法が公式に用意されており、これらを切り替えながら使うと混在が起きやすくなります⁶。
nvmで運用するなら sudo npm install -g は使わず、システム標準のnpmとは触れない状態を保ちます。
sudo を使わずに済ませたい場合、そもそも通常ユーザー権限のnpmで EACCES が出ること自体が、システム側のnpmとホームディレクトリ側のnpmが分かれていることのサインです⁷。
別のターミナルで急に codex が見つからなくなったときは、そのシェルでnvmが読み込まれているかを which node と command -v codex で確認すると、切り分けが早くなります。

1. npmはグローバルインストール時、実行ファイルを{prefix}/binにリンクする。この場所がPATHに含まれていないと、パッケージ自体は存在していてもコマンドとして呼び出せない。 – Folders | npm Docs
2. nvmでは、Node.jsのバージョンごとにグローバルパッケージのセットが完全に独立している。あるバージョンで入れたパッケージは、別のバージョンに切り替えると見えなくなる。 – nvm-sh/nvm – Node Version Manager
3. ~/.local/bin/codex（standaloneインストーラ経由の古いバージョン）と/usr/bin/codex（npmグローバルの新しいバージョン）が両方存在し、PATHの並び順で古い方が優先されてしまっていた。 – Remote SSH bootstrap prefers stale ~/.local/bin/codex over newer /usr/bin/codex – GitHub Issue #29045
4. sudo npm install -gでroot所有になったCodexを、codex updateが非sudoのnpm install -gで更新しようとしてEACCESエラーになる。root管理とユーザー管理が混在した状態そのものが、更新やPATH解決を不安定にする。 – Codex updater should handle root-owned npm global installs and multiple install targets more explicitly – GitHub Issue #21897
5. bashはcommand -vなどで解決したコマンドのフルパスを内部のハッシュテーブルに保持する。PATH上のファイル構成をインストールや削除で変えた直後は、このキャッシュが古いままになり、実際には存在しないパスを指し続けることがある。hash -rはこのキャッシュを空にして、次回のコマンド実行時にPATHを再検索させる。 – Bash Reference Manual: Bourne Shell Builtins
6. npm（npm install -g @openai/codex）、Homebrew（brew install --cask codex）、curlによるスタンドアロンインストーラ、GitHubリリースからのバイナリ直接取得が、いずれも公式にサポートされたインストール方法として案内されている。 – @openai/codex – npm
7. Ubuntu 24.04（WSL2）で通常ユーザーのままnpm install -g @openai/codexを実行すると、/usr/lib/node_modulesへの書き込み権限がなくEACCESで失敗する事例がある。この場合の対処はsudoを付けることではなく、nvmやユーザー所有のprefixに切り替えること。 – EACCESS permission issue with npm install -g @openai/codex – GitHub Issue #1480