node: not foundエラーの原因 — Claude Code WSLのnpmインストール

WSLでexec: node: not foundが出る場面

WSL内でnpm install -g @anthropic-ai/claude-codeを実行してインストールした後、claudeと入力すると次のエラーで起動しないことがあります。

exec: node: not found

この症状が出るのは、npm経由でインストールした場合に限られます。ネイティブインストーラー(curl -fsSL https://claude.ai/install.sh | bash)を使っている場合はこの記事の対象外です。原因は主にWSL環境がLinux側のNode.jsではなくWindows側のNode.jsを掴んでいるケースですが、Linux側にNode.js本体が入っていない・PATHが通っていないケースや、nvmのローダーが読み込まれていないケースでも同じエラーになります。

WindowsとWSLを併用する開発環境では、Node.jsをそれぞれの側に別々にインストールしている構成が珍しくありません。Windows側でVS Codeやその他のツールチェーンのために入れたNode.jsと、WSL側でLinuxの開発に使うNode.jsが共存し、どちらが優先されるかはPATHの並び順とインストールのタイミング次第で決まります。この記事では、その優先順位のずれが具体的にどうclaudeの起動を止めるのかを切り分け、恒久的な直し方までまとめます。

なぜWSLでWindows側のNode.jsを掴むのか

WSLは既定でWindows側のPATH環境変数をLinux側に取り込みます。これはcmd.exeやcode.exeなどのWindows実行ファイルをWSLのターミナルから直接呼び出せるようにするための挙動です。Node.jsをWindows側とWSL側の両方にインストールしていると、npmのグローバルインストールがどちらのnpmを実行したかによって、claude起動時に参照されるNode.jsの実体も変わってきます。

WindowsのPATHはWSLのPATHの末尾に追加される仕組みのため、通常はLinux側のコマンドが優先されます。ただしnpm install -gを実行した時点でWindows側のnpmが先に見つかっていた場合、パッケージ自体がWindows側のnpmの管理下でインストールされ、claude起動時に呼び出すNode.jsの実体もWindows側になってしまいます。

原因を切り分ける — whichで実体を確認する

まず、実際にどちらのバイナリを参照しているかを確認します。

which npm
which node

出力が/mnt/c/から始まっている場合はWindows側のバイナリです。/usr/や/home/から始まっていればLinuxディストリビューション側のバイナリです。exec: node: not foundが出る典型的なパターンは、npmは/usr/配下のLinux側を指しているのに、そのnpmでインストールしたパッケージが内部で参照しているNode.jsの実体が見つからない、という食い違いです。

この食い違いが起きるのは、npmが生成する実行用ラッパースクリプトが、Node.jsの実体を実行時にPATHから解決する仕組みだからです。npmコマンド自体は正しくLinux側を指していても、そのラッパーが実行される時点でLinux側にnode本体が存在しない、あるいはPATHに含まれていなければ、exec: node: not foundになります。単にwhich npmの結果だけを見て「Linux側だから大丈夫」と判断せず、which nodeも必ず合わせて確認してください。

直し方 — インストール前の設定とNode.jsの入れ直し

インストール前の時点で対処するなら、プラットフォーム検出を明示的にLinuxへ固定してからインストールします。

npm config set os linux
npm install -g @anthropic-ai/claude-code --force

sudoを付けて実行しないでください。root権限で入れたパッケージは、通常ユーザーのPATH解決やアップデート時の権限と食い違いを起こしやすくなります。管理者権限が無いとインストールできないと感じた場合は、権限不足ではなく別の原因(ディレクトリの所有者がずれている等)を疑ってください。

すでにexec: node: not foundが出ている場合は、Linux側にNode.jsそのものが入っていないか、パスが正しく通っていない状態です。ディストリビューションのパッケージマネージャーで入れ直します。

sudo apt update
sudo apt install -y nodejs npm

Ubuntu・Debian系以外のディストリビューションでは、aptの部分をそのディストリビューションのパッケージマネージャー(Alpine Linuxならapk、Fedoraならdnf)に読み替えます。ディストリビューションの標準リポジトリに含まれるNode.jsのバージョンは新しいとは限らないため、最新のLTS版を使いたい場合は次のnvmを使う方法のほうが確実です。

バージョンを細かく管理したい場合はnvm(Node Version Manager)を使います。次のコマンドでnvm自体をインストールします。

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

インストール後、新しいターミナルを開くか後述のsourceコマンドでnvmを読み込んでから、任意のバージョンのNode.jsを導入します。

nvm install --lts
nvm use --lts

Node.jsを導入したら、あらためてnpm install -g @anthropic-ai/claude-codeを実行します。

nvmを使っているのに切り替わらない場合

WSLとWindowsの両方にnvmを入れている環境では、さらに面倒な競合が起きます。前述のPATH継承の仕組みにより、WSL側でNode.jsのバージョンを切り替えたつもりでも、Windows側のnvmが優先されて反映されないことがあります。原因の多くは、nvmのローダー自体がシェル起動時に読み込まれていないことです。次のコードはターミナルに直接入力するコマンドではなく、~/.bashrcや~/.zshrcの末尾に書き加えるファイルの中身です。

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

nvmの公式インストールスクリプトは通常この3行を自動で追記しますが、手動でnvmをセットアップした場合や、ドットファイルを独自に管理している場合は追記が漏れていることがあります。追記したら.bashrcを保存し、新しいターミナルを開くか後述のsourceコマンドで反映させます。

現在のセッションだけ即座に反映したい場合は次を実行します。

source ~/.nvm/nvm.sh

それでもWindows側のパスが優先される場合は、Linux側のNode.jsパスをPATHの先頭に明示的に追加します。

export PATH="$HOME/.nvm/versions/node/$(node -v)/bin:$PATH"

このコマンドは現在のシェルセッションだけに効くので、次回ターミナルを開いたときも同じ状態にしたい場合は~/.bashrcや~/.zshrcの末尾に同じ行を追記しておきます。Windows側のPATH取り込み自体をappendWindowsPath = falseで無効化する対処は避けてください。WSLからWindowsの実行ファイルを呼び出せなくなり、別の不具合を生みます。Windows開発でNode.jsを使っている場合は、Windows側のNode.jsをアンインストールする対処も避けたほうが安全です。

診断早見表

症状ごとの原因と対処をまとめました。

よくある質問

ネイティブインストーラーに切り替えれば根本的に解決しますか

解決します。ネイティブインストーラーはNode.jsのグローバル環境に依存せず、専用のバイナリを直接配置する仕組みです。npm由来のPATH競合そのものが起きなくなります。既存のnpmパッケージをアンインストールしてから乗り換えられます。

npm config set os linuxはグローバル設定を書き換えますか

npmのユーザー設定に永続的に書き込まれます。他のパッケージのインストールにも影響するため、WSL上でWindows向けのパッケージを扱う予定がある場合は、インストール後に元の設定へ戻すか、そのプロジェクトだけ.npmrcで上書きすることを検討してください。

Windows側のNode.jsを完全にアンインストールしてもいいですか

Windows側の開発でNode.jsを使わないなら問題ありません。ただしWindows側のツールチェーンで使っている場合は、アンインストールするとそちらが動かなくなります。競合を避ける目的なら、アンインストールよりもWSL側のPATHを明示的に優先させる対処のほうが安全です。

which npmの結果が/usr/なのにnode: not foundになるのはなぜですか

npm自体はLinux側を指していても、そのnpmでグローバルインストールしたパッケージが内部でNode.js実行ファイルを見つけられていない状態です。Node.js本体が入っていないか、PATHに含まれるNode.jsのバージョンディレクトリが壊れている可能性があります。which nodeも合わせて確認し、出力がなければNode.js本体から入れ直します。

WSL2ではなくWSL1でもこの問題は起きますか

起きます。この記事で扱っている原因はNode.js/npmのPATH解決の問題で、WSL1・WSL2どちらのバージョンでも同じように発生します。WSL1固有の別の問題(Exec format error)と混同しないよう注意してください。両者はエラーメッセージが異なるので、実際に表示された文言で見分けられます。

Windows側のNode.jsを一切使っていないのに起きるのはなぜですか

Windows側にVS CodeなどのアプリケーションがNode.jsランタイムを内部で同梱していることがあり、それをPATHが拾ってしまうケースがあります。which nodeの出力パスをよく確認し、/mnt/c/配下であれば、それがどのアプリケーションの同梱ランタイムかを一度確認してから対処するとよいでしょう。

まとめ

WSLでのexec: node: not foundは、npm経由のインストールでWindows側のNode.jsやnpmを誤って参照することが原因です。which npmとwhich nodeの出力が/mnt/c/か/usr/かでまず切り分け、Linux側にNode.jsを入れ直すかnvmのローダーを確認します。恒久的にこの種の競合を避けたいなら、ネイティブインストーラーへの乗り換えが根本対処です。WSL2のセットアップ全体はClaude Code WSL2セットアップ、Homebrew・npm・ネイティブの違いはClaude Code Homebrew・npm・ネイティブ導入の比較、その他のインストールエラーはClaude Codeインストールエラーの切り分けチェックリストにまとめています。