WSL1 Exec format errorエラーの原因とWSL2移行 — Claude Code

WSL1でclaudeを実行するとExec format errorが出る

WSLターミナルでclaudeと入力した直後に、次のメッセージが出て起動できない場合があります。

cannot execute binary file: Exec format error

この症状が出るのはほぼ確実にWSL1です。WSL2では発生しません。まず自分がどちらを使っているかを確認します。PowerShellを開いて次を実行すると、ディストリビューションごとのバージョンがVERSION列に表示されます。

wsl -l -v

VERSIONが1になっているディストリビューションでclaudeを起動した場合に、このエラーが出ます。ネイティブインストーラーで入れた場合もnpm経由で入れた場合も、配置される実体は同じネイティブバイナリなので、インストール方法を変えても症状は変わりません。

このエラーに気づくきっかけは大きく2通りあります。一つは、以前からWindows 10で使い続けているディストリビューションを、WSL2が主流になった後もアップグレードしないまま使い続けているケースです。もう一つは、社内配布のセットアップ手順やイメージが古く、作成した時点のディストリビューションがWSL1のまま残っているケースです。どちらも本人がWSL1とWSL2の違いを意識していないまま使っていることが多く、claudeを初めて起動したタイミングで初めて気づく、という流れになりがちです。

なぜWSL1でExec format errorが起きるのか

原因はClaude Code側のバイナリ形式の変更です。ある時点からネイティブバイナリのプログラムヘッダーが、WSL1のローダーでは正しく解釈できない形式に変わりました。プログラムヘッダーは、実行ファイルの中に埋め込まれた「このバイナリをどうメモリに読み込み、どう実行を開始するか」を示すメタデータです。WSL2は実質的にLinuxカーネルそのものを軽量な仮想マシン上で動かす仕組みのため、通常のLinuxバイナリが期待するこの読み込み手順をそのまま処理できます。一方のWSL1は、Windowsのカーネル上でLinuxシステムコールをエミュレートする変換層で、実行ファイルの読み込み方式もWSL2とは別物です。

この不整合はAnthropicの既知issueとしてGitHub issue #38788で追跡されています。issueの性質上、修正されるかどうかや時期は公式に明言されていません。現時点での実用的な対処は、後述するWSL2への移行か、ローダーを迂回する回避策のいずれかです。

WSL1はWSL自体の最初の実装で、後発のWSL2よりも導入は簡単でしたが、Linuxカーネルとの互換性は原理的にエミュレーション頼みでした。WSL2が主流になってからは、Windows側の新規インストールで作成するディストリビューションは既定でWSL2になるように変わっていますが、それより前に作成済みのディストリビューションは、明示的に変換しない限りWSL1のまま残ります。Claude Codeに限らず、Linuxカーネルの機能に依存するツール全般でWSL1は互換性の落とし穴になりやすく、Claude CodeのExec format errorはその一例です。

WSL2への移行手順

もっとも確実な対処は、対象ディストリビューションをWSL2に変換することです。PowerShellを管理者権限で開き、対象ディストリビューション名を指定して実行します。

wsl --set-version <ディストリビューション名> 2

ディストリビューション名はwsl -l -vの出力のNAME列で確認できます。変換前に、対象ディストリビューションで開いているターミナルはすべて閉じておくとスムーズです。変換はディストリビューション内のファイルを保持したまま行われますが、ディスクの内容量によっては数分かかることがあります。変換が終わったらwsl -l -vを再実行し、VERSION列が2になっていることを確認してからclaudeを起動します。

今後新しく追加するディストリビューションも既定でWSL2にしたい場合は、次のコマンドで既定バージョンを切り替えておきます。

wsl --set-default-version 2

企業管理下のPCでは、管理者ポリシーでwslコマンドの実行自体やLinux仮想マシン機能の有効化がブロックされていることがあります。wsl --set-versionを実行しても応答がない、または権限エラーで止まる場合は、個人の設定変更では解決できません。社内のIT部門にWSL2の利用可否と、必要であればWindowsの仮想化関連機能(Virtual Machine PlatformやHyper-V)の有効化を確認してください。

WSL1のまま使う場合の回避策

業務都合などでWSL1から動かせない場合は、動的リンカーを経由してバイナリを直接呼び出す回避策があります。WSL1のローダーはバイナリに埋め込まれた実行ファイル形式の解釈に失敗しますが、ELFインタプリタ(動的リンカー)自体を明示的に指定して起動する分には通ります。~/.bashrcに次の関数を追加します。

claude() {
  /lib64/ld-linux-x86-64.so.2 "$(readlink -f "$HOME/.local/bin/claude")" "$@"
}

上のコードは~/.bashrcに書き加えるファイルの中身であり、ターミナルにそのまま入力するコマンドではありません。エディタかnano ~/.bashrcのようなコマンドで開いて末尾に追記します。ネイティブインストーラーの既定の配置先である$HOME/.local/bin/claudeを前提にしているので、npm経由でインストールした場合はパスを実際の配置先に置き換えます。追加したら設定を読み込み直してからclaudeを実行します。

source ~/.bashrc
claude --version

claude --versionがバージョン番号を返せば、動的リンカー経由の呼び出しが機能しています。引き続きExec format errorが出る場合は、関数の登録先が実際に使っているシェル設定ファイルと一致しているか確認してください。既定のシェルがbashではなくzshの場合は、~/.bashrcではなく~/.zshrcに同じ関数を追加します。

この関数はWSL1のローダーが直接扱えないバイナリを、動的リンカー経由で無理やり読み込ませているだけの回避策です。恒久的な修正ではなく、将来のバージョンで別の非互換が出ないことを保証するものでもありません。

WSL1とWSL2の使い分け早見表

WSL1からWSL2への移行を迷う場合の判断材料です。

Claude Codeを使う前提であれば、この表の判断はほぼWSL2一択です。唯一の例外は、Windows側のファイルシステム(/mnt/c/配下)にプロジェクトを置いたまま作業する運用で、ここだけはWSL1のほうがI/Oのオーバーヘッドが小さく感じられることがあります。ただしClaude Code自体はLinux側のファイルシステム(/home/配下)にプロジェクトを置く運用を前提にしているため、この差はほとんどのユーザーにとって実利のある比較にはなりません。

移行でよくあるつまずき

wsl --set-versionの実行中に「別のプロセスがディストリビューションを使用中」といったエラーが出ることがあります。対象ディストリビューションのターミナルをすべて閉じても解消しない場合は、wsl --shutdownでWSLサブシステム全体を一度停止してから再実行します。VS Codeのリモートウィンドウやバックグラウンドで動いているサービスが接続を保持したままになっているケースが典型です。

変換自体は成功したのにclaudeが相変わらずExec format errorを返す場合は、シェルが別のディストリビューションに接続している可能性があります。ターミナルのタイトルバーやプロンプトでディストリビューション名を確認し、wsl -l -vの結果と一致しているか照合してください。Windows Terminalで複数のWSLプロファイルを併用している場合に起きやすいつまずきです。

ディスク容量が逼迫している環境では、変換処理自体が途中で止まることがあります。wsl --set-versionはディストリビューションのディスクイメージを新しい形式に作り直すため、元のディストリビューションと同程度の空き容量を一時的に必要とします。

よくある質問

npm経由でインストールした場合もこの問題は起きますか

起きます。ネイティブインストーラーでもnpm経由でも、最終的に配置されるのは同じネイティブバイナリで、原因はWSL1のローダー側にあります。インストール方法を変えても解決しません。

WSL2に変換すると、それまでのファイルや設定は消えますか

消えません。wsl --set-versionはディストリビューションの実行方式を変換する処理で、中のファイルシステムはそのまま引き継がれます。~/.claude配下の設定やプロジェクトファイルも変換後にそのまま使えます。

WSL1のまま使い続けると今後も別の互換性問題が起きますか

その可能性はあります。issue #38788の対象はExec format errorの発生時点までの互換性問題で、将来のバージョンでバイナリ形式がさらに変わった場合に同じ回避策で通る保証はありません。恒久的に使い続けるなら、WSL2への移行がもっとも安定した選択です。

動的リンカーの回避策を使うと動作に違いは出ますか

起動の仕組みが変わるだけで、Claude Code自体の機能には影響しません。ただしこの回避策はWSL1のローダーの制約を迂回しているだけなので、今後のバージョンで別の非互換に当たった場合は同じ手法が通用しない可能性があります。

wsl --set-versionはどのくらい時間がかかりますか

ディストリビューションのディスク使用量に比例します。数GB程度の一般的な開発環境であれば数分程度で終わることが多いですが、大きなデータを抱えたディストリビューションでは長くかかることがあります。

会社支給のPCでwslコマンドが実行できません

管理者ポリシーで仮想化機能やWSLの利用自体が制限されている可能性があります。個人の権限では解決できないため、IT部門にWSL2の利用可否と必要な機能の有効化を確認してください。制限が解除できない環境では、動的リンカー経由の回避策を使い続けるか、ネイティブWindows環境への切り替えを検討することになります。

すでにWSL2を使っているのに同じエラーが出ます

wsl -l -vで対象ディストリビューションのバージョンを再確認してください。複数のディストリビューションを併用している場合、ターミナルが接続しているディストリビューションと、実際にClaude Codeをインストールしたディストリビューションが食い違っていることがあります。バージョンが確かに2なのに解消しない場合は、この記事とは別の原因(バイナリの破損やインストールの不完全終了)を疑い、claude doctorで診断してください。

まとめ

WSL1でExec format errorが出るのは、Claude Codeのネイティブバイナリのプログラムヘッダーの変更にWSL1のローダーが対応していないことが原因です。wsl -l -vでバージョンを確認し、wsl --set-version <ディストリビューション名> 2でWSL2へ変換するのがもっとも確実な対処です。WSL1のまま使う必要がある場合のみ、動的リンカー経由のラッパー関数を回避策として使います。WSL2でのセットアップ手順全体はClaude Code WSL2セットアップ、ネイティブWindowsとの使い分けはClaude Code Windowsインストール、その他のインストールエラーはClaude Codeインストールエラーの切り分けチェックリストにまとめています。