2026年10月6日時点の公式ドキュメントで確認した結論から書く。Claude Codeで許可を毎回聞かれるなら、最初に見るのは設定ファイルではなく、いま動いているモードだ。v2.1.283以降、端末とVS Code拡張で始めたセッションの組み込みの既定は auto モードで、確認の多くは別の分類器モデルが代わりに判断する。それでも毎回聞かれるのは、セッションが Manual（設定値は default）で動いているか、どのモードでも確認が残る操作に当たっているかのどちらかだ。
減らし方は4段階ある。よく使うコマンドを allow ルールで個別に許可する、ファイル編集だけを acceptEdits で通す、auto に任せる、隔離した環境でだけ bypassPermissions で全部通す。下に行くほど確認は減り、事故を止める網も粗くなる。ここを順に押さえれば、「すべて許可」に飛びつかずに確認の回数を減らせる。
この記事の要点
- 既定：v2.1.283以降、端末とVS Code拡張は auto で始まる。
⏸ manual mode onなら Manual。 - 聞かれ方の差：Bashの許可はリポジトリとコマンドごとに保存、ファイル編集の許可はセッション終了まで。
- 個別に許可：
/permissionsか「Yes, and don’t ask again」。判定は deny → ask → allow の順。 - ファイル編集だけ通す：acceptEdits（Manual から
Shift+Tabを1回）。 - すべて許可：bypassPermissions はコンテナやVMの中だけで使う。
- 対象読者：Claude Codeを毎日使う開発者、チームの設定を決めるテックリード。
- 今日やること：
/permissionsでルールと保存先を確認する。
まず確認｜いま何モードで動いているか
許可の確認が多すぎると感じたら、ルールを書き足す前にモードを確かめる。モードが違えば、同じルールでも確認の出方が変わるからだ。
状態表示でモードを見る
入力欄の下の状態表示にモードが出る。Manual なら灰色の ⏸ manual mode on、ほかは ⏵⏵ accept edits on、⏸ plan mode on、⏵⏵ auto mode on と表示される。Shift+Tab を押すとモードが切り替わり、auto からは1回目で Manual に移り、その後は Manual → acceptEdits → plan の順に回る。auto が使える環境なら、plan の後に auto が戻ってくる。
6つのモードと確認なしで通るもの
公式の「Choose a permission mode」は、モードごとに確認なしで実行される範囲を次のように整理している（Claude Code公式ドキュメント）。
| モード | 確認なしで通るもの | 向いている場面 |
|---|---|---|
default（Manual） |
読み取りだけ | 一つずつ確かめたい作業、機密性の高い作業 |
acceptEdits |
読み取り、ファイル編集、よく使うファイル操作コマンド | 編集を後から差分で見直す作業 |
plan |
読み取り（auto が使える時は分類器が通したコマンドも） | 変更前にコードを調べる段階 |
auto |
すべて（裏で安全確認が入る） | 長い作業、確認の多さに疲れた時 |
dontAsk |
読み取りと事前に許可したツール。確認が要るものは拒否 | 締め付けたCIやスクリプト |
bypassPermissions |
すべて | 隔離したコンテナとVMだけ |
セッションが始まるモードの決まり方
端末で新しいセッションを始める時、Claude Codeは次の順で最初に当てはまったものを使う。
- 起動時の
--permission-modeフラグ、または--dangerously-skip-permissions - 設定ファイルの
permissions.defaultMode - 組み込みの既定
組み込みの既定は、v2.1.283以降なら端末でもVS Code拡張でも、全プラン・全接続先で auto だ。それより前のバージョンでは、Pro・Max・Teamの条件を満たすセッションだけが auto で始まり、それ以外は Manual だった。なお2026年10月6日時点で、GitHubのCHANGELOGに載っている最新版は v2.1.291 だ（Claude Code CHANGELOG）。
auto にならず Manual で始まる主な理由
auto が選ばれても、そのセッションで auto が使えなければ Manual で始まる。公式ドキュメントに書かれている主な原因は次のとおりだ。
- どこかの設定ファイルで
disableAutoModeが"disable"になっている - 使っているモデルが auto の対象外（Anthropic API では Opus 4.6以降、Sonnet 4.6以降、Fableモデルが対象。Amazon Bedrockなどの接続先では対象がさらに絞られる）
- 設定ファイルの
defaultModeが"default"（Manual）になっている。逆に"auto"を.claude/settings.jsonか.claude/settings.local.jsonに書いても効かず、組み込みの既定が使われる claude -pや Agent SDK で動かしている（機能フラグを取得するセッションでは既定がdefault）- Anthropic側で auto が止められている
許可の聞かれ方は操作の種類で違う
「さっき許可したのに、また聞かれた」の多くは、操作の種類ごとに許可の続く長さが違うことで説明がつく。公式の「Configure permissions」にある表を訳すと次のとおりだ（Manual モードの場合・Claude Code公式ドキュメント）。
| 操作の種類 | 確認が要るか | 「Yes, and don’t ask again」の効き方 |
|---|---|---|
| 読み取り専用（ファイルの読み取り、Grep） | 作業ディレクトリと追加ディレクトリの中なら不要 | 該当なし |
| Bashコマンド | 要る（組み込みの読み取り専用コマンドは除く） | リポジトリとコマンドごとに永続 |
| ファイルの変更（編集・書き込み） | 要る | セッションが終わるまで |
| Webの取得（WebFetch） | 要る（事前承認済みのドキュメントのドメインは除く） | リポジトリとドメインごとに永続 |
| Web検索 | 要る | リポジトリごとに永続 |
「今後は聞かない」はどこに保存されるか
Bashコマンドの確認画面には、Yes、「Yes, and don’t ask again for: npm test *」のような今後は聞かない選択肢、auto が使える時の「Yes, and switch to auto mode」、No が並ぶ。今後は聞かないを選ぶと、ルールはgitリポジトリの直下の .claude/settings.local.json に保存され、そのリポジトリのどのサブディレクトリやworktreeで始めたセッションにも効く。この保存先になったのは v2.1.211 からで、それより前は起動したディレクトリに保存されていた。
ファイル編集の許可はファイルに保存されず、セッションが終わると消える。毎朝ファイル編集を聞かれるのはこのためだ。また、確認画面が「その選択肢で何を許すか」を全部表示できない時は、1回だけの許可しか出ない。その場合は後述の /permissions から自分でルールを足す。
方法1｜allowルールでよく使うコマンドを個別に許可する
確認を減らす最初の手は、毎回許可しているコマンドを allow ルールにすることだ。モードを変えないので、残りの操作には今までどおり確認が出る。
/permissions でいまのルールを見る
/permissions を実行すると、すべてのルールと、それぞれがどの settings.json から来ているかの一覧が開く。ここでルールを足したり消したりできる。Claudeが作業している最中でも開けて、v2.1.234以降は追加や削除がその次のツール呼び出しから効く。ルールには3種類ある。
- allow：確認なしで使わせる
- ask：使うたびに確認する
- deny：使わせない
ルールの書き方とワイルドカード
ルールは ツール名 か ツール名(指定) の形で書く。公式ドキュメントの例を使うと、npmのスクリプトとgitのコミットは確認なしで通し、git push で始まるコマンドは拒否する設定は次のようになる。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
"deny": [
"Bash(git push *)"
]
}
}
* は空白も含めて任意の文字列に当たる。公式の表から抜き出すと、当たり方は次のとおりだ。
| 書き方 | 当たる | 当たらない |
|---|---|---|
Bash(npm run build) |
npm run build |
npm run build --watch |
Bash(npm run *) |
npm run build、npm run test --watch、npm run |
npm install |
Bash(ls *) |
ls -la、ls |
lsof |
Bash(ls*) |
ls -la、lsof |
なし |
書く時に外せない3つの決まり
*はサブコマンドの後ろに置く：Bash(git log *)はgit logだけを許すが、Bash(git *)は git のすべてのコマンドを許す。Bash(git * main)のようにサブコマンドより前に*を置いた allow ルールには、起動時に警告が出る。- つないだコマンドは1つずつ判定される：
&&、||、;、|などでつないだコマンドは、それぞれがルールに当たらないと通らない。Bash(npm *)を許可していても、npm test && 別のコマンドの後半は別に判定される。 - 末尾の
:*は*と同じ：Bash(ls:*)はBash(ls *)と同じ意味になる。確認画面から保存されるルールは空白区切りの形で書かれる。
どのファイルに書くか
ルールを書く場所で、効く範囲が変わる（Settings files and precedence）。
| ファイル | 効く範囲 | 置くもの |
|---|---|---|
~/.claude/settings.json |
自分の、このマシンのすべてのプロジェクト | 自分だけの許可、既定のモード |
.claude/settings.json |
そのプロジェクトの全員（gitで共有） | チームで揃えるルール |
.claude/settings.local.json |
そのプロジェクトの自分だけ | 確認画面から保存されたルール |
| 管理設定（managed settings） | 組織の全員。ほかの設定から上書きできない | 組織の禁止事項 |
プロジェクトの .claude/settings.json にある allow ルールは、そのフォルダのワークスペース信頼のダイアログを受け入れるまで効かない。ダイアログには、そのフォルダが与えようとしているルールが並ぶので、知らないリポジトリでは中身を見てから受け入れる。設定ファイルの階層と書き方の全体はsettings.json設定ガイドにまとめている。
deny → ask → allow の順で判定される
ルールは deny、ask、allow の順に照合され、最初に当たったもので決まる。細かいルールほど優先されるわけではない。Bash(aws *) を deny にすると、Bash(aws s3 ls) を allow にしていても拒否される。どこか1つの設定ファイルで deny になったものは、ほかの設定ファイルの allow では通せない。
方法2｜acceptEditsでファイル編集をまとめて通す
ファイル編集の確認がいちばん多いなら、acceptEdits が合う。作業ディレクトリの中でのファイル作成と編集を確認なしで通し、状態表示は ⏵⏵ accept edits on になる。
確認なしで通るもの・残るもの
acceptEdits では、ファイル編集に加えて mkdir、touch、rm、rmdir、mv、cp、sed のようなファイル操作のコマンドも確認なしで通る（作業ディレクトリの中のパスに限る）。一方で、範囲の外のパス、.git などの保護されたパスへの書き込み、それ以外のBashコマンド（組み込みの読み取り専用コマンドを除く）には、今までどおり確認が出る。
入り方と使いどころ
Manual から Shift+Tab を1回押すか、claude --permission-mode acceptEdits で起動する。公式ドキュメントは、編集を1件ずつ承認する代わりに、エディタや git diff で後からまとめて見直したい時の使い方として案内している。
方法3｜autoモードで確認を分類器に任せる
auto モードでは、ふだんの確認画面を出さずに作業が進む。実行の前に別の分類器モデルが中身を見て、頼んだ範囲を超える操作、知らないインフラに向けた操作、Claudeが読んだ悪意ある内容に引きずられたように見える操作を止める。明示した ask ルールは、auto でも確認が出る。
使える条件
公式ドキュメントでは、auto は全プランで使える。Team と Enterprise では既定で使えて、管理者は管理設定で permissions.disableAutoMode を "disable" にして組織全体で止められる。モデルの条件は前述のとおりで、Anthropic API では Opus 4.6以降、Sonnet 4.6以降、Fableモデルが対象になる。公式は「確認を減らすが、安全を保証するものではない」と注意しており、機密性の高い操作の確認の代わりにはしない。
既定にする時の置き場所
auto を既定にするなら、~/.claude/settings.json に "defaultMode": "auto" を書く。プロジェクトの .claude/settings.json や .claude/settings.local.json に書いても効かず、~/.claude/settings.json の値も飛ばして組み込みの既定が使われる。組み込みの既定が Manual になる古いバージョンでは、エラーも出ないまま Manual で始まる。Manual や acceptEdits で作業中でも、auto が使える環境ならBashの確認画面に「Yes, and switch to auto mode」が出るので、そこから切り替えてもよい。分類器の設定の詳しい調整は自動許可モードのチーム導入、既定が auto になった時の移行はauto mode標準化の移行手順で扱っている。
方法4｜すべて許可するbypassPermissionsを使う条件
「全部許可したい」に当たるのが bypassPermissions だ。確認画面と安全確認を止め、.git や .claude のような保護されたパスへの書き込みまで確認なしで通す。公式ドキュメントは、Claude Codeが被害を出せないコンテナやVMのような隔離した環境でだけ使うよう警告している。
それでも止まるもの
deny ルールは bypassPermissions でも効く。逆に allow ルールは、このモードでは意味を持たない。さらに、次の節で挙げる「どのモードでも自動では通らない操作」には、このモードでも確認が出る。
有効にする方法
起動時に --dangerously-skip-permissions か --permission-mode bypassPermissions を付ける。defaultMode で既定にする場合は、ユーザー設定、--settings、管理設定のどれかに書く。プロジェクトの .claude/settings.json と .claude/settings.local.json に書いた "bypassPermissions" は、v2.1.257 から無視されるようになった（CHANGELOG）。VS Code拡張では拡張の設定で「Allow dangerously skip permissions」を、デスクトップアプリでは Pro・Max プランなら「Allow bypass permissions mode」を有効にした時だけ、モードの選択肢に出る。
組織で止める
使わせたくない組織は、permissions.disableBypassPermissionsMode を "disable" にする。どの設定ファイルでも効くが、管理設定に置けば利用者の設定で上書きできない。
どのモードでも確認が残る操作
auto にしても bypassPermissions にしても確認が消えない操作がある。公式ドキュメントが「どのモードでも自動では承認しない」としているのは次のものだ。
自動では通らない操作
- 明示した ask ルールに当たるツール
- 組織が
askに設定したコネクタのツール - 利用者の操作が前提のツール（組み込みの
AskUserQuestionと、requiresUserInteractionが付いたMCPツール） rm -rf /やrm -rf ~のような、重要なパスを消すrmとrmdirpermissions.blockReadsOutsideWorkingDirectoriesを有効にしている時の、作業ディレクトリの外の読み取り（設定のしかたは作業ディレクトリ外の読み取り制御を参照）
保護されたパスへの書き込み
.git などの保護されたパスへの書き込みは、Manual と acceptEdits では確認が出て、auto では分類器に回り、dontAsk では拒否される。permissions.allow に Edit(.claude/**) のようなルールを書いても、この確認は先に走るので通らない。その代わり確認画面に「Yes, and allow Claude to edit files in this project’s .claude folder for this session」のような、そのセッションの間だけ許す選択肢が出る。
想定シナリオ｜受託開発チームの許可設定を3つのファイルに分ける
ここからは構成例で、実在の企業の事例や実測値ではない。5人ほどの受託開発チームが「テストとコミットは聞かれずに回したい、push は必ず人が見る、.env は読ませない」を決めた場合の分け方を示す。
チームで共有するルール
リポジトリの .claude/settings.json に、全員で揃えるルールを書いてgitで共有する。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
"ask": [
"Bash(git push *)"
],
"deny": [
"Read(./.env)"
]
}
}
push を deny ではなく ask にしたのは、auto で作業していても push の前だけは確認を出したいからだ。ask ルールは auto でも確認が出る。ただし git -C . push のような別の書き方には当たらないので、push を本当に止めたいなら、ルールだけに頼らず後述のサンドボックスやフックと組み合わせる。
個人とプロジェクトごとの設定
各自の ~/.claude/settings.json には、使うモードの既定だけを書く。auto が使える人は "defaultMode": "auto"、使えない人は書かずに Manual のまま始め、必要な時に Shift+Tab で切り替える。確認画面から保存されるルールは .claude/settings.local.json に貯まるので、このファイルはgitで共有しない。gitで追跡されている .claude/settings.local.json は、リポジトリから渡された設定として扱われ、信頼のダイアログを受け入れるまで効かなくなる。
組織の禁止事項
会社として bypassPermissions を使わせない方針なら、情報システム担当が管理設定に "disableBypassPermissionsMode": "disable" を置く。チームの権限設計の進め方はClaude Code権限設計ガイドが詳しい。
よくある失敗パターン
❌ Bash(git *) を allow に入れる
⭕ Bash(git commit *) のように、許すサブコマンドを書いてから * を付ける。Bash(git *) はすべての git コマンドを通す。公式ドキュメントは、Bash(git * main) が git -c core.fsmonitor=<script> diff main にも当たり、git に任意のプログラムを実行させる -c まで通してしまう例を挙げている。
❌ CLAUDE.md に「確認せずに実行して」と書く
⭕ 許可はルールかモードで決める。公式ドキュメントのとおり、許可のルールはモデルではなくClaude Code本体が強制する。CLAUDE.md の指示はClaudeが何をしようとするかを変えるだけで、何が許されるかは変えない。
❌ プロジェクトの設定に "defaultMode": "auto" を書く
⭕ ~/.claude/settings.json に書く。プロジェクトの .claude/settings.json と .claude/settings.local.json では "auto" が効かず、組み込みの既定が使われる。プロジェクトの設定に書いた "auto" は誰の環境でも読まれないので、チームでモードをそろえる手段にはならない。
❌ deny に Bash(curl *) を書いたので通信は防げたと考える
⭕ deny ルールは、Claudeがふだん書く形のコマンドを止めるもので、境界の役目はしない。公式ドキュメントの表では、Bash(curl *) は /usr/bin/curl や sh -c 'curl …' を止めない。通信やファイルの範囲を確実に絞るならサンドボックスを使い、コマンドの中身を自分の条件で調べたいなら PreToolUse のフックで判定する。
❌ 手元のPCで --dangerously-skip-permissions を常用する
⭕ 確認を減らしたいだけなら、まず auto を使う。bypassPermissions はコンテナかVMの中に限る。
今日やる3つ
- 状態表示を見て、いまのモードを確かめる。
⏸ manual mode onなら、上の「Manual で始まる主な理由」を順に確認する。 /permissionsを開き、ルールとその保存先を一覧で見る。Bash(git *)のような広すぎるルールがあれば消す。- 毎日許可しているコマンドを2つか3つ allow ルールにし、push のような人が見たい操作は ask ルールにする。
よくある質問
Claude Codeで許可を全部スキップするには？
--dangerously-skip-permissions か --permission-mode bypassPermissions を付けて起動する。公式ドキュメントはコンテナやVMのような隔離した環境でだけ使うよう警告している。deny ルールと、どのモードでも自動では通らない操作には、このモードでも確認や拒否が残る。確認を減らすのが目的なら、先に auto モードを試す。
「今後は聞かない」を選んだのに、また聞かれるのはなぜ？
ファイル編集の許可は保存されず、セッションが終わると消えるからだ。Bashコマンドの許可は保存されるが、ルールは書いた形のコマンドにしか当たらないので、/usr/bin/… のようなパス付きの呼び出しや、つないだコマンドの別の部分は改めて判定される。
許可したルールはどこに保存される？
v2.1.211以降は、gitリポジトリの直下の .claude/settings.local.json に保存される。/permissions を開くと、ルールごとにどの設定ファイルから来ているかが分かり、その画面から消せる。
CLAUDE.md に書けば許可は要らなくなる？
ならない。許可のルールはClaude Code本体が強制するもので、CLAUDE.md の指示では変わらない。許可を変えるには /permissions、設定ファイルのルール、モード、PreToolUse フックのいずれかを使う。
VS Code拡張で毎回聞かれる時はどうする？
入力欄の下のモード表示をクリックして、Manual、Edit automatically、Plan、Auto から選ぶ。拡張は会話を始める時のモードを決めるのにプロジェクトの .claude/settings.json を読まないので、既定を変えるなら拡張の設定の claudeCode.initialPermissionMode を使う。この設定は auto を受け付けないため、Auto で始めたい時は設定を空にしてモード表示から一度 Auto を選ぶ。
auto モードでも聞かれる操作は？
明示した ask ルールに当たる操作、AskUserQuestion、重要なパスを消す rm、permissions.blockReadsOutsideWorkingDirectories を有効にしている時の作業ディレクトリの外の読み取りなどだ。auto が使えない条件に当たって Manual に戻っていないかも、状態表示で確かめる。
あわせて読みたい
- 【2026年最新】Claude Code自動許可モード実践｜チーム導入と安全設計
- Claude Code権限設計ガイド【2026】
- Claude Code settings.json設定完全ガイド【2026】
運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）
参考・出典
- Configure permissions（Claude Code 公式ドキュメント）（2026年10月6日参照・確認の種類、保存先、ルールの書き方、判定の順序、ワークスペース信頼）
- Choose a permission mode（Claude Code 公式ドキュメント）（2026年10月6日参照・モードの一覧、始まるモードの決まり方、auto の条件、bypassPermissions、保護されたパス）
- Settings files and precedence（Claude Code 公式ドキュメント）（2026年10月6日参照・設定ファイルの範囲）
- Commands（Claude Code 公式ドキュメント）（2026年10月6日参照・/permissions）
- Claude Code CHANGELOG（GitHub・anthropics/claude-code）（2026年10月6日参照・v2.1.257 の bypassPermissions の扱い、最新版 v2.1.291）
- 設定の例（GitHub・anthropics/claude-code の examples/settings）（2026年10月6日参照）
