Claude Codeの権限設定（パーミッション）｜allow・denyの書き方と、--dangerously-skip-permissionsの考え方【実機で確認・2026年10月】

2026年10月15日 20:25

「確認の画面が多すぎて、作業が進まない」。「でも全部許可にするのは怖い」。「.env だけは、絶対に読ませたくない」。Claude Code を使い込むと、こんな板挟みに出会います。

その答えが、権限設定（パーミッション）です。この記事では、権限の仕組み、ルールの書き方、モードの違い、そして確認を省く --dangerously-skip-permissions をどう考えるかを、実際に動かして確かめた結果とあわせて説明します。

私は Claude Code と Codex を毎日使って、教材づくり、note・Gumroad への出品、画像づくりを自動化しています。私の作業場は、権限の確認を省くモード（bypassPermissions）にしてあります。そのかわり、止めたいものは、ルールとフックで止めています（フックの使い方）。

この記事の内容は、読み物のために書いたものではなく、実際に動かして確かめたものです。Windows 11 の Claude Code（2.1.296）で、小さな試験用のフォルダを作り、モードごとの動き、deny のルール、確認を省くモードとの関係を、順に試しました。全文無料です。

この記事で分かること

権限の仕組み。何が確認なしで動き、何が確認になるのか
allow・ask・deny の3種類のルールと、書き方
6つのモード（default・acceptEdits・plan・auto・dontAsk・bypassPermissions）の違い
設定を書く場所と、強さの順
実機で確かめた結果（モード別の動き、deny が効く範囲、効かない範囲）
--dangerously-skip-permissions の考え方
自動実行（claude -p）でつまずく所

先に結論

権限のルールは、deny → ask → allow の順に調べられ、最初に当たったものが勝ちます。allow で、deny の例外を作ることはできません
ルールは、Claude Code が強制します。CLAUDE.md の「お願い」と違い、AI が守る気かどうかに関係なく、働きます
deny のルールは、確認を省くモード（bypassPermissions）でも効きます。実機でも、効きました
ただし、Read(./.env) の deny は、Python のスクリプトが .env を開くのは止めません。実機でも、ダミーの鍵が読み出せました。本当に守りたいなら、フックや置き場所、そして（WSL2・macOS・Linux では）サンドボックスを重ねます
claude -p（画面なしの実行）では、プロジェクトの .claude/settings.json に書いた allow は効きません。実機でも、効きませんでした。settings.local.json か --allowedTools に書きます
--dangerously-skip-permissions は、bypassPermissions と同じです。公式のドキュメントは、隔離されたコンテナや VM だけで使うよう書いています

権限の仕組み

Claude Code は、AI が何かをしようとするたびに、「確認なしでやってよいか」を判断します。公式のドキュメントでは、道具の種類によって、こうなります（確認が要るモードの場合）。

ファイルを読む：確認なし（作業フォルダの中）
コマンドを実行する（Bash）：確認あり。ただし、ls・cat・echo・grep・git の読み取り系など、確認なしで動かせる読み取り専用のコマンドがある
ファイルを変更する：確認あり
ウェブを取得する：確認あり。ただし、一部の公式ドキュメントのサイトは確認なし
ウェブ検索：確認あり

確認が出たとき、「はい、今後は聞かないで」を選ぶと、ルールが保存されます。後から見直したり、足したり消したりするのが /permissions です。どのルールが、どの設定ファイルから来たのかも、ここで分かります。

ルールの書き方

ルールは、ツール名かツール名(条件) の形で書きます。種類は3つです。

allow：確認なしで使ってよい
ask：必ず確認する
deny：使わせない

.claude/settings.json（または後で書く、ほかの設定ファイル）に、こう書きます。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Read(./.env)",
      "Bash(git push *)"
    ]
  }
}

条件の書き方の例

Bash：コマンドの実行を、すべて
Bash(npm run build)：そのコマンドだけ（npm run build --watch は別）
Bash(npm run *)：npm run で始まるもの全部。* は、空白を含む任意の文字
Read(./.env)：作業フォルダの .env を読むこと
Edit(src/**)：src の下のファイルの編集
WebFetch(domain:example.com)：そのドメインの取得
mcp__サーバー名__ツール名：MCP の道具（MCP の記事）

* と空白に注意

公式のドキュメントの、細かいけれど大事な点です。

Bash(ls *) は、ls -la と、ls だけの場合に合います。lsof には合いません（ls のあとの空白がルールの一部だから）
Bash(ls*) と空白なしで書くと、lsof にも合います
Bash(ls:*) と書いても、Bash(ls *) と同じです
* は、サブコマンドのあとに置きます。Bash(git *) は、すべての git コマンドを許してしまいます。Bash(git log *) なら、git log だけです

Windows のパス

Windows では、C:\Users\... のようなパスが、/c/Users/... の形に直されてから照合されます。公式のドキュメントでは、ドライブ全体の .env を指すには、//c/**/.env と書くとあります。

6つのモード

モードは、何を確認なしで動かすかの「土台」です。ルールは、その上に重ねます。公式のドキュメントでは、次のとおりです。

default（画面では「Manual」）：読み取りだけ確認なし。そのほかは確認
acceptEdits：読み取り、ファイルの編集、mkdir・touch・mv・cp などの簡単なファイル操作が確認なし
plan：読んで調べるだけ。ソースは編集しない。計画を作らせるモード
auto：確認なしで進める。ただし、裏でもう1つのAI（分類器）が、依頼に沿った動きかを点検する
dontAsk：確認が必要になる操作は、すべて自動で断る。事前に許可した道具だけが動く。画面のない自動実行や CI 向け
bypassPermissions：確認を、ほぼすべて省く。隔離されたコンテナや VM だけで使う

切り替え方は、次のとおりです。

画面のある使い方では、Shift+Tab で切り替えます（公式のドキュメントの記載）
起動時に決めるなら、claude --permission-mode acceptEdits のように指定します
いつも同じなら、settings.json の permissions.defaultMode に書きます

「auto」は、公式のドキュメントによると、v2.1.283 以降は、画面のある端末と VS Code で、最初から選ばれているモードです。この記事では、試していません。

設定を書く場所と、強さの順

設定ファイルは、場所によって効く範囲が違います。

~/.claude/settings.json：自分の全プロジェクト。自分のパソコンだけ
.claude/settings.json：そのプロジェクト。Git に入れれば、チームで共有される
.claude/settings.local.json：そのプロジェクトで、自分だけ。共有しない
組織の管理設定：いちばん強く、上書きできない

deny は、どこに書いても、ほかの場所の allow に勝ちます。たとえば、自分の設定で allow にしていても、プロジェクトの設定が deny なら、止まります。逆も同じです。コマンドラインの --allowedTools でも、管理設定の deny は破れません。

実機で確かめた結果

試験用に、小さなフォルダを作りました。.env（中身はダミーの API_KEY=dummy-key-1234）、notes.txt（買い物メモ）、src/app.py（print("hello") だけ）が入っています。.claude/settings.json には、こう書きました。

{
  "permissions": {
    "deny": ["Read(./.env)", "Bash(rm *)", "Bash(echo secret*)"]
  }
}

claude -p（画面なしの実行）で、モードを変えながら、AI に頼みました。結果は、AI の返事ではなく、ファイルが本当に変わったかと、実行の記録（拒否された理由）で確かめました。

1. モードごとの動き

「notes.txt の末尾に『牛乳』と1行追記して」と、同じ頼みを、モードを変えて出しました。

default：追記されませんでした。Edit の道具は「書き込みの権限が下りていない」、Bash の >> でも「出力のリダイレクトには承認が要る」と断られました。画面なしでは、確認する人がいないので、確認が要る操作は、そのまま止まります
acceptEdits：追記されました。ファイルは「買い物メモ」「牛乳」の2行になりました
plan：追記されず、AI は計画のファイルを書いただけでした。「プランモード中で、編集できるのはプランファイルだけ」という返事でした
dontAsk：notes.txt を読むことはできましたが、Edit は「don't ask モードのため拒否」と自動で断られました

2. deny が効く範囲

Read(./.env) を deny にして、.env を読ませようとしました。

Read の道具で読む：止まりました（「権限設定で拒否されたディレクトリのファイル」）
Bash の cat .env：止まりました（「cat .env の使用は拒否された」）。公式のドキュメントにも、cat・head・tail など、ファイルを読むと分かるコマンドにも、Read の deny が効くとあります

ここまでは、期待どおりです。次が、この記事で伝えたい点です。

src/show.py という、.env を開いて表示するだけの Python スクリプトを作り、「python src/show.py を実行して」と頼みました。python を許可した状態で、です。

結果は、API_KEY=dummy-key-1234 が、そのまま表示されました。

公式のドキュメントにも、同じことが書かれています。要約すると、「Read と Edit の deny は、組み込みのファイル道具と、cat など Claude Code が認識するコマンドに効く。Python や Node のスクリプトが自分でファイルを開く場合は、止めない。OS のレベルで止めるには、サンドボックスを有効にする」。

AI は、.env を Read で拒否されたあと、cat で回り込むことは、自分から断っていました（「権限設定を変えずに読む方法として、Bash で cat するなどの回避は行いません」と説明しました）。ただし、これはAI の行儀であって、仕組みの保証ではありません。私が「Python で読んで」と頼めば、読めました。

3. deny と確認を省くモード

bypassPermissions（確認を省くモード）で、rm victim1.txt を頼みました。Bash(rm *) が deny です。

rm victim1.txt：止まりました。ファイルは残りました
bash -c 'rm victim2.txt'：止まりました。「shell -c のスクリプトの中のコマンドに拒否ルールがあり、危険な削除かを確認できない」という理由でした
Read で .env：止まりました

つまり、deny は、確認を省くモードでも効きます。公式のドキュメントにも、要約すると「deny のルールは、bypassPermissions を含む全モードでブロックする。allow のルールは、bypassPermissions では効果がない」とあります。

なお、公式のドキュメントの表には、「Bash(rm *) は bash -c 'rm -rf build/' を止めない」と載っています。実機の2.1.296では、bash -c の中の rm も止まりました。版が上がって、見張りが強くなったのだと考えられます。ただ、これに頼らず、「コマンドの別の書き方は、すり抜けうる」と考えておくのが安全です。

4. deny は、確認なしの読み取りコマンドにも勝つ

echo は、確認なしで動く読み取り系のコマンドです。Bash(echo secret*) を deny にして、echo secret-1 と echo hello を頼みました。

echo secret-1：拒否されました
echo hello：実行されました

5. 画面なしの実行で、プロジェクトの allow が効かない

もう1つ、自動実行（claude -p）で、つまずきやすい点です。

プロジェクトの .claude/settings.json に、"allow": ["Bash(python *)"] を書いて、python src/show.py を頼みました。結果は、「このコマンドには承認が必要」でした。allow があるのに、止まりました。

原因は、公式のドキュメントにありました。プロジェクトの .claude/settings.json の allow は、そのフォルダを「信頼する」画面で承認してからでないと、効きません。そして、その画面は、claude -p では出ません。つまり、画面なしの実行では、プロジェクトの allow は、効きません。deny と ask は、制限するだけなので、影響しません。

直し方は、3つです。最初の2つは実機で試し、3つ目は公式のドキュメントの記載です。

allow を、.claude/settings.local.json に移す（共有しない、自分用の設定。git で追跡されていなければ、効きます）：動きました
コマンドラインで --allowedTools "Bash(python *)" を渡す：動きました
自分の全プロジェクトの設定（~/.claude/settings.json）に書く

6. 画面なしの自動実行の形：dontAsk ＋ allowedTools

公式のドキュメントは、dontAsk を「画面のない CI やスクリプト向け」としています。事前に許可した道具だけが動き、ほかは自動で断られるからです。必要な道具だけを --allowedTools で許可する形です。

claude -p "..." --permission-mode dontAsk --allowedTools "Bash(python src/app.py)"

これで試しました。「python src/app.py を実行して、出力を教えて。次に src/other.py を作って」と頼みました。

最初の試行は、実行できませんでした。AI が、cd "..." && ls ...; python src/app.py; echo ... と、いくつものコマンドをつないで呼んだため、許可のルール（python src/app.py だけ）に合わず、拒否されたのです
「cd や && をつながず、1つだけで実行して」と頼み直すと、hello が出力されました。src/other.py の作成は、Write が許可されていないので、拒否され、ファイルは作られませんでした

教訓は、2つです。許可は、AI が実際に打つ形に合わせること。そして、許可を狭くしすぎると、コマンドの形のゆれで、止まることです。公式のドキュメントでは、変わる部分を * にして書く形（Bash(python *) など）が基本です。そのかわり、許可の範囲が広がるので、deny や、フックと組み合わせます。

--dangerously-skip-permissions の考え方

名前に dangerously（危険に）とあるとおり、すべての確認を省くオプションです。--permission-mode bypassPermissions と同じ意味です。

公式のドキュメントは、こう書いています。

Only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage.

つまり、壊れても困らない、隔離された環境（コンテナ、VM）だけで使うものです。claude --help の説明も、「インターネットにつながらないサンドボックスでだけ推奨」という趣旨です。このモードでは、.git や .claude のような「保護された場所」への書き込みも、確認なしになります。

それでも、普段の PC で使う人がいるのは、確認が多すぎて、作業が進まないからです。私もそうです。使うなら、確認を省いたあとの安全網を、先に用意します。

deny のルール：確認を省くモードでも効く（実機で確認ずみ）。Read(./.env)、Bash(git push *)、Bash(rm *) など
フック：PreToolUse のフックで、危険なコマンドを止める。確認を省くモードでも効く（フックの記事で実機確認ずみ）
サンドボックス：OS のレベルで、シェルのコマンド（と、その子プロセス）のファイルとネットワークへのアクセスを制限する。/sandbox で入れる（標準では切れています）。公式のドキュメントでは、deny のルールでは止められない、Python などの読み取りも、設定で止められます。ただし、動くのは macOS・Linux・WSL2 だけです。Windows のネイティブでは、シェルのコマンドは、サンドボックスなしで動きます。私の環境（Windows 11 のネイティブ）では使えないので、この記事では試していません。Windows で使うなら、WSL2 の中で Claude Code を動かします
バックアップと Git：壊れても戻せるようにしておく
大事な鍵を、そもそも作業フォルダに置かない：.env を AI に読ませたくないなら、いちばん確実なのは、読める場所に置かないことです

もう1つ、公式のドキュメントにある、細かい注意です。画面のある端末で、確認を省くモードが使える状態だと、プランモードの「編集しない」は、強制されなくなります（AI は、編集しないよう指示されるだけ）。claude -p では、プランモードの制限は保たれます。

最初のおすすめ設定

まず、.claude/settings.json に、次のような形で始めるのが、現実的です（公式のドキュメントの書式にもとづく例です）。書いたら、実際に試して確かめてください。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(git push *)",
      "Bash(rm *)"
    ]
  }
}

読むだけのコマンドは、そもそも確認なしなので、allow に書く必要はありません。よく使う、実行系のコマンドだけを allow に足します
deny は、見られたくないファイルと、取り返しのつかないコマンドを、少なめに置きます
確認がうるさいときは、/fewer-permission-prompts というコマンドが、過去の記録から、よく使う読み取り系のコマンドを探して、プロジェクトの .claude/settings.json に許可のリストとして足してくれます（公式のドキュメントの一覧にあるコマンド。私は、この記事のためには試していません）

安全のために

deny は「うっかり」を防ぐ網であって、壁ではありません：コマンドの別の書き方や、スクリプトを経由した読み取りは、すり抜けうる。本当に守るものは、フックやサンドボックスを重ね、置き場所も考える
他人のリポジトリの .claude/settings.json は、開く前に中身を見る：許可やフックが書かれていることがある。公式のドキュメントでも、プロジェクトの allow は、信頼の確認をしてから適用する仕組みです
bypassPermissions を使うなら、deny とフックを先に
秘密の鍵を、AI に打ち明けない：.env の中身をチャットに貼らない

よくある疑問

Q. .env を完全に守るには？

1つの方法では、足りません。①Read(./.env) を deny にする、②フックで、.env に触れるコマンドを止める、③（WSL2・macOS・Linux なら）サンドボックスを有効にして、OS のレベルで止める、④そもそも、作業フォルダに実際の鍵を置かず、環境変数や別の場所を使う、を重ねます。Windows のネイティブでは、サンドボックスが使えないので、②と④が頼りです。

Q. 確認を、毎回聞かれるのが面倒です

「はい、今後は聞かないで」で、ルールが保存されます。よく使う実行系のコマンドを、allow に足します。それでも多いなら、acceptEdits（編集の確認を省く）を使い、deny を置く、という順で緩めるのが安全です。

Q. CLAUDE.md に「.env を読まないで」と書けば十分では？

足りません。公式のドキュメントにも、「権限のルールは、Claude Code が強制する。プロンプトや CLAUDE.md は、AI が何をしようとするかを方向づけるが、Claude Code が何を許すかは変えない」とあります。絶対に守らせたいことは、ルールかフックに書きます。

注意点

この記事の内容は、2026年10月15日の公式ドキュメントと、私の Windows 11 の環境（Claude Code 2.1.296）で確かめたものです。ルールの書式や挙動は、版が上がると変わることがあります。迷ったら /permissions と、公式のドキュメントを見てください
確かめたのは、claude -p（画面なしの実行）での動きです。画面のある使い方での確認の出方、Shift+Tab での切り替え、auto モード、サンドボックス（Windows のネイティブでは使えません）、ask のルール、管理設定は、試していません。公式のドキュメントの記載を紹介しています
試験は、小さな試験用フォルダで、1つずつ、少ない回数で行いました。AI の動き（どのコマンドで試すか）は毎回変わりますが、許可するか止めるかを決めるのは Claude Code 側です
.env の試験は、ダミーの値で行っています。実際の鍵では試さないでください

まとめ

権限のルールは、deny → ask → allow の順で調べられ、最初に当たったものが勝つ。Claude Code が強制するので、CLAUDE.md の「お願い」より強い
モードは、土台。default・acceptEdits・plan・auto・dontAsk・bypassPermissions。自動実行には dontAsk ＋ --allowedTools
deny は、確認を省くモードでも効く。実機でも、rm と .env の Read が止まった
でも、deny は壁ではない。実機でも、Python のスクリプト経由で、ダミーの .env が読めた。大事なものは、フック・置き場所・（使える環境なら）サンドボックスで守る。サンドボックスは、Windows のネイティブでは使えない
claude -p では、プロジェクトの settings.json の allow は効かない。settings.local.json か --allowedTools に書く
--dangerously-skip-permissions は、隔離された環境のためのもの。使うなら、deny とフックを先に置く

次の一歩は、deny に Read(./.env) を1行足して、AI に「.env を読んで」と頼み、本当に断られるかを見ることです。そして、その先に「何が、すり抜けるか」を、ダミーの値で試してみてください。10分で、できます。

次に読む

Claude Codeのフック（hooks）の使い方（無料）：確認を省くモードでも効く、止める仕組み
MCPとは？Claude Codeにつなぐ方法（無料）：MCP の道具の許可の書き方もつながります
AIエージェントとは（無料）：チャットAIとの違いと、安全な始め方
CLAUDE.mdの書き方（無料）：「お願い」を、短く具体的に書く方法
Claude Code テンプレート集（¥9,800）：権限セット4種・フック10本（動作確認済みスクリプト付き）・CLAUDE.md・スキル・プロンプト100本の実物パック

このアカウントをフォローすると、Claude Code や Codex の新しい手順の記事が届きます。ぜひフォローしてください。

この先で分かること（今後の有料記事）

そのままコピーして使える権限セットの実物（調査用・編集用・無人実行用）と、deny の選び方
無人の自動実行（claude -p）で、許可を狭く、止まらずに動かす設計
実際に起きた失敗と、直し方の記録

まさのAI実務ラボ｜Codex・Claude Code では、有料記事が読み放題になります。テンプレートや指示文をまとめて使いたい方はご覧ください。