Claude Codeの承認スキップ｜権限を絞る設定7つと戻し方

Q: Claude Codeの承認スキップは危険ですか？

やり方によります。permissions.allowで対象を名指しする形なら、書いていない操作は今までどおり確認が出るため、日常の開発でも使えます。危険なのは--dangerously-skip-permissionsとbypassPermissionsで、公式が隔離されたコンテナやVMでのみ使うよう警告している方法です。

Q: settings.jsonはどこに置けばいいですか？

共有したいルールはリポジトリの.claude/settings.json、自分の手元だけなら.claude/settings.local.json、全案件共通なら~/.claude/settings.jsonです。優先順位は管理設定、コマンドライン引数、ローカルプロジェクト設定、共有プロジェクト設定、ユーザー設定の順で、どのレベルの拒否も他のレベルでは解除できません。

Q: allowに入れたのに毎回聞かれるのはなぜですか？

よくある原因は3つあります。1つ目は同じ呼び出しにマッチするaskかdenyのルールが先に当たっていること、2つ目は複合コマンドでサブコマンドごとのルールが揃っていないこと、3つ目はワークスペースの信頼ダイアログを受け入れていないためプロジェクトのallowが適用されていないことです。/permissionsで取得元まで確認すると切り分けられます。

Q: --dangerously-skip-permissionsと--allow-dangerously-skip-permissionsは何が違いますか？

前者は起動した時点でbypassPermissionsに入り、すべての権限プロンプトをスキップします。後者はShift+TabのモードサイクルにbypassPermissionsを追加するだけで、起動時には有効になりません。claude --permission-mode plan --allow-dangerously-skip-permissionsのように、別のモードで始めて後から切り替える使い方になります。

Q: チーム全員に同じ制限をかけられますか？

かけられます。管理設定は、ユーザー設定やプロジェクト設定では上書きできないポリシーです。allowManagedPermissionRulesOnlyをtrueにすれば、ユーザーとプロジェクトの設定がallow・ask・denyを定義すること自体を止められます。バイパスとオートを塞ぐなら、disableBypassPermissionsModeとdisableAutoModeを"disable"にしてください。

Q: 承認スキップにするとMCPツールも自動で通りますか？

MCPツールはmcp__<サーバー名>__<ツール名>の形でルールを書きます。denyにmcp__*を入れれば全サーバーを止められますが、allow側ではmcp__*のようなアンカーのない書き方は警告付きでスキップされ、自動承認されません。また、組織がaskに設定したコネクタツールはbypassPermissionsでも確認が出ます。

Claude Codeに作業を任せていると、コマンドのたびに「これを実行していいですか」と止まります。承認スキップを調べて最初に出てくる--dangerously-skip-permissionsは、確認を全部飛ばす代わりに、公式ドキュメントが隔離環境限定と明記しているとおり危険です。落としどころは、settings.jsonのpermissionsで通すものと止めるものを名指しし、確認が要る操作だけを残す形です。この記事では、承認が出る条件、承認を減らす設定7つ、事故につながるallowの書き方、サイト制作と自社ツール開発での設定例、そして設定を元に戻す手順まで、Anthropic公式ドキュメントの表記どおりにまとめます。

この記事の要点

承認スキップのやり方は3つです。permissions.allowで対象を名指しする、権限モードで確認の出方を変える、--dangerously-skip-permissionsで全部飛ばす、の順に危険度が上がります。
権限ルールはdeny→ask→allowの順で評価され、最初に当たったものが結果を決めます。ルールの細かさで順番は変わらないため、止めたいものはdenyに置くのが確実です。
bypassPermissionsは.gitや.claudeへの書き込みまで確認なしで通します。公式は、Claude Codeが損害を出せないコンテナやVMでのみ使うよう警告しています。

01Claude Codeの承認スキップとは｜3つのやり方と違い

Claude Codeの承認スキップとは、ツールを実行する前に出る権限プロンプトを出さずに処理を進めさせることです。やり方は3つあり、通す範囲と危険度がはっきり違います。編集部が公式ドキュメントで確認した範囲では、日常の開発で使ってよいのは1つ目と2つ目で、3つ目は隔離環境専用という位置づけになっています。

承認はどの操作で出るのか？

ファイルの読み取りやGrepでは承認は出ません。承認が出るのはBashなどのコマンド実行と、Edit・Writeによるファイル変更です。Claude Codeはls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd、そしてgitの読み取り専用形を「読み取り専用コマンド」として組み込みで持っており、これらはどのモードでも確認なしに走ります。例外はpermissions.blockReadsOutsideWorkingDirectoriesで囲ったパスだけです。一覧そのものは設定で変えられないため、この中の1つに確認を出したいときはaskかdenyのルールを足します。つまり、あなたが今止められている確認は、ほぼコマンド実行とファイル変更の2種類だと考えて差し支えありません。

承認を減らすやり方は3つあります

3つは排他ではなく、下に行くほど雑になると考えると選びやすくなります。

①settings.jsonのallowで通すコマンドを名指しする

permissions.allowにBash(npm run build)のようなルールを書くと、その呼び出しだけが確認なしで通ります。書いていないものは今までどおり確認が出るため、事故の届く範囲が広がりません。この記事が中心に扱うのはこの形です。

②権限モードで確認の出方を切り替える

acceptEditsならファイル編集とmkdir・touch・rm・rmdir・mv・cp・sedが自動で通り、planなら読み取りと調査だけに限定されます。モードはセッション中にShift+Tabで切り替えられ、設定ファイルではdefaultModeで決めます。

③–dangerously-skip-permissionsで全部飛ばす

claude --dangerously-skip-permissionsは--permission-mode bypassPermissionsと同じ意味で、権限プロンプトそのものを出しません。公式は隔離された環境でのみ使うよう警告しています。理由は次の章で具体的に見ていきます。

権限モードは6つあり、承認スキップに関わるのは3つです

権限モードはdefault（UIの表示は「Manual」）、acceptEdits、plan、auto、dontAsk、bypassPermissionsの6つです。6つを並べた比較表とモードごとの使い分けはClaude Codeの権限モード完全ガイドにまとめているため、この記事では承認スキップに直接関わる3つだけを扱います。acceptEditsはファイル編集まわりを自動で通し、dontAskは事前に許可したもの以外を確認せずに拒否し、bypassPermissionsは権限プロンプトそのものを出しません。3つの具体的な書き方は後述の設定6と設定7で挙げます。

autoが既定に変わった経緯と、任せてよい場面の線引きはClaude Codeのオートモードが既定になった件で詳しく書いています。読み取りだけに絞りたいときのplanの挙動はClaude CodeのPlan Modeの使い方をご覧ください。

02全部スキップはなぜ常用してはいけないのか？

プロンプトインジェクションやモデルの勘違いが起きたときに、間に入って止めるものが1つも残らないからです。公式ドキュメントはbypassPermissionsについて、Claude Codeが損害を引き起こせないコンテナやVMなどの隔離された環境でのみ使うよう明記しています。

bypassPermissionsで通ってしまうもの

見落としやすいのは設定ファイルへの書き込みです。公式の警告には、.git、.config/git、.claude、.vscode、.idea、.husky、.cargo、.devcontainer、.yarn、.mvnへの書き込みが含まれると書かれています。つまりこのモードでは、Claude Code自身の権限設定やGitフックを確認なしで書き換えられる状態になります。安全のために置いたはずのルールを、走っている本人が消せてしまう構図です。

それでも残るプロンプトが6種類あります

ただし、このモードでも消えない確認があります。公式ドキュメントは「どのモードでも自動承認しない操作」として、次の6つを挙げています。

明示的なaskルールに当たったツール
組織がaskに設定したコネクタツール
ユーザーの操作を求めるツール。組み込みのAskUserQuestionと、requiresUserInteractionが付いたMCPツールの両方が入ります
重要なパスを対象にしたrm・rmdirの削除
セッションをまたぐメッセージの保護。別のセッションから届いたメッセージは、承認なしでは渡されません
permissions.blockReadsOutsideWorkingDirectoriesを有効にしているときの、作業ディレクトリの外にあるファイルの読み取り（Claude Code v2.1.257以降）

4番目の削除は、モデルの誤りに対する回路遮断器という位置づけです。allowルールでもPreToolUseフックの"allow"でも承認できません。重要なパスとして扱われるのは、ファイルシステムルートとその直下のディレクトリ、ホームディレクトリ、Windowsのドライブルートとその直下、そして作業ディレクトリとその親です。$(...)やバッククォートのコマンド置換、<(...)のプロセス置換に隠しても、判定は変わりません。

裏を返せば、守ってくれるのはこの6つだけです。プロジェクトのnode_modulesを消す、リモートへ強制pushする、環境変数を外部に送る——このあたりは何も出ずに通ります。

全部スキップと、allowで絞る形の違い

全部スキップ
bypassPermissions

確認：ほぼゼロ
事故の届く範囲：マシン全体
止まるもの：askなど上の6項目のみ

／

allowで絞る
permissions.allow ＋ deny

確認：書いていないものだけ
事故の届く範囲：許可した操作の中
止まるもの：deny全件＋未登録の全操作

FIG.1　同じ「承認を減らす」でも、失敗したときに届く範囲が変わります

03承認を減らす設定7つ｜allowとdenyの絞り方

ここからは、編集部がこの記事で推奨する順序で7つ挙げます。上から順に足していくと、危ない設定を先に固めてから許可を広げる形になります。

設定1｜/permissionsで今のルールを確認する

最初にやるのは追加ではなく確認です。セッション中に/permissionsを実行すると、いま適用されているallow・ask・denyの全ルールと、それぞれがどのsettings.jsonから来ているかが一覧で出ます。「許可したはずなのに聞かれる」の原因はほぼここで判明します。

設定2｜読み取りとテスト・ビルドをallowに入れる

毎回止まって困るのは、たいてい同じ数種類のコマンドです。テスト、ビルド、フォーマッタ、git statusまわり。この単位で名指しします。

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Read"
    ]
  }
}

ルールの形はToolまたはTool(specifier)です。括弧を付けなければそのツールの全使用にマッチし、Bash(*)はBashと同じ意味になります。

設定3｜破壊系と外部送信をdenyで固定する

allowを広げる前に、denyを置きます。権限ルールはdeny→ask→allowの順に評価され、最初に当たったものが結果を決めるためです。ルールが細かいかどうかで順番は入れ替わりません。Bash(aws *)のような広いdenyは、Bash(aws s3 ls)という狭いallowにマッチする呼び出しもまとめてブロックします。

{
  "permissions": {
    "deny": [
      "Bash(git push *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(.env)",
      "Edit(.env)"
    ]
  }
}

なお、Readのdenyルールは、同じパスのEditツールとWriteツールにも適用されます。そのパスに新しいファイルを作る操作も止まります。カバーされないのはNotebookEditだけなので、どのツールにも書き換えさせたくないパスにはEditのdenyを並べて書いておきます。編集への適用はClaude Code v2.1.208以降、書き込みへの適用はv2.1.228以降です。

もう1点、Read・Editのdenyが届くのは組み込みのファイルツールと、cat・head・tail・sedなどClaude Codeが認識するファイルコマンドまでです。PythonやNodeのスクリプトが自分でファイルを開く経路には届きません。そこまで塞ぐならOSレベルのサンドボックスを併用します。

権限ルールが評価される順番

deny
当たったら実行しない

▶

ask
当たったら必ず確認

▶

allow
当たったら確認なし

▶

権限モード
どれにも当たらないとき

最初に当たったルールが結果を決める／ルールの細かさで順番は変わらない

FIG.2　止めたいものはallowを細かく書くのではなく、denyに置きます

設定4｜判断に迷う操作はaskに残す

allowかdenyかで迷ったものは、消さずにaskへ入れます。askにマッチした呼び出しは、同じ呼び出しにより具体的なallowルールがあっても確認が出る仕様です。「基本は通すが、この形だけは目で見たい」という運用がこれで組めます。デプロイ、マイグレーション、本番向けのgit pushあたりが典型です。

設定5｜プロジェクト単位とローカル単位を分ける

設定ファイルには優先順位があり、上のものを下から上書きすることはできません。チームで共有したいルールはリポジトリの.claude/settings.json、自分の手元だけで通したいものは.claude/settings.local.json、どの案件でも共通のdenyは~/.claude/settings.jsonという置き分けになります。

設定の優先順位（上が強い）

1. 管理設定　組織が配布。コマンドライン引数でも上書きできない

2. コマンドライン引数　--allowedTools など、そのセッションだけ

3. .claude/settings.local.json　自分の手元だけの設定

4. .claude/settings.json　リポジトリで共有する設定

5. ~/.claude/settings.json　全プロジェクト共通のユーザー設定

どのレベルで拒否されても、他のレベルが許可することはできません

FIG.3　denyはどこに書いても勝つため、共通の禁止事項はユーザー設定に置けます

1つ注意点があります。プロジェクトの.claude/settings.jsonにあるallowルールとadditionalDirectoriesは、そのワークスペースの信頼ダイアログを受け入れたあとにしか適用されません。deny・askは制限しかしないため、この影響を受けません。クローンしてきたリポジトリでallowが適用されないときは、まずここを疑います。

設定6｜編集の確認だけacceptEditsで外す

コマンドは今までどおり確認したいが、ファイル編集のたびに止まるのは避けたい——という場面では、モードをacceptEditsにします。作業ディレクトリとadditionalDirectoriesの中に限って、ファイル編集とmkdir・touch・rm・rmdir・mv・cp・sedが自動で通ります。起動時に指定するなら次の形です。

claude --permission-mode acceptEdits

名前から受ける印象と違う点が1つあります。自動承認されるのは編集だけではなく、rmとrmdirによる削除も入ります。作業ディレクトリの中なら、確認なしでファイルもディレクトリも消えます。止まるのは、作業ディレクトリそのものやその親を消そうとしたときだけです。案件フォルダの中にあるファイルやサブディレクトリは、確認を挟まずに消えます。sedも同じ扱いなので、置換の失敗がそのまま上書きとして残ります。

消えて困るものを抱えたまま使うモードではありません。使う前にコミットを済ませておくか、消させたくないパスをdenyに入れておきます。

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(rmdir *)"
    ]
  }
}

設定7｜無人実行はdontAskと事前許可で走らせる

CIや定期実行のように人が画面を見ていない環境では、bypassPermissionsではなくdontAskを選びます。事前に許可されていないツールは、確認を出さずに自動で拒否されるモードです。止まらないという性質は同じで、想定外の操作が通らない点だけが違います。

claude --permission-mode dontAsk --allowedTools "Bash(npm run build)" "Bash(npm run test *)" "Read"

定期実行そのものの組み方はClaude Codeの定期実行をcronで自動化する方法にまとめています。

04やってはいけないallowの書き方

allowの書き方は、承認スキップでいちばん事故が起きやすい場所です。1文字違うだけで、通したつもりのない操作まで通ります。公式ドキュメントが名指しで注意している型を4つ挙げます。

危ない書き方	通ってしまうもの	代わりに書くもの
`Bash(curl http://github.com/ *)`	`curl -X GET`、`https://`、短縮URLからのリダイレクト、変数に入れてからの呼び出し	`curl`と`wget`をdenyにして、`WebFetch(domain:github.com)`を許可する
`Bash(ls*)`	`lsof`など、`ls`で始まる別のコマンド	`Bash(ls )`と、``の前にスペースを入れる
`Bash(devbox run *)`	`devbox run rm -rf .`のように、内側に置いた任意のコマンド	`Bash(devbox run npm test)`と、内側のコマンドまで書き切る
ユーザー設定に書いた`Read(/secrets/**)`	守りたいプロジェクト内の`secrets`は無防備のまま、`~/.claude/secrets/**`だけがブロックされる	`Read(//secrets/)`の絶対パスか、`Read(~/secrets/)`のホーム相対

FIG.4　いずれも「絞ったつもり」で通ってしまう型です（公式ドキュメントの注意記述より）

コマンドの引数でallowを絞ろうとする

公式は「コマンド引数を制約しようとするBash権限パターンは脆弱です」と明記しています。例として挙がっているのがBash(curl http://github.com/ *)で、GitHubのURLだけに限定したつもりでも、URLの前にオプションが入るcurl -X GET、プロトコルが違うhttps://、短縮URLからのリダイレクト、変数に入れてから呼ぶ形、余分なスペースには、どれもマッチしません。URLを絞りたいなら、curlとwgetをdenyでブロックし、WebFetch(domain:github.com)を許可してWebFetchツールを使わせるのが公式の推奨です。

なおCLAUDE.mdに「このコマンドだけ使ってよい」と書く方法は、Claudeが何をしようとするかを形づくるだけで、境界そのものは強制しません。CLAUDE.mdの書き方はCLAUDE.mdが守られない原因と書き方で扱っていますが、権限の壁としては数えないでください。

ワイルドカードの前のスペースを省く

*の前のスペースには意味があります。Bash(ls *)はls -laにマッチしますがlsofにはマッチしません。一方でBash(ls*)は単語境界の制約がないため、lsofにもマッチします。1文字の違いで、意図していないコマンドまで自動承認される形です。末尾のワイルドカードはBash(ls:*)と書いても同じ意味になります。

複合コマンドとラッパーを1本のルールで通そうとする

Claude Codeはシェルの区切り文字を認識するため、Bash(safe-cmd *)があってもsafe-cmd && other-cmdは通りません。区切りとして扱われるのは&&、||、;、|、|&、&、改行です。ルールはサブコマンドごとに独立してマッチさせる必要があります。

逆に危ないのがラッパーの扱いです。timeout、time、nice、nohup、stdbufは照合前に取り除かれるため、Bash(npm test *)はtimeout 30 npm testにもマッチします。ところがdirenv exec、devbox run、mise exec、npx、docker execはこのリストに入っていません。これらは引数をコマンドとして実行するため、Bash(devbox run *)と書くとdevbox run rm -rf .まで自動承認されます。環境ランナーを許可するときは、Bash(devbox run npm test)のように内側のコマンドまで書き切ってください。

ユーザー設定に先頭スラッシュのパスを書く

Read・Editのパターンはgitignore仕様に従い、アンカーが4種類あります。//pathはファイルシステムルートからの絶対パス、~/pathはホームディレクトリ、/pathは設定ファイル自身からの相対、pathはカレントディレクトリからの相対です。ここを取り違えると、~/.claude/settings.jsonに書いたRead(/secrets/**)は、プロジェクト内のsecretsではなく~/.claude/secrets/**をブロックします。全プロジェクトに適用したいdenyは、//の絶対パスか~/のホーム相対で書きます。

05用途別の設定例｜サイト制作と自社ツール開発

案件の性質で、通してよいものは変わります。ここでは代表的な2パターンを挙げます。

サイト制作・LP制作での設定例

ビルドとプレビューは自動で通し、公開に関わる操作だけ手元に残す形です。

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run dev)",
      "Bash(npx prettier *)",
      "Edit(/src/**)",
      "Read"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(vercel *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Read(.env)",
      "Edit(.env)"
    ]
  }
}

Edit(/src/**)はプロジェクトルート配下のsrcを指します。.claude/settings.jsonに書いた/pathはプロジェクトルートにアンカーされるためです。

自社ツール開発・定期実行での設定例

無人で回す側は、通すものを増やすより、拒否を厚くするほうが安全です。MCPツールを全部止めるなら、denyにmcp__*を1行入れます。

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Read"
    ],
    "deny": [
      "Bash(git push *)",
      "mcp__*",
      "Read(//**/.env)"
    ],
    "disableBypassPermissionsMode": "disable"
  }
}

Read(//**/.env)はファイルシステム上のどこにある.envでも読ませません。素性の分からないリポジトリを読ませる場面では、ツール自体を外す方法もあります。詳細はClaude Codeの制限モード（–restricted）の解説をご覧ください。

06承認スキップの設定を元に戻すには？

戻し方は3段階あります。今のセッションだけ戻す、設定ファイルから消す、そもそも選べなくする、の順に強くなります。

戻し方	操作・設定	どこまで戻るか	使う場面
今のセッションだけ	`Shift+Tab` で `default` へ／`claude --permission-mode default`	このセッションのみ。設定ファイルは変わらない	一時的に緩めた作業を終えたとき
保存されたルールを消す	`/permissions` で取得元を確認し、そのファイルの `allow` から該当行を削除	そのルールが恒久的に無くなる	「今後は聞かない」を押しすぎたとき
モードごと封じる	`permissions.disableBypassPermissionsMode` を `"disable"`（`disableAutoMode` も同様）	選択肢そのものが消える	自分や組織を確実にロックしたいとき

図: 承認スキップを戻す3つの方法（設定名はClaude Code公式ドキュメントより）

今のセッションだけ戻す

Shift+Tabで権限モードのサイクルを回し、default（UI表示は「Manual」）に戻します。起動しなおすならclaude --permission-mode defaultです。設定ファイルのdefaultModeはコマンドライン引数で上書きできます。

保存されたルールを削除する

権限ダイアログで「はい、今後は聞かない」を選ぶと、その時点でルールが書き込まれます。どのファイルに入ったかは/permissionsの一覧に取得元として表示されるので、そのファイルのallow配列から該当行を消します。複合コマンドを承認した場合、1回の承認でサブコマンドごとのルールが最大5本保存されることがあるため、1行消して終わりにせず一覧で確認してください。

バイパスモードを選べなくする

いちばん確実なのは、モードそのものを封じる設定です。permissions.disableBypassPermissionsModeを"disable"にするとbypassPermissionsが選べなくなり、permissions.disableAutoModeも同じ書き方でautoを止められます。組織の管理設定に置くのが本来の用途ですが、任意のスコープで動くため、自分の~/.claude/settings.jsonに書いて自分自身をロックアウトする使い方もできます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

FAQよくある質問

Claude Codeの承認スキップは危険ですか？

やり方によります。permissions.allowで対象を名指しする形なら、書いていない操作は今までどおり確認が出るため、日常の開発でも使えます。危険なのは--dangerously-skip-permissionsとbypassPermissionsで、公式が隔離されたコンテナやVMでのみ使うよう警告している方法です。

settings.jsonはどこに置けばいいですか？

共有したいルールはリポジトリの.claude/settings.json、自分の手元だけなら.claude/settings.local.json、全案件共通なら~/.claude/settings.jsonです。優先順位は管理設定、コマンドライン引数、ローカルプロジェクト設定、共有プロジェクト設定、ユーザー設定の順で、どのレベルの拒否も他のレベルでは解除できません。

allowに入れたのに毎回聞かれるのはなぜですか？

よくある原因は3つあります。1つ目は同じ呼び出しにマッチするaskかdenyのルールが先に当たっていること、2つ目は複合コマンドでサブコマンドごとのルールが揃っていないこと、3つ目はワークスペースの信頼ダイアログを受け入れていないためプロジェクトのallowが適用されていないことです。/permissionsで取得元まで確認すると切り分けられます。

–dangerously-skip-permissionsと–allow-dangerously-skip-permissionsは何が違いますか？

前者は起動した時点でbypassPermissionsに入り、すべての権限プロンプトをスキップします。後者はShift+TabのモードサイクルにbypassPermissionsを追加するだけで、起動時には有効になりません。claude --permission-mode plan --allow-dangerously-skip-permissionsのように、別のモードで始めて後から切り替える使い方になります。

チーム全員に同じ制限をかけられますか？

かけられます。管理設定は、ユーザー設定やプロジェクト設定では上書きできないポリシーです。allowManagedPermissionRulesOnlyをtrueにすれば、ユーザーとプロジェクトの設定がallow・ask・denyを定義すること自体を止められます。バイパスとオートを塞ぐなら、disableBypassPermissionsModeとdisableAutoModeを"disable"にしてください。

承認スキップにするとMCPツールも自動で通りますか？

MCPツールはmcp__<サーバー名>__<ツール名>の形でルールを書きます。denyにmcp__*を入れれば全サーバーを止められますが、allow側ではmcp__*のようなアンカーのない書き方は警告付きでスキップされ、自動承認されません。また、組織がaskに設定したコネクタツールはbypassPermissionsでも確認が出ます。

07まとめ：どこまで絞れば止まらずに済むか

判断の基準はひとつです。「この操作が誤って走ったとき、自分で戻せるか」。戻せるものはallowへ、戻せないものはdenyへ、迷うものはaskへ置きます。この3つの箱に振り分けるだけで、毎日ぶつかる確認の大半は消えます。全部を飛ばすモードは、壊れても捨てられるコンテナやVMの中でだけ使ってください。

最初の一歩としては、/permissionsで今のルールを見て、テストとビルドの2本をallowに入れ、Bash(git push *)とRead(.env)をdenyに入れるところから始めるのが失敗しにくい進め方です。そのうえで確認がまだ多いと感じたら、オートモードの既定化と戻し方で自動承認の範囲を確かめ、素性の分からないコードを扱うときは制限モードと権限モードの違いまで見ておくと、案件ごとの落としどころが決めやすくなります。

08出典

Anthropic「Configure permissions」（権限ルール構文・評価順・設定の優先順位・ReadのdenyがEditとWriteに及ぶ点を編集部が確認）https://code.claude.com/docs/en/permissions
Anthropic「Choose a permission mode」（どのモードでも自動承認されない6項目、acceptEditsが自動承認するコマンド、重要なパスの定義を編集部が確認）https://code.claude.com/docs/en/permission-modes
Anthropic「CLI リファレンス」（–permission-mode／–allowedTools／–dangerously-skip-permissions の記述を確認）https://code.claude.com/docs/ja/cli-reference
Anthropic「設定」https://code.claude.com/docs/ja/settings
Anthropic「サンドボックス」https://code.claude.com/docs/ja/sandboxing
本記事の事実確認は英語版ドキュメントで行っています。日本語版は反映が遅れている箇所があり、たとえばReadのdenyがWriteにも及ぶ点は、2026年9月4日時点で英語版にのみ記載があります。