Claude Codeの/permissionsコマンドで権限ルールとauto mode拒否を管理する
/permissionsダイアログでallow・ask・denyルールをスコープ別に管理し、auto modeが拒否した操作を「最近の拒否」タブから再試行する手順をまとめます。
/permissionsは、Claude Codeが使えるツールの許可・確認・拒否ルールを一覧して編集するコマンドです。設定ファイルを直接編集しなくても、ダイアログ上でallow・ask・denyの3種類のルールを追加・削除でき、auto modeの分類器が止めた操作を後から見直して再試行することもできます。エイリアスは/allowed-toolsで、どちらを打っても同じダイアログが開きます。
/permissionsコマンドでできること
/permissionsを実行すると、現在有効な全ルールがスコープ(どの設定ファイルに書かれているか)ごとに一覧されます。ここでできる操作は4つです。
- ルールをスコープ別に閲覧する(ユーザー設定・プロジェクト設定・管理設定のどれに由来するか)
- allow・ask・denyルールを追加・削除する
- 追加した作業ディレクトリを管理する(
/add-dirで加えたディレクトリの一覧・削除) - auto modeが拒否した操作の履歴を「最近の拒否」タブで確認し、再試行を指示する
Claudeが応答している最中でも/permissionsは開けます。v2.1.234以降では、ここで加えた変更が同じターン内の次のツール呼び出しから即座に反映されます。それより前のバージョンでは、変更はターンが終わるまでキューに積まれてから適用されていました。
allow・ask・denyはこの順で評価される
ルールは常にdeny→ask→allowの順で評価され、この順序で最初に一致したルールが結果を決めます。ルールの詳しさ(specifierの有無)は順序に影響しません。
このため、広い範囲を対象にしたdenyルールは、より狭いallowルールを上書きします。たとえばBash(aws *)をdenyに置くと、Bash(aws s3 ls)のようなallowルールがあってもすべてブロックされます。denyルールに「例外だけallowに逃がす」という書き方は成立しません。
deny・askはツール名だけの「裸のルール」と、specifierで絞った「範囲付きルール」で挙動が変わります。
| ルールの形 | 挙動 |
|---|---|
Bash(裸のツール名) | 挙動ツールそのものをClaudeの文脈から消す。Claudeはツールの存在自体を認識しなくなる |
Bash(rm *)(specifier付き) | 挙動ツール自体は使えるままで、一致する呼び出しだけを止める |
裸のツール名によるdenyの対象外はEndConversationだけです。ほかのツールが1つでも残っている限り、このツールを裸のdenyルールで消すことはできません。
ルールの範囲を絞る — コマンド指定とパラメータ一致
ToolまたはTool(specifier)の形でルールを書くと、細かい単位で許可・拒否を分けられます。
{
"permissions": {
"allow": ["Bash(npm run *)", "Bash(git commit *)"],
"deny": ["Bash(git push *)"]
}
}Bash(ls *)とBash(ls:*)は同じ意味で、末尾ワイルドカードの書き方が2通りあるだけです。ただし:*の省略形が使えるのは末尾だけで、Bash(git:* push)のようにパターンの途中にコロンを置くと、コロンはただの文字として扱われマッチしません。
deny・askルールは、ツールの主要な内容(BashのcommandやReadのfile_pathなど)以外なら、入力パラメータの値でも絞り込めます。
Agent(model:opus) → Opusモデルを要求するAgent呼び出し
Bash(run_in_background:true) → バックグラウンド実行のBash呼び出し一方allowルールはこの形式を使えません。1つのパラメータが一致しただけでは呼び出し全体の安全性を保証できないため、allow側は各ツール固有のspecifier構文に限定されています。Bash(command:rm *)のように主要な内容フィールドを直接狙うルールは、複合コマンドで迂回されるため起動時に警告付きで無視されます。Bash(rm *)のように書き直す必要があります。
auto modeの拒否をレビューして再試行する
/permissionsのもう1つの役割が、auto modeの分類器が止めた操作の見直しです。「最近の拒否」タブを開くと、分類器が拒否した操作が一覧で並びます。見直したい操作の上でrキーを押すと再試行としてマークされ、ダイアログを閉じた時点でClaudeにその操作を再試行してよいというメッセージが送られ、会話が再開します。
拒否を解消する手段は、拒否の原因によって3つに分かれます。
| 拒否の原因 | 対処 |
|---|---|
| タスク全体を通じて必要な接続先(パッケージレジストリ・社内ドメイン等) | 対処autoMode.environmentに追加する |
| 今後も確認なしで実行したいコマンド | 対処allowルールを追加する |
| 意図した単発の操作だった | 対処次のメッセージでその意図を伝え、rキーで再試行する |
同じ接続先への拒否が繰り返される場合は、分類器が文脈を把握できていないサインです。autoMode.environmentに対象を追加し、claude auto-mode configで反映を確認します。分類器がどの基準でスコアを付けているかはauto mode分類器は何を止めているかにまとめています。
allowルールを1件ずつ手で追加する代わりに、過去の会話履歴を走査して繰り返し許可しているBashやMCPの呼び出しをsettings.jsonのallowlistへ自動で足すSkillが/fewer-permission-promptsです。仕組みと注意点は/fewer-permission-promptsで許可プロンプトを自動整理するにまとめています。
分類器自体が判定不能(モデルが一時的に利用できない、応答がパースできない等)だった場合、その拒否は「最近の拒否」タブに記録されません。この判定不能ケースの見分け方とエラーメッセージの読み方はauto mode安全性判断エラーで扱っています。プログラムから拒否に反応したい場合はPermissionDeniedフックが使えます。
ルールの保存先とスコープの確認
ダイアログに並ぶルールは、どの設定ファイルに由来するかが行ごとに表示されます。「Yes, and don't ask again」のようにダイアログから恒久保存を選んだBashコマンドやWebFetchドメインのルールは、gitリポジトリのルートにある.claude/settings.local.jsonに書き込まれます。worktreeで作業している場合もメインのチェックアウトへ解決されるため、worktreeのサブディレクトリで承認したルールがリポジトリ全体に適用されます。
v2.1.211より前は常に起動したディレクトリに保存されていたため、worktreeやサブディレクトリで承認したルールがリポジトリの他の場所に及びませんでした。古いバージョンで保存されたルールは、そのまま起動先のディレクトリに紐づいて残ります。
ファイル編集の承認はルールとして保存されず、セッション終了までの一時的な許可にとどまります。/permissionsでルールを追加・削除する操作自体は、/add-dirで加えた作業ディレクトリの管理にも使えます。設定ファイルの階層と優先順位の全体像はClaude Code settings.json完全ガイドにまとめています。
/permissionsとサンドボックスは別のレイヤー
/permissionsが管理するallow・ask・denyルールと、サンドボックスによるOSレベルの制限は、補完関係にある別の防御層です。
- 権限ルールはBash・Read・Edit・WebFetch・MCPなど、ほぼ全ツールに対して「使わせるかどうか」を決めます
- サンドボックスはBashツールとその子プロセスだけを対象に、ファイルシステムとネットワークへのアクセスをOSレベルで制限します
denyルールはClaudeが制限されたリソースに手を伸ばそうとすること自体を止めるのに対し、サンドボックスの制限は、プロンプトインジェクションでClaudeの判断が乗っ取られた場合でも、境界の外にBashコマンドが到達しないよう防ぎます。サンドボックスを有効にしautoAllowBashIfSandboxedを既定のtrueのままにしていると、サンドボックス化されたBashコマンドは、権限設定に裸のBashaskルールがあっても確認なしで実行されます。ただしplanモードではこの代替は働かず、git pushのような範囲付きaskルールや明示的なdenyルール、rm/rmdirが重要パスを対象にする場合は、サンドボックス下でも通常の確認フローを通ります。
権限ルールが「Claudeに何をさせるか」の意思決定層、サンドボックスが「Bashが実際にどこまで届くか」の実行環境層と考えると、両者の役割分担が見えやすくなります。
よくある質問
/permissionsとauto modeの設定は何をそれぞれ管理しますか
/permissionsが管理するallow・ask・denyルールは、auto modeの分類器が動く前段で適用されます。deny・askルールに一致した操作は分類器に渡る前に確定するため、分類器はルールをすり抜けた操作だけを評価します。
dontAskモードでも/permissionsで許可したツールは使えますか
使えます。dontAskモードは事前承認されていないツールを既定で拒否しますが、/permissionsやpermissions.allowで許可済みのツールは引き続き動きます。ただしAskUserQuestionや、組織側でask指定されたconnectorツール、requiresUserInteractionを指定したMCPツールは、許可していてもこのモードでは拒否されます。
/allowed-toolsと/permissionsは別のコマンドですか
同じコマンドのエイリアスです。どちらを実行しても同じダイアログが開きます。
確認プロンプトに出たコマンドが何をするか分からないときは
Bash・PowerShellの確認プロンプトでCtrl+Eを押すと、そのコマンドが何をするか・なぜClaudeが実行しようとしているか・何がリスクかをLow/Med/Highの3段階のラベル付きで表示できます。この説明生成はコマンドとClaudeの説明文をモデルに送って生成するため、Ctrl+Eを押したときだけ走り、プロンプトのたびに自動では走りません。表示するだけでコマンド自体は実行されず、もう一度押すと隠せます。不要なら~/.claude.jsonのpermissionExplainerEnabledをfalseにして無効化できます。
追加した許可ルールは他のプロジェクトにも効きますか
効きません。ダイアログから恒久保存したルールは、そのgitリポジトリの.claude/settings.local.jsonに書き込まれ、そのリポジトリ内のセッションにだけ適用されます。全プロジェクトで共通のルールを配りたい場合は、ユーザー設定や管理設定に書く必要があります。
まとめ
/permissionsは、allow・ask・denyルールをスコープ別に見渡し、その場で追加・削除できる唯一の対話的な入り口です。deny→ask→allowの評価順序と、specifierによる範囲指定を把握しておくと、必要なコマンドだけを的確に通せます。auto modeを使っているなら「最近の拒否」タブは特に価値があり、rキー1つで拒否された操作をその場から再試行できます。
権限設計で迷ったときの起点は3つです。
- ルールをどこに書けば意図した範囲(このリポジトリだけか、全プロジェクトか)に効くかを
.claude/settings.local.jsonとユーザー設定の違いで確認する - auto modeを使っているなら、まず「最近の拒否」タブを見て、繰り返し拒否されている接続先が無いかを確認する
- サンドボックスとは別のレイヤーであることを踏まえ、両方を組み合わせて権限設計をする
この3点を押さえておけば、/permissions単体でも、auto modeやサンドボックスと組み合わせた運用でも、意図しない拒否や意図しない許可を減らせます。