権限ルールとは何ですか？
権限ルールの形式はToolまたはTool(specifier)で、allow、ask、denyの3種類がある。ツール名だけ（例：Bash）ならそのツールのすべての使用に一致し、括弧で範囲を絞れる。例えばBash(npm run build)はそのコマンド全体、Read(./.env)はそのファイルの読み取り、WebFetch(domain:example.com)はそのドメインへの取得に一致する。denyとaskルールはTool(param:value)で最上位の入力パラメータにも一致できる。
なぜ存在しますか？
毎回確認する方法と全面許可の間に中間地帯を作るためだ。日常的に安全なコマンドは確認が不要になり、危険なものは常に拒否される。ルールはバージョン管理に入れてチームで共有でき、各開発者が自分用に追加もできる。優先順位は明確で、どのスコープのdenyもallowより優先され、managed設定が最上位であり、コマンドライン引数でもmanagedのルールは上書きできない。
どう動き、どんな限界がありますか？
BashルールはClaudeが書くコマンドテキストに照合する。は任意のテキストを表し、末尾の「スペース＋」は引数なしのコマンドにも一致する。複合コマンド（&&、||、;、パイプなど）ではallowは各サブコマンドが個別に一致する必要があり、denyとaskはどのサブコマンドが一致しても有効になる。照合前にtimeout、time、nice、nohupなどの固定ラッパーが除去される。公式は、denyやaskルールはClaudeが通常生成する書き方をカバーするだけでプログラムを囲む境界ではないと明言しており、Bash(rm *)は/bin/rmやbash -cを止めない。テキストに依存しない強制にはサンドボックス、独自の検査にはPreToolUse hookを使う。
私にとってどういう意味ですか？
ルールは確認を減らす便利層と考え、何かが起きないことの保証とは考えない。allowは内側のコマンドまで含めて具体的に書く（Bash(devbox run *)ではなくBash(devbox run npm test)。前者はdevbox run以降のすべてを通す）。本当に起きてはいけないことはサンドボックスかhookに任せる。この「使い方」は公式ドキュメントに対する私の整理だ。
公式ドキュメントの例：Bash(npm run *)とBash(git commit *)をallow、Bash(git push *)をdenyにすると、npmスクリプトとcommitは確認なしになりgit pushは拒否される。ただしgit -C . pushはそのdenyに一致しない。
メリット：きめ細かく、共有でき、優先順位が明確。デメリット：テキストにしか照合しないため、別の書き方や環境ランナーによってルールが思ったより広くも狭くもなる。