Claude Codeは、ファイル編集やコマンド実行の前に人間の承認を求める仕組み（パーミッションプロンプト）を核に、危険な操作を止める設計になっている。2026年8月4日から6日にかけて公開されたバージョン2.1.221〜2.1.223のchangelogを確認すると、この「承認ダイアログに表示されている内容」自体が実際の動作と食い違いうる、という種類の不具合が複数まとめて修正されていた。公式changelogで内容を直接確認できたので整理する。

何が修正されたか

v2.1.221（8月4日）：zshの条件式でコマンドが隠れる

zshの[[ ]]正規表現条件式を使うと、パーミッションチェックの対象から一部のコマンドを隠して実行できる不具合が修正された。あわせて、クォート文字を含むパスでPowerShellのパス検証が正しく働かない不具合、ワークフロースクリプトが動的なimport()を使ってサンドボックスの外でコードを実行できる不具合も修正されている。

v2.1.222（8月4日）：ワークツリー分離とバックグラウンドタスクの抜け

隔離されたワークツリー（git worktree）で動くセッションやサブエージェントが、隔離されているはずの主チェックアウトに対して破壊的なgitコマンドを実行できてしまう不具合が修正された。ファイル編集・Bash実行の両方、すべてのセッション種別に分離が適用されるよう修正されている。もう一つ、PreToolUseのオート許可フックが、要約やコンパクション、リネームといったバックグラウンドのエージェントタスクに対してはツール制限をバイパスしてしまう不具合も修正された。

v2.1.223（8月6日）：承認画面そのものを欺く手口

続く2.1.223では、さらに4件の権限関連の修正が入った。

最後の1件は、個々の開発者の設定ではなく組織のポリシーそのものが無視されていたという点で、ガバナンス上の抜けだったと言える。

何が問題だったのか

これらに共通するのは、「承認するかどうかを判断する材料」自体が信頼できなくなる、という種類の不具合だという点だ。パーミッションプロンプトは、危険な操作を止める最後の砦として設計されている。しかし今回のように、コマンドの一部を隠したり、隔離されているはずの領域からの操作を通してしまったりすると、承認した本人が意図した範囲と、実際に実行される範囲がずれてしまう。しかも表示上は何も異常が見えないため、当事者が気づく手段がない。

これはこのブログで以前取り上げたauto modeの分類器によるブロック機能とは別の層の話だ。分類器は「この操作を自動承認していいか」を判断する仕組みだが、今回の不具合はその手前の「人間に何を見せて、何を承認させるか」という土台の部分に関わる。土台が崩れていると、その上に積んだ分類器やルールがどれだけ精緻でも意味を持たない。

中小企業が実務で押さえるべきこと

  1. Claude Codeのバージョンは定期的に更新する：今回のような権限関連の修正は、変更履歴を読まなければ「何が直ったか」も分からない。CIやローカル環境のバージョンを固定しっぱなしにせず、更新の確認を運用に組み込む
  2. 組織ポリシー（bypassPermissionsの無効化など）は「設定した後」も検証する：設定した時点では正しく機能していても、後のバージョンで抜けが生じることがある。定期的に想定通り効いているか確認する
  3. ワークツリー分離や隔離実行を「絶対の壁」として過信しない：隔離機能自体にも実装上の抜けが見つかり得る。特に本番に近い認証情報や顧客データを扱う環境では、隔離だけに頼らず、そもそも触れられる範囲を狭くする設計と組み合わせる

承認プロンプトは万能ではない、という前提で設計する

Anthropicが数日のうちにこれだけの権限関連の不具合をまとめて修正してきたこと自体は、地道な改善が続いている証拠として評価できる。ただし裏返せば、「承認を求める仕組みがある」という事実だけでは、想定通りに安全が保たれているとは言えないということでもある。ベンダーが用意した承認フローや隔離機構を土台としつつ、どの操作を本当に人間の目でチェックすべきか、どこを構造的に狭めておくべきかを自社の言葉で決めておく——これもハーネスの考え方の一部だ。

自社の運用でどこまでベンダーの既定機能に委ね、どこを自社のルールで固定すべきか整理したい場合は、パイロット・構築のフェーズで一緒に詰められる。まずは30分の無料診断から相談してほしい。