Claude Code permissions は「承認が出るから安全」という雑な期待を壊す
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- coding agent を安全に使う難しさは、『危ない操作だけ確認してくれればよい』では済まないことにある。確認が多いほど、人は流れ作業で承認しやすくなる。
- もう一つ危ないのは、禁止したつもりの操作が別の形で呼ばれることだ。command 名だけ見て止める運用では、回り道を見落としやすい。
- Claude Code permissions は、毎回の気分で承認する代わりに、何を自動で許し、何を毎回聞き、何を最初から禁止するかを決めておく仕組みである。
- docs の読みどころは、設定画面の使い方よりも、禁止ルールが許可ルールより強く働くこと、そして wrapper や symlink のような回り道まで考える必要があることだ。
- hooks を入れても permissions の責任は消えない。事前検査と許可ルールを別々の層として持つほうが、実運用では説明しやすい。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
この docs は、permissions を単なる『許可を聞く設定』としてではなく、tool ごとの rule system として整理しています。allow は手動承認なしで使わせる、ask は毎回確認する、deny は使えなくする、という三層があり、それを `/permissions` から確認できます。さらに重要なのは precedence、つまり複数の設定がぶつかった時にどれを優先するかです。deny はどのレベルでも他の allow を打ち消し、安全側へ倒れる合成規則として働きます。
なぜ重要か
日本のチームでは『確認画面が出るから安全』『危なそうな command 名を数個 deny すれば十分』と考えがちです。しかし docs は、Bash command の指定、wrapper、複合 command、path 解決まで見ないと簡単に穴が開くことを示しています。また hooks と permissions の役割分担にも効きます。hook で前処理や検査をしていても、deny/ask rule は別に効き続けます。rule layer と hook layer を分けて持つほうが堅い、という設計判断につながります。
技術的ポイント
- `/permissions` UI では rule とその設定ファイルの出所を確認できる。運用上は、何が効いているか分からない状態を減らす入口になる。
- allow は自動許可、ask は都度確認、deny は禁止だが、評価順は deny-first であり、deny は他スコープの allow でも上書きできない。managed settings の deny も CLI で緩められない。
- docs は Bash rule の細粒度指定、compound commands、つまり `&&` などで連結した複合 command、そして process wrapper まで扱っている。単純な command 名パターンだけで止まるはずと思うのは危険である。
- `PreToolUse` hook が `allow` を返しても、matching deny rule はなお block し、matching ask rule はなお prompt する。hook は permission rule を消す抜け道ではない。
- `Cd` rule では symlink、つまり見かけ上は別名でも実体は別の場所を指す参照の解決先まで deny 判定する。path 制御も見た目の文字列だけでなく実解決先を意識する設計になっている。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| Claude Code permissions | Claude Code 権限設定 | Claude Code が実行してよい操作を allow / ask / deny の rule として制御する仕組み。 |
| allow rule | 自動許可ルール | 手動承認なしで実行を許す permission rule。広げ過ぎると監査と安全性が弱くなる。 |
| ask rule | 都度確認ルール | 実行前に人へ確認させる permission rule。多過ぎると承認疲れが起きる。 |
| deny rule | 禁止ルール | 実行を止める permission rule。Claude Code permissions では allow より強い制約として扱われる。 |
| settings precedence | 設定優先順位 | 複数の設定元が重なった時にどれを優先するかの規則。deny と allow の衝突理解に必要。 |
| PreToolUse | ツール実行前フック | 実行前に block や書き換えを行うイベント。禁止系ガードレールはここに置く。 |
試すなら
- まず自分の repo で絶対禁止、毎回確認、自動許可の 3 列を作り、tool と command を振り分ける。
- deny したいものは command 名だけでなく wrapper や派生命令も洗う。
- `--allowedTools` で一時的に広げる前に、managed settings や project settings の deny が何かを確認する。
- hooks を使っているなら、permission rule と役割が重複していないかを見直す。
注意点
- permissions は強いが、粗いパターンで安心すると抜け道が残る。特に Bash 系は実際の command 形を見て詰める必要がある。
- ask を増やし過ぎると承認疲れが起きる。安全性を dialog 数で稼ぐ発想は長続きしない。
- allow を広げたあとで deny を足しても、何を塞げていないかを検証しなければ policy は飾りになる。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。