Claude Codeの権限設定｜permission modeとallow・deny

Claude Codeの権限設定は、「permission modeで基本姿勢を決め、allow・ask・denyで個別の操作を調整する」と整理すると分かりやすくなります。安全性を優先するなら、まずdefault（Manual）を基準にし、lintやテストなど限定した反復操作だけをallowへ、外部への変更はask、秘密情報や明確に避けたい操作はdenyへ寄せる設計から始めるのが実務的です。

まず結論：modeは基本姿勢、ruleは個別判断

設定	役割	考え方
permission mode	セッション全体の承認方針を決める	まずdefault・auto・planなどから基本姿勢を選ぶ
allow	指定した操作を手動承認なしで許可する	安全性を確認できる反復操作へ限定する
ask	指定した操作を毎回確認する	外部変更や影響範囲を確認したい操作に使う
deny	指定した操作を禁止する	秘密情報や実行させたくない操作を明示的に止める

Claude Codeでは権限ルールそのものをClaudeの回答内容で決めるのではなく、Claude Code側が評価します。つまり、CLAUDE.mdへ「実行してよい」と書くだけでは権限は付与されません。

権限ルールはdeny→ask→allowの順で評価される

allow・ask・denyが同じ操作へ重なった場合は、deny、ask、allowの順で評価されます。より具体的なallowを書いても、先に一致する広いdenyを上書きできません。

用語解説：permission rule
Claude CodeのToolや操作パターンに対して、許可・確認・拒否を指定するルールです。ToolまたはTool(specifier)の形で設定します。

denyに一致する：その操作をブロックする
denyに一致せずaskに一致する：実行前に確認する
どちらにも一致せずallowに一致する：手動承認なしで実行できる
どのruleにも一致しない：選択中のpermission modeの挙動に従う

権限トラブルを切り分けるときは、「modeが何か」だけでなく、先に一致するdenyやaskが残っていないかを確認するのがポイントです。

permission modeは用途に合わせて使い分ける

mode	主な挙動	向く場面
default（Manual）	承認が必要な操作は確認しながら進める	最初の導入、影響範囲を把握しながら使う
acceptEdits	作業ディレクトリ内のファイル編集などを自動承認する	編集は任せつつ、コマンド実行は確認したい
plan	読み取り中心で調査・計画する	変更前の調査、設計レビュー
auto	バックグラウンドの安全チェックを通して操作を自動承認する	確認回数を減らしながら自動化したい
dontAsk	事前許可されていない操作は確認せず拒否する	CIなど、許可済み操作だけで完結させたい
bypassPermissions	通常の権限確認を大幅に省略する	隔離されたコンテナやVMなど、影響範囲を限定できる環境

autoは「すべて無条件で許可する」modeではありません。Claude Codeの現行仕様ではバックグラウンドの安全チェックを使います。一方、bypassPermissionsは保護が大きく減るため、公式ドキュメントも隔離環境での利用を前提にしています。

確認を減らすなら、反復する安全な操作だけallowにする

毎回同じ確認が出るからといって、Bash全体をallowにする必要はありません。実務では、日常的に繰り返すlintやtestだけを狭く許可し、外部へ影響する操作をask、触れてほしくない対象をdenyに分ける方が管理しやすくなります。

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm test *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(.env)",
      "Bash(rm -rf *)"
    ]
  }
}

上記は考え方を示す例です。実際のcommandやfile pathはプロジェクトに合わせて狭く設定してください。特にallowを広げる前に、対象コマンドが外部サービスや本番環境へ変更を加えないか確認します。

「Yes, don't ask again」で保存される範囲にも違いがある

確認ダイアログで永続的な許可を選んだ場合でも、すべての承認が同じように保存されるわけではありません。現行の公式ドキュメントでは、Bashの永続許可はrepositoryとcommand単位で保存され、通常はgit repositoryルートの.claude/settings.local.jsonへ記録されます。一方、file modificationの承認はsession終了までです。

対象	承認の扱い
Bash commandの永続許可	repositoryとcommand単位で保存され、将来のsessionにも適用される
file modificationの承認	session中のみ有効
/permissionsで管理するrule	どのsettings.json由来のruleかを確認しながら管理できる

「以前は聞かれなかったのに、別の操作ではまた確認される」という挙動は、保存範囲の違いでも起こります。

CLAUDE.md・Hooks・permissionsは役割が違う

仕組み	主な役割	権限境界になるか
CLAUDE.md	プロジェクトの方針や実行手順をClaudeへ伝える	単独では権限を付与・解除しない
permissions	Toolやcommand、pathごとの許可・確認・拒否を決める	なる
PreToolUse Hook	Tool実行前に追加の検査や制御を行う	設定次第で実行を止められる

「CLAUDE.mdへ禁止と書いたから安全」と考えるのではなく、実際に止めたい操作はpermissionsやHookなど実行側の仕組みで制御します。逆に、permissionsで許可されていても、CLAUDE.mdはClaudeがどの操作を選ぶかという行動方針を整えるために有効です。

迷ったらdefaultから始め、必要な部分だけ自動化する

状況	選び方
導入したばかり	default（Manual）で実際に要求される権限を確認する
lint・testの確認だけ減らしたい	対象commandだけallowへ追加する
編集は任せたいがshellは確認したい	acceptEditsを検討する
変更せず調査だけさせたい	planを使う
確認回数を減らしてAgent作業を進めたい	autoを検討し、deny・askを併用する
無人実行で許可済み操作だけ使わせたい	dontAskと明示的なallowを組み合わせる
権限確認そのものを省略したい	通常環境では避け、隔離環境でbypassPermissionsの必要性を個別判断する

権限設定の目的は「確認をゼロにすること」ではなく、止めるべき操作は止めたまま、確認する価値が低い反復操作だけを減らすことです。まず現在の/permissionsを確認し、繰り返し発生している承認から狭く整理してみてください。

仕様は更新されるため、設定変更時はClaude Code公式のConfigure permissionsも合わせて確認してください。

よくある質問

allowを書けばdenyより優先されますか？

いいえ。現行仕様ではdeny、ask、allowの順で評価されます。広いdenyに一致する操作は、より具体的なallowがあっても許可されません。

auto modeならpermission ruleは不要ですか？

不要とは限りません。modeは基本姿勢、ruleは個別操作の境界です。自動化を進める場合も、明示的に止めたい操作や毎回確認したい操作はdeny・askで分けておくと意図を保ちやすくなります。

CLAUDE.mdに許可を書けば実行できますか？

CLAUDE.mdはClaudeの行動方針には影響しますが、Claude Codeが強制するpermissionそのものは変更しません。権限は/permissions、settingsのrule、permission mode、必要に応じてHook側で管理します。

ROUTE