Claude Codeのパーミッションモードの違いと設定方法｜auto・acceptEdits・bypassPermissionsの使い分け

Claude Codeの確認プロンプトを減らす方法は、--dangerously-skip-permissionsだけではありません。パーミッションモードは6種類あり、2026年9月下旬のv2.1.283以降は、ターミナルとVS Code拡張の対話セッションがプランを問わずautoモードで始まります。この記事では、6モードの守備範囲、skipDangerousModePermissionPromptを書ける場所と省ける範囲、--permission-modeの値、settings.jsonのdefaultModeが効かないファイルを整理します。仕様の根拠は公式ドキュメント（2026年10月17日取得）で、設定ファイルごとの開始モードは手元のClaude Code 2.1.299で実測しました（npmの最新は2.1.302）。

まとめ｜6つのパーミッションモードと設定キーの要点

• モードはdefault（画面表示はManual）・acceptEdits・plan・auto・dontAsk・bypassPermissionsの6種類です。manualはdefaultの別名です（v2.1.200以降）。
• autoは分類器モデルが実行前に操作を審査するモード、bypassPermissionsは審査も確認もしないモードです。別物です。
• skipDangerousModePermissionPromptが省くのは、bypassPermissionsに入る前の警告ダイアログだけです。書けるのはユーザー設定・ローカル設定・管理設定で、プロジェクトの.claude/settings.jsonからは効きません。
• defaultModeのautoとbypassPermissionsは、プロジェクトの.claude/settings.jsonと.claude/settings.local.jsonから効きません。エラーは出ず、bypassPermissionsはManualで、autoは組み込みの既定モードで始まります。~/.claude/settings.jsonに書いてください。
• --enable-auto-modeは公式リファレンス上v2.1.111で削除済みです。v2.1.299の本記事の非対話実測ではエラーにならず、Manualで始まりました。開始モードは、このフラグではなく他の設定や組み込みの既定で決まります。--permission-mode autoを使ってください。
• denyルールはbypassPermissionsを含む全モードで効き、allowルールはbypassPermissionsでは意味を持ちません。なお、ほかに呼び出せるツールがある間のEndConversationには、deny・askルールが適用されない例外があります。

6つのパーミッションモードが確認なしで実行する範囲

「オートモード＝dangerously-skip-permissions」が誤りになった経緯

Claude Codeの初期は、確認を止める手段が実質--dangerously-skip-permissionsしかなく、これを「オートモード」「YOLOモード」と呼ぶ習慣が生まれました。日本語の解説にはこの定義のまま残っているものがあります。

現在の公式のパーミッションモード解説は、autoを「別の分類器モデルが実行前に操作をレビューし、依頼の範囲を超えるもの、認識していないインフラを対象にするもの、読み込んだ敵対的コンテンツに起因すると見られるものをブロックする」モードと定義しています。人間の承認を分類器の審査に置き換える設計で、審査そのものを外すbypassPermissionsとは役割が違います。autoの判定ロジックやブロックされたときの対処はClaude Code auto modeとは？既定化した自動承認の仕組みと「bash denied」の対処【2026年10月】で扱い、本記事はモードの選び分けと設定キーに絞ります。

モード別の自動承認範囲とステータスバー表示

acceptEditsが自動承認するBashコマンドはmkdir・touch・rm・rmdir・mv・cp・sedの7つで、対象は作業ディレクトリとadditionalDirectoriesの配下に限られます。LANG=Cのような安全な環境変数やtimeout・nohupを前に付けても通ります。それ以外のBashコマンドは、組み込みの読み取り専用コマンドを除いて確認が入ります。

planで分類器がコマンドを審査するのは、autoが使える環境で設定useAutoModeDuringPlanが既定のtrueのときです。falseにすると、通常は読み取り専用以外のコマンドが確認対象になります。ただし、bypassPermissionsを使える状態で始めた対話ターミナルのplanでは、分類器の審査も通常の確認も適用されません。クリティカルパスの削除などの保護は残ります。

どのモードでも自動承認されない操作

bypassPermissionsでも、次の操作は自動では通りません。

• 明示的なaskルールに一致したツール、組織がaskに設定したコネクタのツール
• AskUserQuestionやrequiresUserInteraction付きのMCPツールなど、ユーザーの回答が前提のツール
• ルートやホームディレクトリなどクリティカルパスを対象にしたrm・rmdir（allowルールでもPreToolUseフックのallowでも通せません）
• 別セッションとのメッセージ送受信にかかる保護
• permissions.blockReadsOutsideWorkingDirectoriesが有効なときの、作業ディレクトリ外の読み取り（v2.1.257以降）

どのモードを選んでも、確実に止めたい操作はdenyかaskのルールで書くのが基本です。ルールの書き方とサンドボックスの重ね方はClaude Codeのセキュリティ設定｜権限ルール・サンドボックス・管理設定で守る実装手順にまとめています。

skipDangerousModePermissionPromptが省く警告と書ける場所

skipDangerousModePermissionPromptの省略対象

skipDangerousModePermissionPromptは、セッションがbypassPermissionsに入る直前に出る確認ダイアログを出さないようにするキーです。--dangerously-skip-permissionsから入る場合も、defaultMode: "bypassPermissions"から入る場合も対象です。個々の操作に出る承認プロンプトには関係しません。

{
  "skipDangerousModePermissionPrompt": true
}

公式の設定リファレンスによると、既定は未設定でダイアログが出ます。書ける場所はユーザー設定・ローカル設定・管理設定の3つで、リファレンスは「信頼していないリポジトリがあなたの代わりにダイアログを飛ばすことはできない」と理由を書いています。falseは未設定と同じ扱いで、ほかのファイルがtrueならダイアログは出ません。

手で書かなくても値が入っていることがあります。対話セッションでダイアログを一度承諾すると、Claude Code自身が~/.claude/settings.jsonにtrueを書き込むためです。ダイアログをもう一度出したいときは、このキーを消すかfalseにします。

バックグラウンドセッションとsettings.local.jsonの落とし穴

claude -pの非対話実行ではダイアログ自体が出ません。注意が要るのは--bgで起動するバックグラウンドセッションです。承諾の記録が無い状態でclaude --bg --permission-mode bypassPermissionsを実行すると、対話セッションで一度承諾するまで拒否されます。

キーを.claude/settings.local.jsonにだけ書いている場合は、拒否ではなく無視になります。バックグラウンドセッションはbypassPermissionsの指定を捨てて起動し、次の通知を固定表示します。

Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true

このとき--permission-mode bypassPermissionsや--dangerously-skip-permissionsで起動したセッションはManualで始まり、--allow-dangerously-skip-permissionsで起動したセッションはShift+Tabの巡回からbypassPermissionsが外れます。対話セッションではローカル設定のキーが効くため、手元では通るのにバックグラウンドだけ通らない、というずれ方をします。

dotfiles同期で毎回ダイアログが戻る問題

~/.claude/settings.jsonをGitやdotfiles同期ツールで管理していると、承諾時にClaude Codeが書き込んだtrueが同期で元に戻され、起動のたびにダイアログが出ることがあります。GitHubのissue #25503（2026年2月13日起票）は「フラグを明示した時点で承諾とみなすべき」と求めていますが、10月17日時点でもopenのままです。同期している側のsettings.jsonにこのキーを直接書いておけば戻りません。

名前から「承認プロンプトを全部消す設定」と受け取られやすく、issue #50461のように「trueにしても確認が出る」という報告も立っています。前の章で挙げた、どのモードでも自動承認されない操作は、このキーでは消えません。

名前の似たskipAutoPermissionPromptとの違い

skipAutoPermissionPromptは、自分の設定やモード選択で初めてautoに入ったときに一度だけ出る説明の表示を省くキーです。警告ダイアログではありません。組み込みの既定がセッションをautoで始めた場合の通知は対象外で、書けるのはユーザー設定と管理設定だけです（ローカル設定は不可）。説明は一度出ると表示済みとして記録されるため、このキーが意味を持つのはまだ一度も出ていない環境に限られます。

–permission-modeによる起動時のモード指定

受け付ける7つの値とmanualエイリアス

起動時の指定は--permission-modeです。設定ファイルのdefaultModeより優先されます。--dangerously-skip-permissionsは--permission-mode bypassPermissionsと等価だと公式のCLIリファレンスに明記されています。

claude --permission-mode auto
claude --permission-mode acceptEdits
claude --permission-mode plan
claude --permission-mode dontAsk
claude --permission-mode bypassPermissions
claude --permission-mode default    # 画面表示は Manual
claude --permission-mode manual     # default の別名（v2.1.200以降）

セッション中はShift+Tabで切り替えます。autoから最初に押すとdefaultへ移り、その後はdefault→acceptEdits→planと回ります。bypassPermissionsとautoは使える状態のときだけplanの後ろに入り、順番はbypassPermissionsが先、autoが最後です。dontAskは巡回に現れず、--permission-mode dontAsk、または設定ファイルのpermissions.defaultMode: "dontAsk"で指定します。v2.1.247以降は、ManualとacceptEditsのBash承認プロンプトに「Yes, and switch to auto mode」が加わり、承認と同時にautoへ移れます。

–enable-auto-modeの廃止とv2.1.299の非対話実測

古い記事に残るclaude --enable-auto-modeは、CLIリファレンスでは「v2.1.111で削除。autoは既定でShift+Tabの巡回に入っているので、そのモードで始めるには--permission-mode autoを使う」とされています。ただし、v2.1.299で実行するとエラーにはなりません。本記事のユーザー設定を除外した非対話実行では、フラグは受け付けられ、Manualで始まりました（次章の実測表のE）。フラグがManualを選んだのではなく、無視されて-pの既定がそのまま使われた結果です。既定がdefaultになる実行方法でこのフラグに頼ると、autoで動かしたつもりがManualのまま動く、というのが実際に起きる症状です。

環境変数CLAUDE_CODE_ENABLE_AUTO_MODE=1も同じ扱いです。環境変数リファレンスは「古いリリースとの互換のために受け付けるが効果はない」としており、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryでもautoは既定で使えます。

settings.jsonのdefaultModeの置き場所とauto・bypassPermissionsが効かないファイル

defaultModeの設定ファイル別の有効値

毎回フラグを付けたくない場合はpermissions.defaultModeを設定します。値は--permission-modeと同じ7つです。

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

開始モードは、--permission-mode（または--dangerously-skip-permissions）、permissions.defaultMode、組み込みの既定、の順に決まります。複数の設定ファイルにdefaultModeがある場合は設定の優先順位に従い、プロジェクトや管理設定の値が~/.claude/settings.jsonより優先されます。

落とし穴は、autoとbypassPermissionsの2つだけがプロジェクトの.claude/settings.jsonと.claude/settings.local.jsonから効かないことです。どちらもエラーは出ません。autoを書いた場合は~/.claude/settings.jsonのdefaultModeも使われず、組み込みの既定へ落ちます。bypassPermissionsを書いた場合はManualで始まります。bypassPermissionsが無視されるようになったのは変更履歴のv2.1.257（2026年9月1日）からで、それ以前はどのファイルからでも効いていました。リポジトリにチェックインした設定で、クローンした人のセッションを全開にできてしまう経路が塞がれた形です。

VS Code拡張が始める会話では、開始モードの決定手順が異なります。開始モードの選択にはプロジェクト設定を使わず、claudeCode.initialPermissionMode、前回モード表示から選んだモード、ユーザー設定と管理設定のdefaultMode、組み込みの既定、の順に決まります。claudeCode.initialPermissionModeはautoを受け付けないため、Autoで始めたい場合は未設定のままモード表示から一度Autoを選びます。

設定ファイル別の開始モードを実測した結果

上の表がドキュメントどおり動くかを、Claude Code 2.1.299で確かめました。空のディレクトリでclaude -pを--output-format stream-json --verbose付きで実行し、最初に出るinitイベントのpermissionModeを記録しています。ユーザー設定の影響を外すため、Hの行以外は--setting-sources project,localを付けました。

experiment_dir=$(mktemp -d) || exit 1
cd "$experiment_dir" || exit 1
mkdir -p .claude
echo '{"permissions":{"defaultMode":"bypassPermissions"}}' > .claude/settings.json
claude -p "reply with the single word ok" --max-turns 1 --model haiku \
  --output-format stream-json --verbose --setting-sources project,local \
  | grep -m1 '"subtype":"init"' | jq -r .permissionMode
# => default

B・C・Jが示すとおり、プロジェクト側にautoやbypassPermissionsを書いても警告もなくManualで始まります。チームでbypassPermissionsを配りたい場合は、プロジェクト設定ではなく管理設定か、起動スクリプトのフラグで渡すことになります。

実行方法別の組み込み開始モード

フラグもdefaultModeも無いときの開始モードは、実行方法と版で変わります。9月以降に大きく動いた部分です。

対話セッションの既定autoは、9月初めの時点ではPro・Max・Teamプランに限られていました。公式ドキュメントはv2.1.283以降を全プラン・全プロバイダとしており、変更履歴では他社クラウド経由とテレメトリ無効のセッションがv2.1.283（9月25日）、全プランへの拡大がv2.1.284（9月28日）の項目です。autoが選ばれても、モデルが非対応（Sonnet 4.5・Opus 4.5・Haiku 4.5など）だったり組織が止めていたりするとManualで始まります。

~/.claude/settings.jsonにauto以外のdefaultModeを書いていれば、その値が優先されます。Pro・Max・Teamプランなどでは、ターミナルかVS Code拡張で一度だけautoへの変更を勧められますが、断れば設定はそのまま残ります。

bypassPermissionsの入り方と止め方

起動経路4つと–allow-dangerously-skip-permissions

bypassPermissionsは、有効にせずに始めたセッションから後で入ることができません。入り口は次の4つです。

claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions
claude --permission-mode plan --allow-dangerously-skip-permissions   # 巡回に加えるだけ
# または ~/.claude/settings.json・管理設定・--settings の permissions.defaultMode: "bypassPermissions"

--allow-dangerously-skip-permissionsは、planで始めて計画を詰め、承認後にShift+TabでbypassPermissionsへ移る、という使い方をするフラグです。このフラグ付きで始めたセッションでは、計画の承認画面の選択肢が「Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session」に変わります。

bypassPermissionsでも止まる操作とroot・sudoでの起動拒否

クリティカルパスに対するrm・rmdirは、bypassPermissionsでも確認が出ます。v2.1.281以降、autoとbypassPermissionsのターミナルではこの確認に2分のカウントダウンが付き、時間切れなら拒否されます。何かキーを押せばカウントダウンは止まり、回答を待ち続けます。1セッションで3回時間切れになると、それ以降は確認を出さずに即拒否です（新しいメッセージを送ると数え直し）。環境変数CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1で時間制限を外せます。

LinuxとmacOSでは、rootまたはsudo下でbypassPermissionsを起動しようとすると、次のメッセージで拒否されます。

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

このチェックは、Claude Codeが認識するサンドボックス内では自動的に外れます。コンテナで自律実行したいなら、非rootユーザーでClaude Codeを動かすDev Containerの構成を使うのが近道です。仕組みはDev Container（devcontainer）のメリットとは｜Dockerで開発環境を統一する仕組みと設定【2026年版】で解説しています。

管理者がモードを止める設定

組織として止めたい場合は管理設定を使います。

• permissions.disableBypassPermissionsMode: "disable"：--dangerously-skip-permissionsを拒否し、サブエージェント定義のpermissionMode: bypassPermissionsも無視して親セッションのモードで動かします。
• disableAutoMode: "disable"（permissions.disableAutoModeでも可）：autoを巡回から外し、--permission-mode autoで始めてもManualになります。実行中のセッションにはauto mode disabled by settingsが表示されます。
• --restricted（v2.1.248以降）：評価ハーネス向けの起動オプションで、bypassPermissionsを受け付けません。

CIと非対話実行のモード選択（dontAskとclaude -p）

claude -pで回すCIでは、bypassPermissionsより先にdontAskを検討してください。dontAskは確認が必要になる呼び出しをすべて自動で拒否し、permissions.allowに一致する操作、読み取り専用のBashコマンド、PreToolUseフックが承認した呼び出しだけを実行します。入力待ちで止まることがなく、何が動くかが設定ファイルに残ってレビューできます。公式の例は次のとおりです。

claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

押さえておく前提は3つあります。まず、機能フラグを取得する通常の-p実行はdefaultで始まるので、autoで回したいなら--permission-mode autoを明示します（実測表のAとG）。次に、-pで--permission-prompt-toolを指定していないと、autoのブロックが閾値に達しても戻る先の確認画面がありません。その操作は実行されず、Claudeは作業を続けます。結果の検証は呼び出し側で行ってください。最後に、Claude Code on the webのクラウドセッションは設定ファイルのdontAskとbypassPermissionsを無視します。

動的な判断を足すならClaude Code Hooksの設定方法｜全33イベント一覧とsettings.jsonの書き方【2026年9月版】、GitHub Actionsから回すならClaude Code GitHub Actionsの導入と料金｜@claude連携の設定・分単価とトークン課金、プログラムから制御するならClaude Agent SDK（旧Claude Code SDK）とは？使い方・移行・料金を解説【2026年版】が入り口になります。

モード選択で失敗しやすい設定と採用すべきでない場面

ネット接続した開発機でのbypassPermissions常用リスク

通常の開発マシンでbypassPermissionsを常用するのは、今の選択肢では不利です。公式ドキュメントは「bypassPermissionsはプロンプトインジェクションや意図しない操作から守らない。確認を大幅に減らしつつ安全チェックが欲しいならautoを使う」と代替を名指ししています。使ってよいのは、コンテナ・VM・サンドボックスのように、壊されても作り直せる環境だけです。

判断の基準は、そのセッションが最悪の操作をしたときに失うものを復元できるかどうかです。復元できないデータや機密情報に触れる作業では、Manualで変更を確認し、必要に応じてdenyルールや隔離環境を併用します。autoやacceptEditsへ切り替えるだけでは、損失を防ぐ保証にはなりません。作業ツリーごと分けたいならClaude Codeのgit worktreeで並列エージェント開発を行う方法｜仕組み・使い方・注意点【2026年版】の構成が実務的です。社内でエージェントの権限設計から運用まで任せたい場合は、AIエージェント開発の支援も相談先になります。

autoで想定外に止まる・設定が効かない例

• 広いallowルールが外れる：autoに入ると、Bash(*)・PowerShell(*)・Bash(python*)のようなインタプリタのワイルドカード、パッケージマネージャの実行コマンド、AgentとMonitorのallowルールが一時的に外されます。Bash(npm test)のような狭いルールは残り、モードを抜けると元に戻ります。
• 3回連続・累計20回のブロックで一時停止：閾値は変更できません。止まると通常の確認に戻り、確認した操作を承認するとautoが再開します。分類器の判定ルールの確認や調整は、上で紹介したauto modeの記事で扱っています。

よくある質問

skipDangerousModePermissionPromptはどこに書けば効きますか？

~/.claude/settings.json（ユーザー設定）、.claude/settings.local.json（ローカル設定）、管理設定のいずれかです。プロジェクトの.claude/settings.jsonでは効きません。ただしバックグラウンドセッション（--bg）はローカル設定のキーを認めず、bypassPermissionsの指定を無視して起動します。確実なのはユーザー設定です。

skipAutoPermissionPromptとは何ですか？

自分で初めてautoに入ったときに一度だけ出る説明を省くキーです。bypassPermissionsの警告ダイアログとは無関係で、書けるのはユーザー設定と管理設定だけです。組み込みの既定でautoから始まった場合の通知には効きません。

accept edits onとauto modeの違いは何ですか？

accept edits on（acceptEdits）は、読み取りと事前許可した操作に加えて、作業ディレクトリ内のファイル編集とmkdir・mvなど7つのファイル操作コマンドを確認なしで通します。保護パスへの書き込みとそれ以外のBashコマンドは確認が出ます。auto mode on（auto）では、権限ルールで決着しない操作を分類器が実行前に審査します。読み取りや作業ディレクトリ内の編集は審査を通らず、審査では危険性だけでなく依頼の範囲や送信先も見られます。

settings.jsonのdefaultModeにautoを書いても反映されないのはなぜですか？

書いた場所がプロジェクトの.claude/settings.jsonか.claude/settings.local.jsonである可能性が高いです。autoはこの2ファイルから効かず、エラーも出ません。~/.claude/settings.jsonへ移してください。VS Code拡張の会話はclaudeCode.initialPermissionModeなどを読む別系統です。

–permission-mode autoと–dangerously-skip-permissionsの違いは何ですか？

--permission-mode autoでは、権限ルールなどで決着しない操作を分類器が実行前に審査します。本番デプロイ・強制push・外部への機密送信などは分類器の既定のブロック対象です。--dangerously-skip-permissionsは--permission-mode bypassPermissionsと同じで、その審査を行いません。前者は承認の手間を減らす仕組み、後者は保護を外す仕組みです。

関連記事

• Claude Code auto modeとは？既定化した自動承認の仕組みと「bash denied」の対処【2026年10月】
• Claude Codeのセキュリティ設定｜権限ルール・サンドボックス・管理設定で守る実装手順【2026年10月】
• Claude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順
• Claude Agent SDK（旧Claude Code SDK）とは？使い方・移行・料金を解説【2026年版】
• Claude Codeのgit worktreeで並列エージェント開発を行う方法｜仕組み・使い方・注意点【2026年版】