Claude Codeの確認プロンプトを減らす設定──allow / ask / deny をどこで線引きするか

Claude Codeで「実行してよいですか」の確認が毎回出るのが面倒、という悩みの解き方は2通りある。allowルールを足して許可範囲を広げるか、権限モードそのものを緩めるかだ。ただし公式ドキュメントを読むと、前者には明確な天井がある。autoモードに入った瞬間、Bash(*) のような包括的なallowルールやワイルドカードのインタープリタ指定は自動的に取り外されると明記されている。一方でdenyルールとaskルールは、bypassPermissions を含むすべてのモードで効き続ける。つまり「許可を増やす」施策はモードによって無効化されるが、「禁止を書く」施策は無効化されない。この非対称性がある以上、先に固めるべきはdeny側だ、というのが本記事の立場である。以下、2026年8月27日に公式ドキュメントを取得して確認した仕様を並べる。

3行まとめ

1. 権限ルールの評価順は deny → ask → allow で、最初に一致したルールが勝つ。ルールの具体性は順序を変えないため、広いdenyの中に狭いallowの例外は書けない（公式明記）
2. autoモードに入ると Bash(*)・Bash(python*) のようなワイルドカードのインタープリタ指定・パッケージマネージャの実行コマンド・Agent のallowルールは削除される。.git .claude .zshrc など保護されたパスへの書き込みはallowルールで事前承認できない
3. 3回連続または累計20回ブロックされるとautoモードは一時停止して手動確認に戻る。このしきい値は設定不可

権限設定は3つのキーと1つのモードでできている

公式の設定リファレンスによると、settings.json の permissions 配下に置くキーは次のとおり。

ルールの書式は Tool または Tool(specifier)。括弧なしのツール名はそのツールの全使用に一致し、Bash(*) は Bash と同等とされる。設定ファイルの置き場所は、全プロジェクトに効く ~/.claude/settings.json、リポジトリで共有する .claude/settings.json、コミットしない個人用の .claude/settings.local.json の3層（＋組織が配布するmanaged設定）だ。Claude Codeとは何かという前提から確認したい場合はClaude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェントを参照してほしい。

なぜ「allowを足す」だけでは頭打ちになるのか

理由は3つ、いずれも公式ドキュメントに書かれている。

第一に、autoモードは広いallowルールを剥がす。 権限モードのドキュメントには、autoモードに入ると「任意のコード実行を許可する広いルールが削除される」とあり、対象として①包括的な Bash(*) または PowerShell(*)、②Bash(python*) のようなワイルドカードのインタープリタ指定、③パッケージマネージャの実行コマンド、④Agent のallowルールが挙げられている。Bash(npm test) のような狭いルールは引き継がれ、削除されたルールはautoモードを抜けると復元される。2026年8月14日からautoモードがPro/Max/Teamのデフォルトになった件は別記事にまとめたが、デフォルトが変わったことでこの「剥がれる」挙動に当たる人は増えているはずだ。

第二に、保護されたパスはallowで事前承認できない。 .git .config/git .vscode .idea .husky .cargo .devcontainer .yarn .mvn .claude（.claude/worktrees を除く）といったディレクトリと、.gitconfig .bashrc .zshrc .envrc .npmrc .mcp.json .claude.json などのファイルへの書き込みは、bypassPermissions 以外のすべてのモードで自動承認されない。公式は「安全性チェックはClaude Codeが設定からallowルールを評価する前に実行される」ため Edit(.claude/**) のようなエントリを書いても結果は変わらない、と明記している。モード別の挙動は、default/acceptEdits/plan はプロンプト、auto は分類器へルーティング、dontAsk は拒否。

第三に、プロジェクトのallowルールは信頼ダイアログを通るまで適用されない。 リポジトリ内の .claude/settings.json に書いた permissions.allow と additionalDirectories は「機能を付与する」ため、ワークスペース信頼ダイアログを受け入れた後にのみ適用される。それまでは読み込まれるが適用されない。対してdenyルールとaskルールは「制限のみを行うため、影響を受けない」。非対話モード（-p）ではダイアログが出ないので、allowルールは無視されたままになる。

denyは無効化されず、allowは3つの条件で無効化される。設定を書く順番をdeny→ask→allowにする理由はここにある（この順序自体は筆者の運用判断であり、公式が推奨しているわけではない）。

評価順は deny → ask → allow、特異性は順序を変えない

公式の記述をそのまま引くと、「ルールは順序で評価されます。deny、ask、allow の順です。その順序での最初のマッチがアウトカムを決定し、ルールの特異性は順序を変更しません」。

ここから2つの実務的な帰結が出る。ひとつ、Bash(aws *) のような広いdenyルールは Bash(aws s3 ls) のような狭いallowルールにも一致する呼び出しをすべてブロックするため、denyルールの中にホワイトリスト例外を作ることはできない。ふたつ、一致するaskルールがあれば、より具体的なallowルールが同じ呼び出しに一致していてもプロンプトは出る。「確認が減らない」時は、広すぎるaskルールが残っていないかを先に疑うほうが早い。

denyの書き方にも差がある。Bash のようなベアツール名のdenyはツールをClaudeのコンテキストから完全に削除するため、Claudeはそのツールの存在を認識しない。Bash(rm *) のようなスコープ付きdenyはツールを残したまま、一致する呼び出しだけをブロックする。全MCPツールを落としたいなら deny に "mcp__*" を1行書けばよい（MCPそのものについてはMCPとはを参照）。特定のサブエージェントを止めるなら Agent(Explore) のように書く。

スコープをまたいだ場合も同じで、ユーザー設定のdenyはプロジェクト設定のallowをブロックする。どのスコープのdenyもallowより先に評価されるためだ。加えて配列型の設定はスコープをまたいで連結・重複排除される（fallbackModel と availableModels は例外）ので、~/.claude/settings.json に書いたdenyは全プロジェクトに積み上がる。

allowを書くときに外しやすい3つの落とし穴

複合コマンド。 Claude Codeは && || ; | |& & と改行をコマンド区切りとして認識する。Bash(safe-cmd *) があっても safe-cmd && other-cmd の実行権限にはならず、各サブコマンドが独立して一致する必要がある。逆に「今後は聞かない」で複合コマンドを承認すると、複合文字列全体ではなくサブコマンドごとのルールが保存される（1つの複合コマンドにつき最大5ルール）。

プロセスラッパー。 ルール照合の前に timeout time nice nohup stdbuf とフラグなしの xargs は取り除かれるので、Bash(npm test *) は timeout 30 npm test にも一致する。問題はこのリストが組み込みで変更できないこと。npx・docker exec・devbox run・direnv exec・mise exec は含まれていないため、Bash(devbox run *) というルールは devbox run rm -rf . にも一致してしまう、と公式が名指しで警告している。環境ランナー越しに許可するなら Bash(devbox run npm test) のようにランナーと内部コマンドを両方書く。なお watch setsid ionice flock、および -exec や -delete を伴う find は常にプロンプトを出し、プレフィックスルールでは自動承認できない。

パスのアンカー。 Read/Editのパターンはgitignore仕様に従い、//path がファイルシステムルート、~/path がホーム、/path が設定ソースからの相対、path/./path がカレントディレクトリ相対を意味する。つまりユーザー設定に Read(/secrets/**) と書くと、プロジェクト内の secrets ではなく ~/.claude/secrets/** をブロックする。全プロジェクトに効かせたいなら // か ~/ を使う。Read(.env) は Read(**/.env) と同等でカレントディレクトリ以下の任意の .env に一致するが、親ディレクトリや別プロジェクトの .env には届かない。そこまで塞ぐなら Read(//**/.env) を書く。また、Readのdenyルールは同じパスのEditもブロックする（v2.1.208以降）が、WriteとNotebookEditはカバーされないので、変更させたくないパスには Edit のdenyも併記する。

なお ls cat echo pwd head tail grep find wc which diff stat du cd とgitの読み取り専用形式は、組み込みで読み取り専用と認識され全モードでプロンプトなしに実行される。このセットは設定不可で、逆にプロンプトを出させたい場合はそのコマンドに ask か deny を足す。

確認が減らない・増えた時に見る場所

/permissions はすべての権限ルールと、それがどの settings.json から来ているかを一覧する。拒否されたアクションは同じ画面の「Recently denied」タブに並び、r で手動承認して再試行できる。どの設定ソースが読み込まれたかは /status の Status タブの Setting sources 行、設定ファイルにJSONエラーがある場合の詳細は /doctor で出る。

autoモードで急に確認が復活した場合、原因はフォールバックの可能性がある。分類器が3回連続、または累計20回ブロックすると、autoモードは一時停止してプロンプトが再開する。しきい値は設定不可で、プロンプトされたアクションを承認すると再開する。非対話モード（-p）では承認する人がいないため、繰り返しのブロックはセッションを中止させる。

Bashの確認画面では Ctrl+E を押すとコマンドの説明が出て、低リスク／中リスク／高リスクのラベルが付く。説明はキーを押した時だけ生成され、表示してもコマンドは実行されない。この機能は ~/.claude.json の permissionExplainerEnabled を false にすれば切れる。

より強い制御が要るなら、PreToolUseフックを使う手もある。終了コード2で終わるフックは権限ルールの評価前にツール呼び出しを止めるため、allowルールがある呼び出しでもブロックできる。逆にフックが "allow" を返してもdenyルールとaskルールは評価される。「Bashは全許可にして、止めたい少数だけフックで拒否する」構成を公式が明示的に案内している。フックの組み方はAIに「ルールを読め」は効かない──読むまで作業をブロックする仕組み（hooks）の作り方に書いた。

この設定で防げないこと

権限ルールは万能ではない。公式ドキュメント自身が限界を書いているので、そのまま挙げる。

• 間接的な読み書きは止まらない。 ReadとEditのdenyルールは、Claudeの組み込みファイルツールと、Claude Codeが認識するBashのファイルコマンド（cat head tail sed など）には適用される。しかしPythonやNodeのスクリプトが自分でファイルを開くような任意のサブプロセスには適用されない。OSレベルで全プロセスを塞ぐにはサンドボックスが要る。
• コマンド引数を制約するBashパターンは脆い。 Bash(curl http://github.com/ *) は、URL前のオプション、httpsへの変更、-L によるリダイレクト、変数展開、余分なスペースのいずれでも一致しなくなる。公式は代わりに、curl/wgetをdenyでブロックしてWebFetchに寄せる／PreToolUseフックでURLを検証する、を推奨している。ただしBashが使える限り、WebFetchのドメイン制限だけでネットワークアクセスは防げない。
• denyを増やすと作業も止まる。 ベアツール名のdenyはツールをコンテキストから消すので、Claudeは代替手段を探せない。禁止範囲を広げるほど「できません」の頻度は上がる。どこで線を引くかは、リポジトリの性質と本人のリスク許容度の問題で、正解は一つではない。
• 削減量は数値で示せない。 本記事は「確認が何％減る」といった数字を出していない。プロンプト数は作業内容・モード・リポジトリ構成に依存し、当サイトでは条件をそろえた計測をしていないためだ。効果の保証はしない。
• バージョン依存の記述が多い。 公式ドキュメントには v2.1.142（プロジェクト設定の auto を無視）、v2.1.200（manual エイリアス）、v2.1.203、v2.1.207、v2.1.208（Read denyがEditにも及ぶ）といった但し書きが多数含まれる。claude --version で自分の版を確認してから読み合わせてほしい。エラーが出る場合の切り分けはClaude Codeがエラーで動かない時の切り分け手順にまとめている。

確認日と、実機検証していない範囲

本記事の仕様はすべて2026年8月27日にAnthropic公式ドキュメント（日本語版）を取得して確認した。同日以降の変更は反映していない。設定例は公式ドキュメント内の記載を引用したもので、当サイトの環境で全パターンを実機検証したわけではない。組織のmanaged設定が配布されている環境では、ユーザー設定・プロジェクト設定の内容がそもそも上書きできない場合がある（allowManagedPermissionRulesOnly が true の場合、ユーザーとプロジェクトはallow/ask/denyを定義できない）。

• Claude Code の設定 — Claude Code公式ドキュメント（2026年8月27日確認）：https://code.claude.com/docs/ja/settings
• 権限を設定する — Claude Code公式ドキュメント（2026年8月27日確認）：https://code.claude.com/docs/ja/permissions
• 権限モードを選択する — Claude Code公式ドキュメント（2026年8月27日確認）：https://code.claude.com/docs/ja/permission-modes