WSL1 Exec format errorエラーの原因とWSL2移行 — Claude Code
WSL1でclaudeを実行するとExec format errorになるのは既知のバイナリ互換性の問題です。WSL2への移行手順とWSL1のまま使う回避策、その副作用をまとめます。
WSL1でclaudeを実行するとExec format errorが出る
WSLターミナルでclaudeと入力した直後に、次のメッセージが出て起動できない場合があります。
cannot execute binary file: Exec format error公式のトラブルシューティングは、このメッセージをWSL1で起きる既知のバイナリの回帰として扱っています。WSL2で同じ表示が出たときは、別の原因を疑う場面です(後半のFAQで扱います)。まず自分がどちらを使っているかを確認します。PowerShellで次を実行すると、ディストリビューションごとのバージョンがVERSION列に出ます。
wsl -l -vVERSIONが1のディストリビューションでclaudeを起動すると、このエラーに当たります。ネイティブインストーラーで入れても、npmで入れても同じです。issue #38788には、npmで2.1.181を入れてもbashが同じExec format errorを返したという報告があります。インストール方法を変えても症状は変わりません。
気づきやすいのは、Windows 10のころから使っているディストリビューションを変換しないまま残している場合や、社内配布のセットアップ手順が古い場合です。本人がWSLのバージョンを意識していないので、claudeを初めて起動した時点で気づきます。
なぜWSL1でExec format errorが起きるのか
原因はClaude Codeのネイティブバイナリ側にあります。プログラムヘッダー(実行ファイルに埋め込まれた、メモリへの読み込み方と実行開始位置を示すメタデータ)が、WSL1のローダーの扱えない形に変わりました。WSL2は軽量な仮想マシン上で本物のLinuxカーネルを動かすので、通常のLinuxバイナリをそのまま読み込めます。WSL1はWindowsカーネル上でLinuxのシステムコールを変換する層で、ELFの読み込みも別の実装です。
具体的な変化について、issueでは利用者が分析を書き込んでいます。2.1.81と2.1.84のセグメントを比べると、後者には約129MBの.bunセクションを含むLOADセグメントが現れ、Bunランタイムの更新で入ったものだろうという見立てです。公式の説明ではなく、利用者の推測として読んでください。
この問題はGitHub issue #38788で追われていました。経過は次のとおりです。
issue #38788の経過
- 2026-03-25報告が立つ
2.1.83でWSL1の起動に失敗し、2.1.81では動いたという報告です。curlインストーラー経由の環境でした。 - 2026-04〜06新しい版でも再現する報告が続く
2.1.113への自動更新後に壊れ、2.1.112へ戻すと動いたという報告があります。6月には2.1.181でも同じエラーが出て、2.1.112へ固定し直した例が書き込まれています。 - 2026-07-31not plannedでクローズ
「長期間更新がないため閉じる」という自動のコメントでクローズされました。修正済みの意味ではありません。
- 2026-09-23ロックされる
クローズ後に動きがなかったため、自動でロックされました。同様の症状は新しいissueとして立てる運用です。
issueの経過は、報告された版の食い違いも示しています。最初の報告は2.1.83、別の報告は2.1.113が境目だと述べており、どこから壊れたかは書き込みからは断定できません。
3月31日には、npmで2.1.88を入れたらエラーが出ないので直ったかもしれない、という書き込みがありました。ただしその後の版でも再発報告が続き、修正を確認した書き込みはクローズまで出ていません。
WSL2へ移行する手順
もっとも確実なのは、対象のディストリビューションをWSL2に変換することです。作業はPowerShellから行います。
WSL1からWSL2への変換
- 1
名前とバージョンを確認する
wsl -l -vを実行し、NAME列の名前を控えます。対象のVERSIONが1であることも見ておきます。 - 2
ターミナルを閉じる
対象のディストリビューションで開いているターミナルをすべて閉じます。
- 3
変換を実行する
ディストリビューション名を指定して、下のコマンドを実行します。対象のディストリビューションがWSL2の形式に変換されます。
- 4
結果を確認して起動する
もう一度
wsl -l -vを実行し、VERSIONが2になったらclaudeを起動します。
wsl --set-version <ディストリビューション名> 2これから追加するディストリビューションも既定でWSL2にしたいときは、既定バージョンを切り替えておきます。
wsl --set-default-version 2会社支給のPCでは、ポリシーでwslコマンドや仮想化機能が止められていることがあります。--set-versionが応答しない、または権限エラーで止まるときは、管理者側の設定が関係している可能性があります。IT部門にWSL2の利用可否と、仮想化機能の有効化を確認してください。
WSL1のまま使う場合の回避策と副作用
WSL1から動かせない事情があるなら、動的リンカーを経由してバイナリを呼ぶ方法があります。WSL1のローダーはclaudeの実行ファイルを直接は読めませんが、ELFインタプリタ(動的リンカー)を明示して起動する分には通ります。公式のトラブルシューティングが示す関数を~/.bashrcに追記します。
claude() {
/lib64/ld-linux-x86-64.so.2 "$(readlink -f "$HOME/.local/bin/claude")" "$@"
}これはファイルに書き足す内容で、ターミナルに直接打つコマンドではありません。$HOME/.local/bin/claudeはネイティブインストーラーの既定の配置先です。npmで入れた場合は、実際の配置先に置き換えます。追記したら読み込み直して確認します。
source ~/.bashrc
claude --versionバージョン番号が返れば、動的リンカー経由の起動は機能しています。それでもExec format errorが出るなら、関数を書いたファイルが実際に使っているシェルの設定ファイルかを確認します。zshなら~/.zshrcに同じ関数を足します。
issueには、この関数に関する利用者の報告が2件あります。いずれも公式の手順ではなく、1人の書き込みを根拠にしている点に注意してください。
- fnmなどでパスが
$HOME/.local/binではない環境では、$(whence -p claude)でパスを引く形に書き換えて動いたという報告です(zsh向けの書き方です) - 動的リンカー経由で起動すると、Claude Code内のgrep・find・rgのツール呼び出しが「
-Gを共有ライブラリとして読めない」というエラーで失敗するという報告です。/proc/self/exeがリンカー自体を指し、同梱の検索ツールがリンカーに引数を渡す形になるのが原因だと、書き込んだ本人が説明しています
2つ目の報告が本当にあなたの環境で再現するかは、この記事では確認できていません。回避策で起動しても、ファイル検索系の動作が不安定なら、WSL2への変換が現実的な出口です。
まだclaudeが入っていない環境では、インストーラー自体が同じエラーで止まります。issueには、curlで2.1.90を入れようとしてclaude-2.1.90-linux-x64の実行に失敗した報告や、そもそも新規インストールができないという報告があります。回避した利用者は、インストーラーが落ちるまで走らせたあと、展開済みのパッケージを/lib64/ld-linux-x86-64.so.2経由でinstall付きで実行したと書いています。これも利用者の書き込みで、公式の手順ではありません。
WSL1とWSL2、Claude Codeでどちらを選ぶか
WSL1とWSL2の違い
WSL1
Windowsカーネル上でLinuxのシステムコールを変換します。公式のsetupページでは、サンドボックスは非対応で、WSL 2が使えない場合の選択肢という扱いです。Exec format errorの当事者でもあります。
WSL2
軽量な仮想マシン上で実際のLinuxカーネルを動かします。サンドボックスに対応し、Exec format errorも出ません。
サンドボックスを有効にしようとしてSandboxing requires WSL2と表示されたら、そのディストリビューションはWSL1です。WSL2へ上げるか、サンドボックスなしで使います。WSL2のサンドボックスはLinuxと同じbubblewrapで動き、bubblewrapとsocatが必要です。
Desktopアプリの場合は選択肢そのものがありません。WSLセッションはWSL 2専用で、WSL 1は非対応です。インストール済みのWSL 2ディストリビューションだけが、アプリ内のWSLの欄に並びます。
WSL2にも弱点があります。ファイルシステムをまたぐとディスク読み取りが遅くなり、検索結果が期待より少なくなることがあります。検索自体は動きますが、claude doctorは検索を正常と表示するため、気づきにくい症状です。プロジェクトはWindows側の/mnt/c/配下ではなく、Linux側の/home/配下に置きます。/mnt/c/に置いたまま変換した場合は、変換後に移す手があります。
移行でつまずきやすい点
wsl --set-versionが、ディストリビューションの使用中を示すエラーで止まることがあります。ターミナルを閉じても消えないなら、wsl --shutdownでWSL全体を一度止めてから再実行します。VS Codeのリモート接続など、バックグラウンドの接続が残っているケースが考えられます。
変換が成功したのにclaudeが同じエラーを返すなら、シェルが別のディストリビューションに繋がっている可能性があります。ターミナルのタイトルやプロンプトで名前を確認し、wsl -l -vの表と照らしてください。Windows Terminalで複数のWSLプロファイルを使っていると起きやすい食い違いです。
ディスクの空きが少ない環境では、変換が途中で止まる可能性があります。変換前に空き容量を確かめておくと安心です。
よくある質問
すでにWSL2を使っているのに同じエラーが出ます
wsl -l -vで、いま接続しているディストリビューションのバージョンを確かめてください。複数を併用していると、ターミナルの接続先とclaudeをインストールした先が食い違うことがあります。バージョンが確かに2なら、バイナリの破損やインストールの不完全終了を疑います。手元のclaude(v2.1.287で確認)にはclaude doctorがあり、ヘルプには「インストールの健全性を確認する。信頼確認なしで現在のディレクトリの設定ファイルを読む。修正まで含めたチェックはセッション内の/doctor」と書かれています。
回避策のあとにアップデートしても大丈夫ですか
関数がreadlink -fでシンボリックリンクの先を引くので、自動更新でclaudeの実体が入れ替わっても、同じ関数のまま新しい版を呼べます。ただし新しい版が別の非互換を持ち込まないことまでは保証されません。issueでも、6月に2.1.181で同じエラーが出た報告があります。
会社支給のPCでwslコマンドが実行できません
管理者ポリシーで仮想化やWSLが制限されている可能性があります。IT部門にWSL2の利用可否を確認してください。制限が外せない場合は、動的リンカー経由の回避策を使い続けるか、WSLを使わないネイティブWindowsでの利用を検討します。後者の入り口はClaude Code Windowsインストールにあります。
まとめ
WSL1のExec format errorはClaude Code側のバイナリ形式の変更が原因で、issueはnot plannedのままクローズされています。待って直る前提では動かず、WSL2へ変換するか、動的リンカー経由の関数で起動するかの二択です。WSL2でのセットアップ全体はClaude Code WSL2セットアップ、その他のインストールエラーはClaude Codeインストールエラーの切り分けチェックリストで扱っています。