許可の抜け道を塞いだ修正の一覧（2026年5月〜11月）と、運用での確かめ方

先に結論：一覧から読める2つのこと

1. 抜け道は命令の書き方に隠れていた：変数の代入を挟む、引用符で囲んだ語を含める、作り込んだコマンドで一部を検査から隠す、といった形で、許可のルールが想定通りに働かなかった例が記載されています。ルールを書いた本人が正しいと思っていても、判定の側に穴があり得ます。
2. 修正されるのは「後から」：どの行も、不具合が見つかって直った記録です。ルールを入れた時点で安全だったことの証明にはなりません。

日付順の一覧

運用での確かめ方：許可ルールの検査を自作する

許可ルールを入れたら、止まるべきものが止まるかを自分で確かめる検査を作っておきます。やり方は単純です。

1. 止めたい命令の一覧を作る（運用中のフォルダの削除、範囲外の書き込み、強制的なgit操作など）。
2. 各命令を、書き方を変えて3通り以上用意する（変数に入れる、引用符を付ける、末尾にスラッシュを付ける）。
3. 空のテスト用フォルダで流し、止まったか／通ったかを表に残す。
4. 版が上がるたびに、同じ表を埋め直す。

通ってしまった行が出たら、ルールの書き方ではなく、使っている版を疑います。この表が、先の一覧のような記載との突き合わせ材料にもなります。

この面で確かめていないこと

• 各不具合を再現してはいません。危険な命令を実際の運用環境に向けて試すことはしていません。
• 修正前の版で実際に被害が出たかどうか。
• 変更履歴の全体を見たわけではなく、取得できた範囲で拾っています。

秘密情報まわりの修正をどう読むか

一覧には、許可の回避とは別に、秘密情報の扱いに関する行があります。6月2日（2.1.161）にはMCPの操作が秘密を端末に出力していた不具合、8月17日（2.1.234）にはMCPの診断出力で秘密が漏れる不具合を含む24件の修正が記載されています。5月（2.1.153）には、APIゲートウェイにOAuthの認証情報が渡っていた不具合の修正も載っています。

これらに共通するのは、秘密がファイルではなく「画面の出力」に出る点です。端末の記録、スクリーンショット、診断のコピーを他人に渡したり、サポートに送ったりするときが危ない場面です。対処の基本は2つです。

1. 診断の出力やログを共有する前に、キーやトークンらしい文字列を検索して伏せる。
2. 認証情報は、設定ファイルに直接書かず、環境変数や専用の保管場所に置く。

どの版で漏れていたか、実際に漏れた人がいたかは、ここでは確かめていません。公式の記載は「修正した」までです。

破壊的な操作に関する記載の読み方

6月19日（2.1.183）のオートモードの変更や、8月4日（2.1.222）の作業ツリーの修正は、消せないものを消す操作をどこで止めるかの話です。後者は、作業ツリーを分けて作業させていても、本体のチェックアウトに対して破壊的なgit操作が実行できてしまった、という内容で修正されたと記載されています。

作業ツリーは「安全な作業場」という前提で使われがちですが、その前提が崩れた期間があったことになります。その期間に作業ツリー運用をしていた人は、本体側のコミット履歴に覚えのない変更がないか、一度確かめる価値があります。履歴が正常なら、何もする必要はありません。確かめるのは数分で済みます。

出典と確認日

• Claude Code 公式 変更履歴：https://code.claude.com/docs/en/changelog （2026年11月7日に確認）

編集：ちんあなご編集部。記載は公式ページの内容を自分の文で書き直したもので、原文の引用ではありません。

よくある質問

次に読むページ