Claude Code allow deny ask Bashルール Claude Code permissions settings.json ワイルドカード 環境ランナー 許可プロンプト

allow/denyаskで許可プロンプトを制御する書き方

許可プロンプトを減らす近道は、安全だと確信できるコマンドをpermissions.allowに列挙することです。設定は.claude/settings.jsonに書けばチームで共有できます。ただしルールは記述順ではなく決まった優先順位で評価されるため、この順序を知らないと「書いたのに効かない」に陥ります。以下はClaude Code 2.1系の挙動です。

deny→ask→allowの評価順序がプロンプトの有無を決める

ルールはdenyaskallowの順に照合され、最初にマッチしたものが結果を決めます。ルールが具体的かどうかは順序に影響しません。ここを誤解している人が多いのです。

たとえば広いBash(aws *)denyがあると、より狭いBash(aws s3 ls)allowを書いても許可されません。denyはマッチした呼び出しを一律ブロックし、アローリストの例外を内包できないからです。askallowの関係も同様で、マッチするaskがあれば具体的なallowを書いてもプロンプトが出ます。プロンプトを消したいなら、まずdenyとaskが対象コマンドに広くかぶっていないかを確認してください。

Bashのワイルドカードと複合コマンドを取りこぼさず書く

Bashルールの*はスペースの有無で意味が変わります。Bash(ls *)ls -laにマッチしますがlsofにはマッチせず、Bash(ls*)は両方に当たります。単語境界を効かせたいなら末尾にスペースを入れましょう。

もう一つの落とし穴が複合コマンドです。&&|;で連結された各サブコマンドは個別に照合されるため、Bash(git status *)だけではgit status && npm test全体は自動承認されません。連結されたnpm testにも別途allowが必要です。なお、GUIで「今後は聞かない」を選ぶとClaude Codeがサブコマンドごとにルールを分割保存するので、複合コマンドを手動承認していけば必要な粒度のルールが自然に積み上がります。

「設定したのにプロンプトが減らない」ときに疑う落とし穴と確認方法

allowを足してもプロンプトが出続けるなら、まず「Claudeが実際に送っているコマンド文字列と、あなたのパターンが一致しているか」を見ます。claude --verboseで起動すると各ツール呼び出しの正確な引数が表示され、ルールとの差分を目視で突き合わせられます。現在有効なルールと取得元ファイルは/permissionsで一覧できます。

タイプミスも見落とせません。既知のツール名に一致しないdeny/askルールは起動時に警告が出るので、まずこの警告を潰しましょう。

プロセスラッパーや環境ランナー越しのコマンドで自動承認が抜けるケース

Claude Codeは照合前にtimeouttimenicenohupstdbufと、フラグなしのxargsを剥がします。だからBash(npm test *)timeout 30 npm testにもマッチします。この一覧は固定で変更できません。

一方、devbox runmise execnpxdocker execのような環境ランナー(指定したコマンドを実行するラッパー)は剥がされません。ランナー名と内側コマンドをまとめて一つのコマンドとして扱うため、Bash(npm test)を許可していてもdevbox run npm testは別物と判定され、プロンプトが出ます。ここでBash(devbox run *)と丸ごと許すとdevbox run rm -rf .まで通ってしまうので、Bash(devbox run npm test)のように承認したい内側コマンドごとに具体的に書くのが安全です。ランナー経由でだけプロンプトが残るなら、まずこの剥がし対象外を疑ってください。

剥がされるラッパーと剥がされない環境ランナーの違い
剥がされるラッパーと剥がされない環境ランナーの違い