Claude Codeのbwrap execvp /bin/bashエラーがmerged-usrで出る原因
merged-usrのLinuxやWSL2で、sandboxを有効にすると全Bashコマンドがbwrap: execvp /bin/bashで止まります。報告されている原因と、取れる回避策を並べます。
DebianやUbuntu、Arch、そしてそれらを載せたWSL2でClaude Codeのsandboxを有効にすると、echo helloのような単純なコマンドまで次のエラーで止まることがあります。
bwrap: execvp /bin/bash: No such file or directory/bin/bashはホストに実在するのに「No such file or directory」と言われるのが特徴です。GitHub issue #99680が2026年10月5日に起票され、openのままです。ここでは症状の見分け方、報告されている原因の読み方、sandboxを外さずに済ませたい人が取れる選択肢を順に並べます。
「/bin/bashが無い」と言われる症状の見分け方
#99680の報告者の環境は、Claude Code 2.1.289、Debian GNU/Linux 13(trixie)のWSL2、bubblewrap 0.12.0です。sandboxが有効だと、Bashツールの呼び出しはコマンドの中身に関係なく毎回失敗します。
次の3点が揃うなら、この記事の症状です。
- メッセージが
bwrap: execvp /bin/bash: No such file or directoryである which bwrapもbwrap --versionも、sandbox経由のBashツールで同じエラーになる/bin、/lib、/lib64、/sbinがusr/*へのシンボリックリンクになっている
3つ目はホストの端末で確かめられます。
ls -ld /bin /lib /lib64 /sbin
readlink -f /bin/bash各行が/bin -> usr/binのようなリンクとして表示されるなら、merged-usrです。issueはこの配置を、Debian 12以降、Ubuntu 23.04以降、Archの既定として挙げています。Pop!_OSの利用者も、同じ現象を経験しているとコメントしています。
同じ根を持つ4件の報告と、症状の違い
#99680は単独の不具合報告ではなく、過去の報告をまとめ直した形です。本文は、先行する4件を次のように整理しています。
| issue | 環境 | 症状 | 状態 |
|---|---|---|---|
| #41863 | 環境Ubuntu 24.04、Claude Code 2.1.89 | 症状execvp /bin/bashが失敗する | 状態not plannedで閉鎖 |
| #69583 | 環境WSL2、Ubuntu 22.04、bubblewrap 0.6.1 | 症状同上。原因を診断し修正案も提示 | 状態重複として閉鎖 |
| #88059 | 環境Debian trixie、2.1.232以降 | 症状Can't mount tmpfs on /newroot/bin | 状態not plannedで閉鎖 |
| #64799 | 環境Arch Linux | 症状Can't mount tmpfs on /newroot/lib64 | 状態open |
エラー文が2種類あることに注意してください。execvpで止まるのはコマンドの起動時、Can't mount tmpfs on /newroot/...で止まるのはsandboxのマウント設定の段階です。#88059の報告者は、2.1.229では動いていた同じ環境が2.1.232以降で壊れたと書いています。#99680の起票者自身は、回帰かどうかは分からないと答えています。
たがいに関連はしているものの、同じ修正で全部が直るとは限りません。自分の画面のメッセージがどちらの型かを、まず見てください。
なぜ起きるのか — #69583の診断
原因は#69583の診断が最も具体的です。bwrapはsandbox内の/usrをバインドしますが、merged-usrが前提にしている/bin -> usr/bin、/lib -> usr/lib、/lib64 -> usr/lib64の互換シンボリックリンクを、新しいルートの中に作りません。
動的リンクされた実行ファイルは、ELFインタプリタをフルパスで要求します。たとえば/lib64/ld-linux-x86-64.so.2です。このパスがsandbox内で解決できないと、execvpはENOENTを返します。メッセージに出る「No such file」は、/bin/bash本体ではなくローダーの欠落を指している、というのが診断の中身です。
#69583はWSL2のUbuntu 22.04で、bwrapを手で呼んで切り分けています。
| 手元の再現 | 結果 |
|---|---|
--ro-bind /usr /usrだけで/usr/bin/bashを起動 | 結果失敗(execvp /usr/bin/bash) |
上に--symlink usr/lib64 /lib64と--symlink usr/lib /libを足す | 結果成功 |
--ro-bind / /でルート全体を束ねる | 結果成功(シンボリックリンクが保たれる) |
別の手がかりもあります。#69583ではSHELL=/usr/bin/bashにすると、エラーの対象が/usr/bin/bashに変わるだけで失敗は続きました。$SHELLは参照されているので、問題はシェルのパスではなくローダー側にある、という裏付けです。
ただし、これはClaude Code内部の動作の確定情報ではありません。実際にClaude Codeがbwrapへ渡す引数は、issueの報告者による観察と推定です。Claude Code側の修正方針は、issueに示されていません。
issueが提案している修正の方向
#99680は、Claude Code側で次のどちらかを取ることを提案しています。
- merged-usrを検出し(ホストの
/binなどが/usr配下に解決するシンボリックリンクなら)、--symlink usr/bin /bin、--symlink usr/lib /lib、--symlink usr/lib64 /lib64、--symlink usr/sbin /sbinをbwrapの引数に足す - #88059の提案に沿い、シンボリックリンクを実体のパスに解決してから、許可・拒否のマウント一覧を組む
利用者側の設定では、これらを再現できません。bwrapに渡す引数を足すキーは、設定リファレンスのsandbox設定に見当たりません。
回避策は2つだけ — どちらも隔離を手放す
#99680が挙げる回避策は、次の2つだけです。
sandbox.enabledをfalseにする。隔離そのものがなくなる- 失敗するたびに
dangerouslyDisableSandbox: trueの再試行を承認する。コマンドごとに隔離を外すことになる
issue本文は、後者が「バイパスの確認を反射的にクリックする習慣」を生む点を問題にしています。
sandbox.enabledをfalseにする
{
"sandbox": {
"enabled": false
}
}設定の置き場所とenabledの意味は、sandbox.enabledの解説にあります。外すと、Bashコマンドは隔離なしで動きます。sandboxに頼っていたautoAllowBashIfSandboxedの自動承認も、前提が消える点に注意してください。
再試行を承認する場合の見え方
公式のsandbox解説によると、sandbox内で失敗したコマンドをClaudeがdangerouslyDisableSandbox付きで再試行することがあります。手動モードとacceptEditsモードでは、「Bash command (unsandboxed)」という題の確認が出ます。今回の症状ではすべてのコマンドが失敗するので、承認が毎回必要になる計算です。
この再試行を管理設定で禁じている組織では、事情が変わります。allowUnsandboxedCommands: falseのもとでは、dangerouslyDisableSandboxは無視され、再試行の逃げ道そのものがなくなります。そのうえ全コマンドが失敗するので、Bashが使えなくなります。仕組みはallowUnsandboxedCommandsの解説に詳しいです。
bwrapPathは効くのか
「bwrapPathで直る」という見立てを目にするかもしれません。結論から言うと、#99680にその記述はありません。
sandbox.bwrapPathは、PATHの外にあるbubblewrapを指すための管理設定です。設定リファレンスの表では、設定できる場所が管理設定(Managed)だけになっています。指せるのは別のバイナリの場所であって、bwrapに渡すマウント設定やシンボリックリンクは変わりません。merged-usrの症状は、どのbwrapバイナリを使うかではなく、新しいルートの組み立て方に起因するという診断です。
別のbwrapを置いても、原理的には同じ症状が出る、と読むのが筋です。もちろん、バージョンの違うbwrapで挙動が変わるかは、報告がないので不明です。bwrapPathの使いどころはenableWeakerNestedSandboxとbwrapPathの記事が扱っています。
同じ理由で、enableWeakerNestedSandboxも効きません。#99680は、関連する#64799の報告をもとに、この設定がこの種のバグを回避できないと書いています。/procのマウントの問題とは別の層の話です。
隔離を残したい人が使える確認の手順
直接の修正は無いので、次のどれに当たるかを切り分けるのが現実的です。
症状別の切り分け
- 1
エラー文を読む
execvp /bin/bashなら今回の症状です。Can't mount tmpfs on /newroot/...なら#88059型で、同じ根の別の現れ方です。 - 2
merged-usrかを確かめる
ls -ld /bin /lib /lib64 /sbinの結果がシンボリックリンクなら、報告と同じ配置です。リンクでない(古い非merged-usr構成)なら、別の原因を疑います。 - 3
別のbwrapエラーと混同しない
NixOS上の
Can't create fileはNixOSのbwrapエラー、unshareのEINVALはsandbox-unshare-einvalの領分です。原因が別なので、対処も違います。 - 4
待つ間の運用を決める
issueはopenのままです。
sandbox.enabled: falseにするか、個別に再試行を承認するかを、扱うリポジトリの重要度で決めます。
運用で気をつけたい2点
sandboxが起動できない場合の既定動作にも注意が必要です。公式のsandbox解説では、依存の欠落やプラットフォーム非対応でsandboxを起動できないとき、Claude Codeは隔離なしでコマンドを実行します。sandbox.failIfUnavailableをtrueにすると、起動時に終了させられます。failIfUnavailableの記事に設定の詳細があります。
ただし今回の症状は、bwrap自体は存在し、コマンドごとの実行で失敗するタイプです。依存の欠落とは扱いが異なる可能性があります。failIfUnavailableを管理設定でtrueにした環境でmerged-usrに当たったとき、どう振る舞うかは、#99680には書かれていません。
もう1点は、issueの寿命です。#99680にはduplicateのラベルが付いており、コメントでは「14日のstale期間のたびに親指のリアクションかコメントが要る」と指摘されています。過去の#41863と#88059は修正されないまま閉じられました。同じ症状に遭う人は、openのissueに状況を足すのが、修正を前に進める手段になります。
まとめ
bwrap: execvp /bin/bash: No such file or directoryは、merged-usrの互換シンボリックリンクがsandbox内に作られない、という診断が出ている問題です。利用者の設定で直す手段は見つかっておらず、取れるのはsandboxを外すか、コマンドごとに再試行を承認するかの2択です。bwrapPathとenableWeakerNestedSandboxは、この症状の回避策としては報告されていません。