Claude Code WSL2セットアップ — パスとNode.js、sandboxの落とし穴
Claude CodeをWSL2で使うときのセットアップ手順と、パスの取り違え・ブラウザーログイン・sandbox有効化まで、WSL特有のつまずきをまとめます。
WSL2で使う前に、まずバージョンを確認する
Claude CodeはWSL2上で動きます。WSL1でも起動は試みますが、公式にはWSL2が前提で、既知の不具合を踏みやすくなります。PowerShellでwsl -l -vを実行すると、ディストリビューションごとのバージョンがVERSION列に表示されます。
WSL1のままclaudeを実行するとcannot execute binary file: Exec format errorが出ることがあります。バイナリのプログラムヘッダーがWSL1のローダーでは扱えない形式になっているために起きる既知の不具合で、GitHub issue #38788で追跡されています。もっとも確実な対処はディストリビューションをWSL2に変換することです。
wsl --set-version <ディストリビューション名> 2どうしてもWSL1のまま使う必要がある場合は、動的リンカ経由でバイナリを呼び出す関数を~/.bashrcに追加する回避策もありますが、恒久対応にはなりません。
WSL2にClaude Codeをインストールする
WSLディストリビューションのターミナルを開き、Linux用のインストールコマンドを実行します。PowerShellやCMDからではなく、必ずWSLのターミナル内で実行します。
curl -fsSL https://claude.ai/install.sh | bashWindowsをネイティブで使うか、WSL2でLinux環境として使うかの判断基準はClaude Code Windowsインストールにまとめています。
npmで入れる場合の注意
npm経由で入れると、WSL側でWindowsのnpmを拾ってしまう事故が起きやすくなります。プラットフォーム検出がずれる場合はnpm config set os linuxを先に実行してからnpm install -g @anthropic-ai/claude-code --forceを実行します(sudoは付けません)。
claude実行時にexec: node: not foundと出る場合も同じ原因で、WindowsのNode.jsを掴んでいます。which npmとwhich nodeの結果が/mnt/c/で始まっていればWindows側のバイナリです。LinuxディストリビューションのパッケージマネージャーかnvmでNode.jsを入れ直します。
nvmをWSLとWindowsの両方に入れている場合、WSLはWindows側のPATHを既定で取り込むため、Windowsのnvmが優先されてバージョン切り替えが効かないことがあります。~/.bashrcや~/.zshrcでnvm.shを読み込んでいるか確認し、それでも解決しなければLinux側のNode.jsパスを明示的に先頭へ追加します。Windows側の実行ファイルをWSLから呼べなくなるため、appendWindowsPathを無効化する回避策は避けてください。
ログイン時にブラウザーが開かない問題
WSL2・SSH・コンテナ内でClaude Codeを起動すると、ブラウザーが別ホストで開くためログイン後のリダイレクトが戻ってきません。サインイン後にブラウザー側へログインコードが表示されるので、ターミナルの入力欄に貼り付ければ認証が完了します。
ブラウザーがそもそも開かない場合は、BROWSER環境変数にWindows側ブラウザーのパスを設定します。
export BROWSER="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
claude貼り付けが効かない場合は、ターミナルのペーストショートカット(Windows Terminalなら右クリックかShift+Insert)を試すか、標準入力からコードを読むclaude auth loginを使います。アカウント作成からログイン方式全体の整理はClaudeログイン完全ガイドを参照してください。
パスをめぐる3つのつまずき
WSL2でよく起きる不具合の多くは、Windows側のファイルシステムとLinux側のファイルシステムを行き来することが原因です。
1つ目は検索結果の抜け漏れです。プロジェクトをWindows側のファイルシステム(/mnt/c/)に置いていると、クロスファイルシステムのディスク読み取り性能が落ち、claude doctorでは検索機能が正常と表示されるのに実際の検索結果が少なくなることがあります。プロジェクトをLinux側のファイルシステム(/home/配下)に置き直すと解消します。
2つ目はNode.jsの取り違えで、前段のnpmインストール時の問題と同じ根が、claude起動後のスクリプト実行や拡張機能でも顔を出すことがあります。3つ目はPATHの優先順位で、WindowsとWSLの両方に同じツールを入れていると、意図せずWindows側が優先されるケースが積み重なります。迷ったらwhichでパスの先頭が/mnt/c/か/usr/か/home/かを都度確認する習慣をつけると切り分けが早くなります。
sandboxモードをWSL2で有効にする
sandboxモードはコマンドごとにファイル書き込みとネットワークアクセスを制限する機能で、WSL2ではLinuxと同じくbubblewrapとsocatの2パッケージに依存します。
sudo apt-get install bubblewrap socatインストール後はClaude Codeを再起動しないと/sandboxパネルが依存パッケージの追加を検知しません。Ubuntu 24.04以降のディストリビューションでは、既定のAppArmorポリシーがbubblewrapの名前空間作成をブロックしていることがあります。sysctl kernel.apparmor_restrict_unprivileged_usernsが1を返す場合は、bwrap専用のAppArmorプロファイルを追加して許可します。
WSL2では、cmd.exeやpowershell.exe、/mnt/c/配下の実行ファイルの起動をWindows側に橋渡しする際にUnixソケットを使います。サンドボックス化されたコマンドからこれらを起動できるかどうかは、Unixソケット関連の設定次第です。すべて許可するならallowAllUnixSockets、特定のコマンドだけサンドボックス対象から外すならexcludedCommandsを使います。個人・チーム・企業のレイヤー別にどこまで許可すべきかはClaude Codeセキュリティ・権限ガイドで扱っています。
Claude Code DesktopのWSLセッションとの違い
ここまではWSLターミナルからCLIを直接起動する方法でした。Claude Code DesktopアプリのCodeタブにも、WSL2ディストリビューション内でセッションを開始する機能があります。並行セッション・サイドチャット・差分レビュー・ブランチとプルリクエストの状態・worktreeはDesktopのWSLセッションでも一通り使えます。「エディタで開く」を選ぶと、Remote - WSL拡張機能経由でVS Codeがそのディストリビューションに接続した状態で開きます。VS Code拡張機能そのものの使い方はClaude Code VS Code拡張機能の使い方にまとめています。
一方で、統合ターミナル・コネクタとプラグイン・セッションのフォーク・ファイルブラウザーペイン・@によるファイル候補は、DesktopのWSLセッションではまだ使えません。これらの機能が必要な作業や、細かい設定をsettings.jsonで直接調整したい場合は、本記事のようにWSLターミナルから直接CLIを起動する方法が向いています。
あるディストリビューションで初めてセッションを開くときは、Claude Codeがその中にセットアップを行うため起動が少し遅くなります。2回目以降は環境ピッカーに最近使ったフォルダがディストリビューションごとに表示されるので、プロジェクトへの再接続はワンクリックで済みます。組織管理下のデバイスでは、管理者の設定次第でWSLセッション自体が使えない場合がある点もCLI版と共通です。
よくある質問
WSL2とネイティブWindowsは同時にインストールできますか
できます。それぞれ独立したインストールで、~/.claude配下の設定やMCPサーバー構成も別々に管理されます。プロジェクトごとに使い分けたい場合は、両方に必要な設定をそれぞれ用意します。
VS Codeとの連携はどう違いますか
Claude Code DesktopのWSLセッションで「エディタで開く」を選ぶとRemote - WSL拡張機能経由でVS Codeが開きます。WSLターミナルからCLIを直接起動する場合は、VS Code拡張機能をWSL側のリモートウィンドウにインストールして使う形になります。
sandboxの依存パッケージはインストールのたびに検知されますか
依存関係のチェックはClaude Code起動時に実行されます。bubblewrapやsocatを追加でインストールした直後は、Claude Codeを再起動してから/sandboxを開くと反映されます。
クリップボードのCtrl+VとAlt+Vはどちらを使えばいいですか
WSLでは既定でCtrl+VとAlt+Vの両方が画像貼り付けに割り当てられているため、使い慣れた方で構いません。ネイティブWindows環境ではAlt+Vが既定の割り当てです。
まとめ
WSL2でのセットアップはcurl -fsSL https://claude.ai/install.sh | bashをWSLターミナル内で実行するだけですが、つまずきの多くはWindows側とLinux側のファイルシステム・Node.js・PATHが混ざることから起きます。プロジェクトはLinux側のファイルシステムに置き、Node.jsやnvmはWSL側で管理し、sandboxモードを使うならbubblewrapとsocatを入れてから再起動する、という順番を守ると迷いにくくなります。ネイティブWindowsとの使い分けはClaude Code Windowsインストール、個別のエラーからの切り分けはClaude Codeでよくあるエラー10選を参照してください。