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

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

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

最初の報告は2026年4月5日です。sandbox.enabledとautoAllowBashIfSandboxedを両方trueにしたセッションで、echo $USERを実行するとContains simple_expansionという理由の確認プロンプトが立ちました。

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

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

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

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

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

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

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

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

サンドボックス以外の隔離手段に切り替える案も出ましたが、コメント欄の反応は消極的でした。Dockerコンテナに切り替えると認証まわりが不安定になりmacOS固有の機能が使えなくなる、独自サンドボックスはサプライチェーンリスクが増えるといった指摘があり、どちらも代替として選びにくいという評価です。

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

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

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

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

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

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

前者は波括弧付きの展開が原因で確認プロンプトが立ち、後者は同じ内容でも自動承認されました。防御的な書き方をしたユーザーほど確認が増えるという、意図に反した結果です。公式のv2.1.139修正は$VARと$(cmd)の解消を明記していますが、この波括弧付きの書き方への言及はありません。

影響を受けたバージョンの範囲

Homebrewのclaude-code安定版キャスクでは、v2.1.89の時点ですでに再現することが報告されました。一方でv2.1.87では再現しなかったため、混入した版はv2.1.88かv2.1.89のどちらかに絞り込まれましたが、それ以上の特定には至っていません。LinuxとmacOSの両方で再現が報告されており、プラットフォーム限定の不具合ではありませんでした。

当時使われていた回避策

修正版が出るまでの間、コメント欄では2つの回避策が共有されていました。1つはPreToolUsehookでdangerouslyDisableSandboxパラメータの有無を見て、サンドボックス化されたコマンドだけを明示的に許可する方法です。hookの書き方はPreToolUse hookの記事にまとめています。もう1つは自動更新を止めて、修正前のv2.1.87へダウングレードする方法でした。

どちらも暫定策です。hookはサンドボックスが無効なセッションで同じ設定を使い回すと、確認なしにコマンドを実行してしまう危険があると報告者自身が注記していました。ダウングレードは自動更新も止めるため、この不具合以外の修正や新機能も受け取れなくなります。v2.1.139以降へアップグレードしたあとは、$VARや$(cmd)を含むコマンドで確認プロンプトが出なくなったことを確かめてから、どちらの回避策も外すという選択肢があります。

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

issueは投稿直後、botから類似issue(#31373、#31191)との重複の可能性を指摘され、3日以内にコメントがなければ自動クローズされる状態になりました。複数のユーザーが再現報告で応じたため自動クローズは避けられ、その後も1か月にわたって新しい再現報告が寄せられ続けました。最後のコメントは2026年5月6日付けで、「もう1か月も経っている」という指摘です。その5日後にリリースされたv2.1.139のchangelogに、この不具合の修正が記載されています。

v2.1.139で修正された内容

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

v2.1.139以降のバージョンでは、$VARや$(cmd)を含むコマンドが自動承認されるようになりました。現在の公式ドキュメントにも、構文解析器による制限は記載されておらず、サンドボックス化できるかどうかが確認を省くかどうかの基準として説明されています。ただし{a,b,c}のブレース展開や"${VAR}"の波括弧付き展開まで解消されたかは、公式の文言からは確認できません(下記Callout参照)。

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

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

claude --version

表示されたバージョンがv2.1.139より前で、かつ自動更新を止める設定を入れていないか確認します。DISABLE_AUTOUPDATER環境変数やclaude installでの固定バージョン指定が残っていると、修正版へ自動では上がりません。これまでこの不具合を意識していなくても、古いバージョンを使い続けていれば同じ現象に遭遇する可能性があります。

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

v2.1.139以降でBashコマンドに確認プロンプトが出た場合、それはこの不具合ではなく、autoAllowBashIfSandboxedが元々スキップしない条件に該当している可能性があります。明示的なdenyルール、rm/rmdirが重要パスを対象にする場合、Bash(git push *)のような範囲付きaskルール、planモード中の裸のBashaskルールの4つです。条件の詳細はautoAllowBashIfSandboxedの記事にまとめています。

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

まとめ

autoAllowBashIfSandboxedがシェル展開を含むコマンドで機能しなかった不具合は、issue #43713として2026年4月に報告され、v2.1.139で修正されました。古いバージョンを固定していたり自動更新を止めていたりする環境では、まずclaude --versionで手元の状態を確認するのが確実です。修正後も確認プロンプトが出る場合は、不具合ではなく元々の4条件に該当していないかを見分けます。原因が切り分けられれば、無人実行のループを安心して回せる状態に戻せます。