3 版続けて、同じ種類の修正が入った

結論から言うと、Claude Code は最新版へ上げてください。 v2.1.221 から v2.1.223 にかけて、権限チェックを回避できる不具合の修正が連続して入りました。

判断の軸は単純です。今回直ったのは、承認したつもりの範囲を超えて動きうる 類の不具合です。設定を丁寧に書いているかどうかに関係なく効きます。逆に言えば、権限設定を作り込んでいるチームほど、その設定が想定どおりに効いていない期間があったことになります。

本記事では、攻撃の手口には踏み込みません。運用として何を確認し、どの順で対応するか に絞って整理します。

まずバージョンを確認する

対応の入口は、いま何を使っているかの確認です。手元の版が v2.1.223 以降なら、この記事で挙げた修正はすべて入っています。

確認して、下回っていれば上げる。それだけで今回の話は終わります。 設定を触る必要も、運用を変える必要もありません。

そのうえで、以下は「何が直ったのか」を把握しておきたい人と、組織で配っている管理者向けの内容になります。

何が直ったのか

公式のリリースノートから、権限に関わる項目を抜き出すと次のようになります。

版公開日直った内容 (要約)
v2.1.2218/4zsh の条件式内に隠したコマンドが Bash の権限チェックを通過する
v2.1.2228/4worktree 分離セッションが本体のチェックアウトへ破壊的な git 操作を実行できる
v2.1.2228/4PreToolUse の自動許可フックが、要約・圧縮など裏の処理でツール制限を回避する
v2.1.2238/6承認ダイアログで、コマンドの一部を見えなくできる
v2.1.2238/6ワークフローが動的な読み込みでサンドボックス外のコードを実行できる
v2.1.2238/6エージェント定義の設定が、組織のバイパス無効化ポリシーを無視する

共通しているのは、「見えているもの」と「実際に動くもの」がずれる 点です。承認ダイアログに出た内容を読んで許可したのに、実際にはそれ以外も動きうる。これが権限バイパスの本質です。

注意

権限設定を書いていれば安全、という前提が崩れる種類の不具合です。設定の見直しより先に、バージョンを確認してください。

表示と実体がずれるのがなぜ問題か

Claude Code の安全性は、人が承認する ことで担保されています。危ない操作は止まり、画面に出て、人が読んで許可する。この前提が、設計全体の土台になっています。

その承認画面に出る内容が、実際に動く内容と一致しない場合、人の判断そのものが無効になります。 どれだけ注意深く読んでいても、読んだ内容が実体でなければ意味がありません。

だからこの種の不具合は、機能追加の遅れとは重みが違います。「新機能はまだ要らないから更新しない」という判断はありえますが、この修正には同じ理屈が通りません。

急ぐかどうかは、入力の出どころで決まる

とはいえ、全員が今すぐ手を止めて更新すべきかというと、そこは状況によります。判断の軸は、機能ではなく入力の出どころです。

使い方優先度
Web の内容や外部から届くファイルを読ませる高い
チケットや issue の本文を読ませて作業させる高い
自動化・バックグラウンドで長時間動かしている高い
手元で、自分が書いた指示だけを与えている中程度

上 3 行に当てはまるなら、細工された内容が権限チェックを抜ける経路が、現実的な脅威になります。 外部から届いた文章の中に指示が混ざっている状況は、実際に起こりえます。

いちばん下だけなら、緊急性はそこまで高くありません。それでも次に触るときには上げてください。放置する理由がある種類の修正ではありません。

分離していたはずの作業が本体に届く

修正のなかで、性質が少し違うものが 1 つあります。v2.1.222 の worktree 分離に関するものです。

worktree で作業を分けるのは、本体に影響を与えないため です。試したい変更を隔離し、駄目なら捨てる。この前提で使っている人は多いはずです。

その分離が、破壊的な git 操作に対して効いていませんでした。隔離したつもりの作業が、本体のチェックアウトに届きうる状態だった ということです。修正後は、ファイル編集と Bash を含むすべてのセッション種別に分離が適用されます。

並列で複数のエージェントを動かしている場合、この修正の意味は大きくなります。分離を前提に本数を増やしていたなら、その前提が一部成立していなかったことになります。

管理者が確認すること

組織で使っている場合、確認する項目は 2 つです。

1 つは、バイパス無効化ポリシーを配っているかどうか。配っているなら、v2.1.223 より前のバージョンでは、エージェント定義側の設定によってポリシーが無視される場合がありました。ポリシーの内容を変える必要はありません。 全員のバージョンを上げれば、意図どおりに効きます。

もう 1 つは、現在のバージョンの分布。全員が最新とは限りません。数か月前に入れたまま触っていない人が、たいてい何人かいます。

FIXITFIXIT
ポリシー配ってれば大丈夫じゃないの？
TsukasaTsukasa

逆です。そのポリシーが効かない不具合が含まれていました。

FIXITFIXIT
じゃあ何をすればいい？
TsukasaTsukasa

判断の軸は 1 つで、全員のバージョンです。設定はそのままで構いません。

確認は難しくありません。バージョンを申告してもらうか、各自に更新を促して報告してもらう形で足ります。人数が多いなら、最低バージョンを決めて周知するのが手っ取り早いです。

周知の文面は短くて構いません。「権限まわりの修正が入ったので、この版以上へ上げてください」で足ります。理由を長く書くほど読まれなくなります。 詳しく知りたい人だけがリリースノートを見に行けるように、リンクだけ添えておけば十分です。

外部入力を読ませているなら、更新だけでは足りない

優先度の高いほうに当てはまるチームは、更新に加えてもう 1 段の構えが要ります。今回の修正は既知の穴を塞いだだけで、外部から来た文章に指示が混ざる構造そのものは変わりません。

運用として効くのは、次の 3 つです。

  1. 許可するコマンドを絞る。素の実行を許さず、必要なものだけを列挙する
  2. 読ませる範囲と、実行させる範囲を分ける。調べる作業と、変更を加える作業を同じセッションで混ぜない
  3. 自動で通す設定を減らす。承認を挟む箇所を残しておく

2 番が実務的です。外部の文章を読む作業では、そもそも危険な操作を許可しない という切り分けができます。調査は調査だけ、実装は自分で書いた指示だけ、と分けておけば、細工された内容が実行に届く経路が減ります。

3 番については、今回の修正内容そのものが理由になります。自動で通す仕組みは、それが正しく動いていることを前提にしています。前提が崩れたときに残るのは、人が見ている箇所だけです。

コツ

許可の範囲を絞る作業は、更新より時間がかかります。先にバージョンを上げて穴を塞いでから、腰を据えて取り組んでください。

更新を運用に乗せる

今回のように修正が連続すると、その都度の対応では追いつきません。仕組みにしておく必要があります。

とはいえ、大掛かりなものは要りません。決めるのは 3 つです。

  1. 最低バージョンを決める。これを下回ったら更新する、という線
  2. 見る係を決める。リリースノートの security 関連の行だけを、週に一度確認する
  3. 周知の経路を決める。上げるべきときに、どこへ流すか

2 番が要点です。全員がリリースノートを追う必要はありません。 1 人が見て、権限やセキュリティに関わる行があったときだけ流す。それで今回のような連続修正は拾えます。

更新作業そのものは各自の手元で終わるので、運用として持つべきなのは周知と期限だけです。ここを決めておけば、次に同じことが起きても数分で回ります。

定例に組み込む場合

既存の定例があるなら、そこに 1 行足すのがいちばん続きます。

  • 今週、権限・セキュリティ関連の修正はあったか
  • あった場合、最低バージョンを更新するか
  • 更新するなら、いつまでに

「新機能の紹介」と混ぜないでください。 一緒にすると、新機能の話が長くなってセキュリティの行が流れます。分けておくと、判断が速くなります。

更新して不都合が出たら

更新を渋る理由として多いのが、「上げたら動かなくなるかもしれない」という懸念です。実際、版が上がれば挙動は変わります。

現実的な進め方は、次のようになります。

状況進め方
個人で使っているそのまま上げてよい。戻す必要が出たら戻す
チームで同じ手順を共有している1 人が先に上げ、問題が無いか確認してから広げる
自動化に組み込んでいる自動化の環境で先に検証してから、手元を上げる

いちばん下だけ注意が要ります。 自動化に組み込んでいる場合、更新で挙動が変わると気づきにくい形で結果が変わります。ここは検証してから上げてください。

とはいえ、上 2 つに当てはまる大半のケースでは、先に上げて、問題が出たら対処するほうが速く済みます。 検証に時間をかけている間も、穴は開いたままです。

なお、今回の 3 版には権限以外の修正も多く含まれています。セキュリティ修正だけを取り出して当てることはできない ので、まとめて上がる前提で考えてください。

権限設定そのものは、これまでどおりでよい

今回の件で「権限設定を全部見直すべきか」と聞かれることがありますが、その必要はありません。 直ったのはチェックの実装であって、設定の考え方ではありません。

ただし、更新を機に一度だけ確認しておくと良い点があります。

バイパス系の設定を、便宜的に緩めたまま戻していないか。 一時的に許可を広げて、そのままになっている環境は珍しくありません。今回の修正でチェックが正しく効くようになったぶん、緩めた設定はより正確に「緩いまま」機能します。

設定の考え方そのものは Claude Code の権限と settings.json 設計 に整理しています。組織全体での配り方は Claude Code 全社導入 完全ガイド を参照してください。

経営側にどう説明するか

導入を承認した側から見ると、この手の報せは「危ないものを入れたのでは」という印象になりがちです。説明の仕方で受け取られ方が変わります。

伝えるべきは次の 3 点だと考えます。

修正が出ていること自体は、悪い報せではありません。 権限チェックが仕組みとして存在し、そこに見つかった穴が塞がれています。チェックの仕組みが無い道具のほうが、報せが出ないぶん危険です。

当社側でやることは更新です。 設計や運用の作り直しではありません。所要は各自数分で、費用も発生しません。

残るリスクは、人が承認を読まなくなることです。 ここは道具ではなく運用の問題なので、引き続き見ていきます。

3 点目まで一緒に伝えておくと、次に同種の報せが出たときの話が早くなります。「また脆弱性か」ではなく「更新の話だな」に変わります。

この種の修正は今後も出る

エージェントが実際にコマンドを実行する以上、権限まわりの不具合は今後も出ます。 珍しい出来事として扱うより、定期的に起きるものとして構えを作るほうが現実的です。

構えとして持っておくべきは、次の 3 つだと考えます。

構え理由
更新を早く適用できる状態修正が出てから当てるまでが短いほど露出が短い
外部入力の扱いを意識する攻撃の起点は、たいてい外から来た文章
承認を形骸化させない読まずに通す運用だと、修正が入っても意味がない

3 行目が最後の砦です。表示と実体が一致していても、読まずに承認していれば同じことです。 仕組みの修正は前提を整えるだけで、判断そのものは人が持ち続けます。

承認が形骸化する原因は、たいてい量です。承認を求められる回数が多すぎると、内容を読まずに通すようになります。許可の範囲を適切に絞ることは、承認の回数を減らし、残った承認を読ませるための施策でもあります。 安全のために全部を止める設計は、結果として何も見られない状態を作ります。

まとめ

  • v2.1.221〜223 で、権限チェックを回避できる不具合の修正が連続した
  • 承認ダイアログの表示と実際に動く内容がずれる類のもので、設定では回避できない
  • 急ぐかどうかは、外部から来た内容を読ませているかで決まる
  • 管理者は、バイパス無効化ポリシーが効かない期間があった前提で全員のバージョンを確認する
  • 最低バージョン・見る係・周知経路の 3 つを決めれば、次回は数分で回る
  • 権限設定の考え方は変えなくてよい。緩めたまま戻し忘れた箇所だけ見ておく
  • 外部の文章を読ませる作業と、変更を加える作業は分けておくと経路が減る