Claude Codeの権限設定は、「禁止リストを厚くする」だけでは守れません。私はhooksでBashコマンドを実行前に検査してブロックする運用を続けてきましたが、直近のアップデートを追うほど、denyは4層あるうちの1層にすぎないと考えるようになりました。この記事では、権限を「渡さない・許す・止める・外側で強制する」の4層に分けて、それぞれの役割と設計の考え方を整理します。
対象読者は、Claude Codeを日常的に使っていて settings.json の permissions を書いたことがある人、そしてエージェントに定時実行や自動運用を任せ始めて「どこまで許可してよいか」を決めかねている人です。
権限モードの既定値が変わり、「許可の設計」が本題になった
前提から。2026年8月14日以降、Pro / Max / TeamプランのClaude Code新規セッションは、権限モードの既定値がauto modeになりました。分類器が操作の安全性を判定し、安全側は確認なしで通す方式です。自分で既定値を設定済みの場合は切り替えプロンプトを承諾しない限り維持されます。
Claude Code公式: Permission modesControl whether Claude asks before acting. Switch permission modes with Shift+Tab in the CLI, the mode indicator in VS Code, or the mode selector in Desktop.code.claude.com
毎回の承認ダイアログに頼る運用から、「何を自動で通すか」を事前に設計する運用へ。既定値の変更はその流れの確定と読めます。そして許可の設計が本題になった途端、効いてくるのが権限の「層」の違いです。
私の従来構成は「止める」に寄っていた
私が自動運用しているSNSシステムでは、hooksのPreToolUseでBashコマンドを実行前に検査し、mainへの直接pushや自己マージなど、破られては困る操作をブロックしています。判定できないコマンドはブロック側に倒す設計です。あわせてGitHub側のブランチ保護を、すり抜け前提の受け皿にしています。
Claude Codeのhooksで自動運用に禁止ラインを引く｜Bashガード実装記録Claude Codeのhooksで、エージェントに破らせたくない操作をコードとして強制する実装記録。PreToolUseフックの設定、Bashコマンドを検査するガードスクリプト、exit code 2でブロックする仕組み、正規表現ルールの設計と限界まで、実運用中の構成をそのまま解説します。www.tentspace.net
この構成は今も機能しています。ただこれは4層のうち「止める」と「外側で強制する」の2層だけで、手前の2層——そもそもツールを渡さない、許可ルールの粒度を設計する——には手を付けていませんでした。denyの網を厚くする方向ばかり向いていたわけです。
その見直しのきっかけが、2026年8月末の3連続リリースでした。
公式が「allow側の緩さ」を問題にし始めた
Claude Codeのchangelogを時系列で並べると、方向がはっきり見えます。いずれも一次情報は公式changelogです。
Claude Code公式changelogRelease notes for Claude Code, including new features, improvements, and bug fixes by version.code.claude.com- 2.1.246（2026-08-25）: サブコマンドより前にワイルドカードを含むBash許可ルールに対して、起動時に警告が出るようになりました。あわせて
/permissionsにAuto modeタブが追加され、分類器ルールの閲覧・編集ができるようになっています。 - 2.1.248（2026-08-27）:
--restrictedフラグが追加されました。組み込みツールを外し、ファイルアクセスを制限した状態でセッションを起動できます。同バージョンでは資格情報ファイルのアップロード保護も修正されています。 - 2.1.251（2026-08-28）: 権限境界のすり抜けを塞ぐ修正が集中しました。権限チェックの後にワーキングディレクトリ内のシンボリックリンクを差し替えると承認範囲外を読み書きできた問題、Grep / Globがシンボリックリンク経由の検索パスに
Read(...)のdenyルールを適用していなかった問題、Bashの権限チェックがOPTIND=1のような算術代入を自動承認していた問題などの修正です。
ワイルドカードの起動時警告は、「許可ルールの書き方そのものが誤設定の温床になりうる」という前提がツール側に入ったということです。Bash(npm *) のつもりで書いたルールが、ワイルドカードの位置次第で意図よりずっと広い範囲を許可してしまう。この型の事故を、実行時ではなく起動時に検知する方向になりました。
許可ルールは「書いた瞬間の状態」にしか効かない
2.1.251の修正一覧は、もっと根本的なことを教えてくれます。許可の判定は、判定した瞬間の状態にしか効かないということです。
シンボリックリンクの問題が典型です。権限チェックの時点では承認範囲内のパスだったものが、チェックの後にリンク先を差し替えられると、実際の読み書きは範囲外に届いてしまう。判定と実行のあいだに前提が変わる経路があると、ルール自体は正しくても境界は破れます。
Grep / Globのdeny不適用も同じ構造です。Read(...) のdenyルールを書いた人は「このファイルは読めない」と思っていますが、実際にはツールと経路の組み合わせごとに適用のされ方が違っていた。つまり、自分のdeny行が実際に何を止めているかは、ルールの字面からは分からないわけです。
私のhooksのBashガードも、この見方で読み直すと弱点の位置が分かります。hooksはあくまで「実行しようとした操作」を検査する後段の防御です。検査対象に上がってこない経路、検査時点と実行時点で状態が変わる操作には、原理的に届きません。denyの正規表現を何行足しても、この構造は変わりません。
権限は4層で設計する
そこで、権限設定を次の4層に分けて考えるようにしました。上から順に、効く範囲が広い層です。
第1層: 渡さない。 そもそも使えるツールを絞る層です。2.1.248の --restricted フラグは、組み込みツールを外しファイルアクセスを制限した状態でセッションを始める仕組みで、まさにこの層に当たります。MCPサーバーを接続するときに、読み取り系だけのサーバーを選ぶ・書き込みツールの本数を確認するのも同じ層の判断です。渡していないツールは、許可ルールの書き間違いでも呼べません。なお、私はまだ --restricted を自分のRoutineで検証していないので、ここは仕組みの紹介にとどめます。
第2層: 許す粒度を設計する。 settings.json のallowルールと、auto modeの分類器ルールの層です。ここでの実務は2つ。ワイルドカードの位置を確認すること（2.1.246の起動時警告が出る書き方は、意図より広く許可している疑いが濃い）、そして /permissions のAuto modeタブで、分類器が何を自動承認する設定になっているかを一度見ておくことです。「denyに書いていないから安全」ではなく「allowが何を通すか」を先に固めます。
第3層: 実行前に止める。 hooksのPreToolUseによるdenyの層です。第1層・第2層を通ってきた操作のうち、文脈依存で判断すべきもの——mainへの直接push、自己マージ、破壊的なコマンド——をコードで検査してブロックします。判定できないケースをブロック側に倒すのがポイントで、ここの実装は上でリンクした記事に書いたとおりです。
第4層: エージェントの外側で強制する。 ここまでの3層はすべてClaude Codeの内側の仕組みなので、前提ごと覆る可能性を残します。最後の層は、エージェントが何をしようと物理的に通らない外側の制約です。GitHubのブランチ保護、サーバー側に置いたレート制限やAPI権限の絞り込みがこれに当たります。私の運用では、SNSへの公開回数制限をエージェント側のプロンプトではなくサーバー側のKVに置いています。
自作MCPサーバーに「投稿し過ぎない」制限を実装した記録｜制限はプロンプトではなくサーバーに置くAIエージェントに投稿ツールを渡すと放っておくと公開し過ぎます。その制限をプロンプトではなく自作MCPサーバー側（Cloudflare WorkersのKV）に置いた実装記録。単純なカウントではなくreserve→commit/releaseの二段階にした理由と、失敗時に枠を戻す設計まで解説します。www.tentspace.net
4層を言い換えると、「渡さない」は攻撃面の縮小、「許す」は入口の設計、「止める」は文脈依存の検問、「外側」は最終防衛線です。どれか1層を厚くしても、他の層の穴は塞がりません。逆に4層が揃っていれば、1層のすり抜け——2.1.251で修正されたような類のもの——が起きても、事故までは届きにくくなります。
今週やることリスト
この整理を自分の環境に当てるなら、作業は次の4つです。
settings.jsonのallowルールを開き、ワイルドカードの位置を1行ずつ確認する。Claude Codeを2.1.246以降に上げれば、危うい書き方には起動時に警告が出ます。/permissionsのAuto modeタブで分類器ルールを一読し、自動承認の範囲を把握する。- deny行それぞれについて「どのツール・どの経路に効いているか」を言えるか自問する。言えないdeny行は、第3層（hooks）か第4層（外側の強制）に置き換えられないか検討する。
- 定時実行など人が見ていないセッションについて、
--restrictedのようなツール面の縮小を検討する。
権限まわりの修正は毎週のように入っています。設定を一度書いて終わりにせず、changelogの権限関連の項目だけでも追う価値があります。
まとめ
Claude Codeの権限設定は、禁止リストの厚さではなく層の揃い方で決まります。渡さない・許す・止める・外側で強制する。私の構成は長らく第3層と第4層に寄っていましたが、公式側の直近の動き——ワイルドカード警告、--restricted、権限境界の修正の集中——は、手前の2層を設計せよというメッセージに読めます。denyの網を編み続ける前に、そもそも何を渡し、何を許すかから見直す。権限設計の順番は、たぶんそちらが先です。