--allow-dangerously-skip-permissionsの挙動 — planの安全性が変わる点

--allow-dangerously-skip-permissionsは、bypassPermissionsをShift+Tabの切り替え候補に加えるだけのフラグです。起動した時点ではそのモードに入りません。planなど別のモードで始め、必要になった時点で切り替えられます。

名前が--dangerously-skip-permissionsとほぼ同じなので混同されがちですが、効き方は別物です。この記事では、切り替え候補への入り方、planモードの挙動が変わる点、使えない場面と止め方を順に見ます。

--allow-dangerously-skip-permissionsは何をするフラグか

CLIリファレンスには「bypassPermissionsをShift+Tabの切り替え候補に追加するが、そのモードで開始はしない」フラグと書かれています。planで始めて後からbypassPermissionsへ移る使い方が例です。

claude --permission-mode plan --allow-dangerously-skip-permissions

この例はplanで起動します。ステータスバーには⏸ plan mode onが出て、bypassPermissionsになるのはShift+Tabで自分で切り替えたときだけです。切り替えると⏵⏵ bypass permissions onの表示に変わります。

--permission-modeで起動モードを決める基本はClaude Codeの--permission-modeで起動モードを指定するにあります。このフラグはその指定と組み合わせて使う補助です。

Shift+Tabの切り替え順のどこに入るか

標準の切り替え順はdefault、acceptEdits、planの順です。autoから最初に押すとdefaultへ移り、そこから同じ順に進みます。

任意で有効にするモードはplanの後ろに並びます。bypassPermissionsが先、autoが最後です。両方が有効なら、planから1回押すとbypassPermissionsに入り、もう1回押すとautoへ進みます。planの次に押したら無確認のモードだった、という状況になり得る点は覚えておく価値があります。

bypassPermissionsが切り替え候補に現れる条件は次の4つです。

• --permission-mode bypassPermissionsで起動した
• --dangerously-skip-permissionsで起動した
• --allow-dangerously-skip-permissionsで起動した
• ユーザー設定、--settings、管理設定のいずれかでpermissions.defaultModeを"bypassPermissions"にした

dontAskは切り替え候補に現れず、--permission-mode dontAskで指定する必要があります。

起動後に有効化はできない

bypassPermissionsを有効にしていないセッションからは、このモードに入れません。有効化は起動時に済ませる必要があります。「普段は有効化せずに起動して、必要になったら途中で足す」ことはできず、足すつもりなら最初からフラグを付けて起動します。

常用するなら、シェルのエイリアスにしておく運用が考えられます。次はあくまで一例です。

# 例: planで始めつつ、bypassPermissionsも候補に加える
alias claude-plan='claude --permission-mode plan --allow-dangerously-skip-permissions'

エイリアスにすると、普段のターミナル作業でもbypassPermissionsが常に候補に入ります。次の節の理由から、これは見た目以上に影響が大きい設定です。

候補に足すとplanモードの挙動が変わる

見落としやすいのはここです。bypassPermissionsが使える対話ターミナルセッションでは、planモードのブロックが強制されません。

通常のplanは、計画を承認するまで編集をブロックします。ところがbypassPermissionsが使える状態では、Claudeは計画に徹するよう指示されるものの、計画中に試みたファイル編集やシェルコマンドはプロンプトなしで実行されます。ただし、明示的なaskルールと、重要パスを対象にしたrm・rmdirの削除は引き続き確認が出ます。

つまり、--permission-mode plan --allow-dangerously-skip-permissionsで始めたplanは、フラグ無しのplanほど安全な「読むだけのモード」ではありません。保護パスへの書き込みも、この状態のplanでは自動承認の対象です。フラグを付けないplanなら、保護パスへの書き込みは自動承認されません。

読み取り専用の計画フェーズを期待して起動するなら、このフラグは外しておくほうが仕様に沿います。逆に、planで状況を調べてすぐ実装に移りたい用途なら、この挙動は意図どおりです。Claude Code Planモード完全ガイドにplanモード自体の使い方があります。

プラン承認の選択肢も変わる

計画が出ると、承認の選択肢が表示されます。通常は「Yes, and use auto mode」「Yes, manually approve edits」「No, keep planning」です。bypassPermissionsを有効にして起動していると、最初の選択肢が「Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session」に置き換わります。

承認ボタンを何気なく押した結果、以降のプロンプトがすべて消える、という流れが起こり得ます。選択肢の文言を読んでから承認する習慣が要ります。

ターミナル以外では効き方が違う

planのブロックが外れるのは対話ターミナルセッションだけです。次の場面ではplanのブロックが維持されます。

• -pによる非対話実行
• Agent SDKのセッション
• VS Code拡張のチャットパネル

これらでは、--allow-dangerously-skip-permissionsは「後からbypassPermissionsを選べるようにする」役割だけを持ちます。VS Code拡張でbypassPermissionsを使うには、拡張設定の「Allow dangerously skip permissions」トグルが必要です。トグルが無いとモードがインジケーターに出ず、bypassPermissionsを指定してもManualで始まります。

初回の警告ダイアログとroot制限

bypassPermissionsが有効な対話セッションを初めて起動すると、操作の責任を受け入れるかを問う警告ダイアログが出ます。承認すると~/.claude/settings.jsonにskipDangerousModePermissionPrompt: trueが書き込まれ、以降は表示されません。もう一度見たいときは、そのキーを消すかfalseにします。断ると、Claude Codeは終了します。

非対話モードではダイアログは出ません。--bgで始めるバックグラウンドセッションは、対話セッションで一度ダイアログを承認するまで拒否されます。拒否されたら、対話セッションでclaudeを起動してダイアログを承認し、そのあとで--bgをやり直します。

LinuxとmacOSでは、rootまたはsudoの下でこのモードを使えません。拒否時のメッセージは次のとおりです。

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

認識されたサンドボックスの内側ではこの確認が自動でスキップされます。コンテナで自律実行するなら、非rootで動くdev container構成を使います。

効かない・止められる場面

このフラグがあってもbypassPermissionsが使えない場面があります。

disableBypassPermissionsModeは、--dangerously-skip-permissionsを拒否し、エージェント定義のpermissionMode: bypassPermissionsも無視する設定です。このキーは起動時のフラグより優先されます。設定リファレンスの同じ項目には--allow-dangerously-skip-permissionsの記載がありませんが、モード自体を止める設定なので、組織でbypassPermissionsを許さないなら管理設定に置きます。

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

組織側の設計はClaude Code組織管理ガイドが扱っています。

bypassPermissionsでも止まらないもの

切り替え候補に足して実際に入ったあとも、すべてが素通りになるわけではありません。

• denyルールはすべてのモードで効く。bypassPermissionsも例外ではない
• allowルールはbypassPermissionsでは意味を持たない
• 他組織の公開アーティファクトの読み取りは承認が必要で、このモードでは承認を求められないため読めない
• 重要パスに対するrm・rmdirの削除は確認が出る。端末では2分のカウントダウンが付く
• 複数セッション間のメッセージ受信には安全策が残る

Windowsでは、PowerShellツールを有効にしているとRemove-Itemにも専用の確認があります。ファイルシステムのルートやホームディレクトリ、*や\*で終わるワイルドカードの対象は、bypassPermissionsでも拒否されます。作業ディレクトリかその親を-Recurseで消すコマンドだけは、このモードで確認が省かれます。

サブエージェントも、このモードを引き継ぎます。メインの会話がbypassPermissionsなら、サブエージェント定義のpermissionModeは無視され、同じモードで動きます。逆に、メインがdefaultやplanのとき、サブエージェント側にbypassPermissionsを指定してもメインのモードが使われます(後者はv2.1.267以降)。サブエージェントに丸ごと任せても、無確認にできるのは本体が無確認の間だけです。

確認が不要になるのは、あくまで通常のツール呼び出しの承認です。プロンプトインジェクションや意図しない操作への防御はないため、隔離されたコンテナやVMで使う前提のモードです。確認を減らしつつ裏で安全確認を走らせたいなら、auto modeの有効化条件を確認してautoを使う選択肢があります。

どう使い分けるか

状況別の目安は次のとおりです。

権限モード全体の経緯を知りたい場合は、Claude Code権限モデルの変遷も参考になります。

まとめ

このフラグは、bypassPermissionsを「入れる状態」にせず「入れる候補」に置く仕組みです。便利な反面、planのブロックが外れる副作用があり、planの次の1回で無確認のモードに入る配置でもあります。planを安全な計画フェーズとして使いたいかどうかで、付けるか外すかが決まります。