autoAllowBashIfSandboxedがシェル展開コマンドで効かなかった不具合とv2.1.139の修正

Claude Codeのサンドボックスには、Bashコマンドの確認プロンプトを省くautoAllowBashIfSandboxedという設定があります。2026年4月から5月にかけて、$USERや$(date)のようなシェル展開を含むコマンドではこの設定が働かず、確認プロンプトが復活する不具合が報告されました(GitHub issue #43713)。原因は構文解析がシェル展開を扱いきれず通常の確認フローへ落ちていた点にあり、v2.1.139で修正されています。

ただし修正後も、書き方によっては確認が残ったという報告が続いています。この記事では不具合の経緯に加えて、いま出ている確認プロンプトが不具合の残りなのか、設計どおりの挙動なのかを切り分ける材料を並べます。

シェル展開を含むコマンドだけ確認が復活していた

最初の報告は2026年4月5日です。v2.1.92(macOS)でsandbox.enabledとautoAllowBashIfSandboxedを両方trueにしたセッションを使い、echo $USERを実行するとContains simple_expansionという理由の確認プロンプトが立ちました。報告者は、約1週間前までは同じ操作が自動承認されていたとも書いています。

ls /tmpやdate; uptimeのような単純なコマンドは従来どおり自動承認されるため、シェル展開を含むコマンドだけが影響を受けていたことになります。

挙動は非対称でした。リテラルな文字列と展開を組み合わせたecho "user is $USER"は自動承認され、変数単体を引用符で囲んだecho "$HOME"だけが確認を求められています。設定は正しくtrueのままなのに、書き方次第で結果が変わる状態でした。

原因はサンドボックス境界ではなく構文解析だった

autoAllowBashIfSandboxedは本来、コマンドがサンドボックスの中に閉じ込められているかどうかを根拠に確認を省く設定です。ところが実際の判定には、コマンドの構文を静的解析して「単純」と分類できたときだけ自動承認するという条件が追加でかかっていました。展開やコマンド置換を含む構文を解析器が扱いきれないと、サンドボックス化そのものの成否とは無関係に確認へ回されていたのです。

報告者はissue内で、解析器が安全性を証明できないというだけの理由でサンドボックスの信頼モデルを弱めるべきではないと指摘しています。サンドボックスが境界として機能している以上、構文が複雑かどうかは確認の要否と無関係だという主張です。

issueのクローズコメントも、この見方を前提にしています。静的解析で安全と証明しきれないコマンドも、v2.1.139以降はサンドボックスを境界として扱い、自動承認に回すという説明です。

実務では無人実行のループが止まる影響が大きかった

go testやpytestのテストコマンドには、一時ディレクトリのパスを$(mktemp -d)のような形で渡すものが多く含まれます。この不具合の下では、編集・テスト・修正を繰り返す無人実行のループが、反復のたびに確認待ちで止まっていました。

報告者によれば、この状態を回避する手段は--dangerously-skip-permissionsで権限システムそのものを無効化することくらいしか残っていませんでした。サンドボックスと自動承認を組み合わせた「安全な無人実行」という運用が、事実上使えなくなっていたという見立てです。

サンドボックス以外の隔離手段に切り替える案も出ましたが、コメントの1つは、こう指摘しています。Dockerコンテナに切り替えると認証まわりが不安定になりmacOS固有の機能が使えなくなる、独自サンドボックスはサプライチェーンリスクが増える、という内容です。

プラグインやスキルの起動自体を止めるケースも報告された

影響は確認プロンプトの増加だけにとどまりませんでした。外部公開されていたcompound-engineeringプラグインは、SKILL.md内で!から始まるバッククォート構文を使い、リポジトリ名をロード時に事前解決していました。この構文が同じ構文解析の制限に引っかかると、Unhandled node type: stringというエラーで権限チェック自体が失敗します。

Bash(git rev-parse:*)のような許可ルールを設定していても、エラーは権限マッチングより前に発生するため、スキルの実行が始まる前に止まっていました。プロンプトが増えるだけでなく、スキルの起動そのものがエラーで止まる副作用もあったことになります。

8月6日には、Macのデスクトップアプリでも似た報告が付きました。SKILL.mdのfrontmatterに書いた前提チェックがContains simple_expansionで拒否され、Skillツールの呼び出しが失敗したという内容です。

"${VAR}"の波括弧付き展開だけ確認が必要になる非対称もあった

変数名を波括弧で囲む"${VAR}"という書き方が、囲まない"$VAR"より確認を必要としやすいという非対称も、5月4日のコメントで報告されました。次の2つはどちらも引用符で囲まれ、単語分割の心配がない同等の書き方です。

# 確認プロンプトが立つ(Contains expansion)
test -n "${MY_VAR}" && echo "set" || true
 
# 自動承認される
test -n "$MY_VAR" && echo "set" || true

防御的な書き方をしたユーザーほど確認が増えるという、意図に反した結果です。v2.1.139のchangelogが挙げているのは$VARと$(cmd)で、波括弧付きの書き方は名指しされていません。5月13日には、v2.1.139でも${sha}がContains expansionのまま残るという報告が上がっています。

どのバージョンで始まり、いつ直ったか

不具合の混入から修正までの流れは、issueのコメントによれば次の順です。

混入版の特定には食い違いがあります。4月5日のコメントはv2.1.90まで動いていたと書いている一方、4月10日にはv2.1.89で再現するという報告があり、v2.1.87が正常という点だけが一致しています。どちらの報告も、混入はv2.1.88かv2.1.89のどちらかだと示しています。

当時使われていた回避策

修正版が出るまでの間、コメント欄では2つの回避策が共有されていました。どちらも暫定策で、片方には明確な副作用があります。

v2.1.139以降へ上げたあとは、$VARや$(cmd)を含むコマンドで確認が出ないことを確かめてから、どちらの回避策も外すという選択肢があります。hookは外し忘れても動き続けるため、修正後に残しておく理由は薄くなります。

再現報告が続き4か月以上openのままだった

issueは投稿直後、botから類似issue(#31373、#31191)との重複の可能性を指摘され、3日以内にコメントがなければ自動クローズされる状態になりました。コメントが付き続けたため自動クローズの条件を外れ、コメントは最終的に40件に達しています。

5月6日には「もう1か月も経っている」という指摘が付き、その5日後にv2.1.139が出ました。ただしissueのクローズは8月19日で、修正リリースから約3か月後です。クローズコメントは、これが実際の抜けだったと認めています。最新版への更新を求め、まだ確認が出る場合は返信すれば再オープンするとも書いています。

v2.1.139で修正された内容

v2.1.139(2026年5月11日)のchangelogには、「autoAllowBashIfSandboxedが$VARや$(cmd)のようなシェル展開を含むコマンドを自動承認していなかった不具合を修正」と記載されています。

v2.1.139以降では、単純な形の$VARや$(cmd)を含むコマンドが自動承認されるようになりました。書き方によって確認が残る例は、次の節にまとめています。サンドボックスの公式ドキュメントも、構文解析器による制限には触れず、サンドボックス内で動くかどうかを自動承認の基準として説明しています。

修正後も確認が残った型と、その見分け方

v2.1.139の直後から、解消しきれていない書き方の報告がissueに並びました。表示される理由文がContains simple_expansionとは別物になっているものが多く、理由文を見れば同じ原因かどうかを見分けられます。

X=$(cmd)の代入を含む複合コマンドには、Contains shell syntax (variable_assignments) that cannot be statically analyzedという理由文も報告されています。FOO=barの形が引数の中にあるパターンは、別のissue(#58214)に分けて起票されました。

クローズコメントは、ヒアドキュメント、安全でない環境変数のプレフィックス、解決できない対象へのrmは、設計上いまも確認を出すと説明しています。つまり修正後の確認プロンプトは、少なくとも3種類に分かれます。

• 理由文がContains simple_expansionやUnhandled node type: stringで、バージョンがv2.1.139より前の場合は、この記事の不具合そのものです。v2.1.139以降でも、展開がforループやパイプの内側にあるとContains simple_expansionが残る報告があります
• cdとgitの組み合わせやfind -execのように、シェル展開とは別の理由文が出る場合は、別の確認ロジックに当たっています
• denyルールや範囲付きaskルールなど、次の節の条件に当たっている場合は、設計どおりの確認です

手元のバージョンを確認する

不具合の影響を受けているかどうかは、バージョンの確認から始めます。

claude --version
claude update --help

claude updateとclaude installは別のコマンドです。claude installは[target]にstable・latest・具体的なバージョンを取り、--forceで既存のインストール上にも入れ直せます。これまでこの不具合を意識していなくても、古いバージョンを使い続けていれば同じ現象に遭遇する可能性があります。

修正後も確認が出る場合に見分けたい条件

v2.1.139以降でBashコマンドに確認プロンプトが出た場合、不具合ではなく、autoAllowBashIfSandboxedが元々スキップしない条件に該当している可能性があります。サンドボックスのドキュメントは、自動承認モードでも次の4つが残ると定めています。

条件の詳細はautoAllowBashIfSandboxedの記事にまとめています。

設定そのものが原因という場合もあります。autoAllowBashIfSandboxedの既定値はtrueで、falseにするとサンドボックス内のコマンドも通常の権限フローを通り、/sandboxのModeタブでは「regular permissions」と呼ばれます。settings-referenceには、CLAUDE_CODE_SUBPROCESS_ENV_SCRUBを設定すると自動承認が無効になるという記載もあります。サンドボックスのドキュメントでは、strict sandbox modeで!で打ったコマンドも含め、これを設定したLinuxセッションの全コマンドがサンドボックス内で実行されると説明されています。

サンドボックスの自動承認とは別に、Claude Codeにはauto modeという確認省略の仕組みもあります。こちらは境界ではなく分類器の判定に基づく仕組みで、全shellコマンドを審査対象にするautoMode.classifyAllShellという設定もあります。auto modeではサンドボックス内のコマンドも、サーバー側の分類器によるレビューを受けます。境界に頼るか判定に頼るかで前提が異なるため、確認が出る原因を切り分けるときはどちらの仕組みが働いているかも合わせて見る必要があります。詳しくはautoMode.classifyAllShellの記事で扱っています。

まとめ

autoAllowBashIfSandboxedがシェル展開を含むコマンドで機能しなかった不具合は、issue #43713として2026年4月に報告され、v2.1.139で修正されました。確認が出たときは、まずclaude --versionでv2.1.139以降かを見て、次に理由文を手がかりに不具合の残りか別の判定かを分けます。