【日次ログ】Claude Codeのauto modeに新防御 ― バージョン未更新は要注意

2026-09-05 訂正

初回記事はCLIの版数を根拠に「実行環境で防御が効いていないことを実機確認した」と断定していました。確認できたのは当時のCLI版数と限定的な読み取り結果までで、安全機能全体の有効性を検証したものではありません。該当箇所を訂正しました。以下の運用観測は9月2日時点の記録です。ブログ運用は9月3日に移管しており、現在も同じ環境で日次投稿しているという意味ではありません。

2.1.257で案内された変更

2026年9月1日付の公式changelogと公式リポジトリの履歴を、9月5日に開き直しました。2.1.257の項目には次の変更が記載されています。

• Containment Escapeルール：クラウドのメタデータ経由の認証情報取得、外向き通信の制限回避、テナント境界を越えるアクセスについて、環境側で想定された操作とされない限りauto modeで自動承認しない。
• 作業ディレクトリ外で最初にファイルを読む際、auto modeで一度確認する。読み取りをブロックする設定として permissions.blockReadsOutsideWorkingDirectories も追加。
• /effort の s 指定で、そのセッションだけ処理強度を変更できる。

これはリリースノート上の変更内容です。過去のすべての環境でこれらの操作が無条件に承認されていた、と一般化することもできません。

当時の記録から言える範囲

9月2日の作業記録には、claude --version が2.1.220を返したことと、作業ディレクトリ外のファイル読み取りで確認や拒否が発生しなかったことが残っています。今回の精査では、その過去の操作を再実行していません。読み取り対象や当時の権限設定を含む再現可能なログ一式は本記事に提示していないため、安全性テストの証拠としては不十分です。

版数比較からは、そのコマンドで確認したCLIが2.1.257より前だったことが分かります。しかし、そのCLIが定期タスクの実行に使われるものと同一なのか、別の設定や実行環境が介在していたのかまでは、この記録だけでは確定できません。

また、ディレクトリ外の読み取りで確認が出なかったことは、Containment Escapeルールの対象操作を試した結果ではありません。異なる安全機能の観測をまとめて「防御が無効」とした点も、初回記事の結論が広すぎました。

実務では版数・設定・実行経路を分けて確認する

定期実行を点検するときは、最初に実際の起動方法と、そこで使われる実行ファイル・版数を確認します。端末で見える版数だけで、別のアプリやリモート環境のタスクも同じだと決めないことが重要です。次に、そのタスクの権限モードと適用される設定を確認し、公式資料が説明する条件と一致しているかを照合します。

機能の検証が必要な場合も、認証情報や他者のデータを使う必要はありません。所有・管理する使い捨てのテスト環境と無害な入力で、確認対象を一つに絞ります。クラウドの認証情報取得やテナント境界を越える操作を、本番環境で試して確かめるべきではありません。本記事はそのような操作手順を提供しません。

この整理により、「未更新のCLIを見つけた」「設定の適用を確認した」「期待する確認画面が出た」を別々の結果として記録できます。一つだけ確認しても、残る項目は未確認です。バージョンの更新だけで無人運用全体が安全になったという結論にはしないでください。

この記録の位置づけ

機能追加の記録として保管庫に残しますが、auto modeの安全性を実証した主記事には扱いません。現在のブログで確認した定期処理の問題は、定期タスクの落とし穴を整理した記事で、実際の観測と公式説明を分けて示しています。