Claude Code --dangerously-skip-permissionsの使い方：確認が残る理由と安全な選び方

Claude Codeの確認をスキップして起動するには、claude --dangerously-skip-permissionsを使います。これはclaude --permission-mode bypassPermissionsと同じモードを選ぶ指定です。通常のツール呼び出しをその都度承認せずに進められますが、明示的な確認ルールや一部の削除チェックまで消えるわけではありません。公式の権限モード文書が示す、2026年10月7日時点の条件に沿って説明します。

普段の開発で編集確認だけを減らしたいなら、まずacceptEditsが候補です。無人で処理したい場合も、「未許可の操作を拒否する」dontAskと「通常の許可確認を通過する」bypassPermissionsでは結果が違います。bypassを使うときは、端末が持つ権限を先に狭める必要があります。

起動方法と、--allowを付けた場合の違い

自分で管理する隔離環境で、対象ファイルと通信先を限定できている場合の起動例です。次の2つは同じ指定なので、両方を付ける必要はありません。

claude --dangerously-skip-permissions

claude --permission-mode bypassPermissions

このフラグが変えるのはClaude Code側の許可判断です。OSのアクセス権、コンテナの制約、認証、利用枠、料金は変わりません。管理者権限でしかできない操作を可能にする指定でもありません。CLIのフラグ一覧で、自分のクライアントが対応する指定を確認してください。

一方、次の起動方法はbypassを選択可能にするだけで、その時点では有効にしません。

claude --allow-dangerously-skip-permissions

対話型ターミナルでは、利用可能になったモードを切り替えてから使います。現在のモード表示を確認し、ルールを見直す際は会話内の/permissionsを使います。--allowを付けたことだけを、bypassで動作している証拠にしないでください。

特に注意したいのは、対話型ターミナルでPlanと組み合わせる場合です。現在の仕様では、bypassが選択可能になっていると、Planによる編集・コマンド実行の強制的なブロックが適用されません。計画を作る指示自体は残りますが、「Planだから書き込めない」とは判断できません。-p、SDK、VS CodeのチャットではPlanの強制的な制限が残ります。この違いは権限モード文書に明記されています。

起動時に止まる場合

初回の対話型bypass起動には警告への同意があります。これはモード選択とは別に保存されます。-pでは警告ダイアログが表示されず、バックグラウンド起動の--bgでは事前の同意が必要です。ダイアログがないことを、実行環境の安全確認が済んだ印と考えないでください。

Linux・macOSでは、rootやsudoによるbypass起動は原則として拒否されます。認識されたサンドボックス環境には例外がありますが、通常の解決策は非rootユーザーで実行することです。また、v2.1.248以降の--restrictedはbypassを受け付けません。制限を解除するためにフラグを追加するのではなく、必要な作業が制限付きの実行で完了できるかを見直します。起動条件の公式説明

VS Codeで「権限をバイパス」が出ないとき

VS Codeの拡張機能には、bypassを利用可能にする独自の設定があります。CLIで--allow-dangerously-skip-permissionsを付けても、拡張機能のチャットで自動的に選べるようにはなりません。

1. VS Codeの設定で、Claude Code拡張機能のbypassを許可する項目を確認します。設定検索ではdangerouslyを識別語にできます。
2. その設定が組織の管理ポリシーで禁止されていなければ、有効にしたうえでチャットのモード選択を確認します。
3. 新しいチャットの開始モードと、現在のチャットの選択モードを区別します。設定を変えただけで既存のチャットがbypassになったとは判断しません。

VS Codeは開始モードを決める際に、プロジェクトの設定を読みません。ユーザー側のinitialPermissionMode、記憶されたモード、管理設定・ユーザー設定、組み込みの既定値などが関係します。PlanとBypassは前回のモードとして記憶されず、拡張機能をラッパー経由で起動する場合にも違いがあります。正確な順序は公式文書のVS Codeタブで確認できます。

同じClaude Codeでも、操作画面によって選べるモードは異なります。

この表は現在の公式な画面別仕様です。Remote ControlでBypassが見えない場合も、ローカルの実行が必ずManualになっているとは限りません。実行元のターミナルを確認してください。

bypassでも確認が残る理由

bypassは「すべての確認を無条件で消す」モードではありません。まず、画面上の許可ダイアログなのか、Claudeが文章で質問しているだけなのかを区別します。後者はタスクの曖昧さを解消する質問で、許可モードの切り替えだけではなくなりません。

許可ダイアログや拒否が出る場合は、次の条件を確認します。

権限モードの公式説明では、現在のbypassは保護対象パスへの通常の書き込みも即座に許可します。したがって「.claudeなどの保護対象は必ず確認される」という古い説明には頼れません。一方、重要パスに対するrm・rmdirは別扱いです。v2.1.281以降、Auto・Bypassのターミナルで出るこの確認には2分の期限があり、応答しない状態が繰り返されると拒否されます。PowerShellのシステムパスやワイルドカードを使う削除には、全モード共通の拒否条件もあります。

これは「危険な削除は全部止まる」という保証ではありません。プログラム内部での削除や、別の実行経路を含めたOS上の制限にはなりません。止まった処理は対象と必要性を確認し、理由が分からないまま保護機能を無効化しないことが大切です。

--continueや/resumeでBypassは引き継がれる？

保存済みの会話をID・名前・--continueで復元する場合、保存されていたBypassとPlanは新規セッションの開始モードに戻ります。bypassが必要なら、改めて明示的に有効にします。起動時の選択画面から再開する場合も、新規セッションのモードが使われます。

一方、動作中のセッションで/resumeを使う場合は現在のモードを維持し、実際に動作中のバックグラウンドセッションを再開する場合もそのモードを維持します。-pの再開は新しい-p実行の既定値が基本で、Planの復元にはバージョンと確認用ツールなどの追加条件があります。再開時の権限モードを区別して、再開後の表示を確認してください。

確認を減らすなら、まずどのモードを選ぶ？

編集、判断の自動化、確認なしの実行を分けると、必要以上に権限を広げずに済みます。

Manualは画面上の名称で、設定値はdefaultです。manualの別名はv2.1.200以降に対応しています。編集を自動承認する起動例は次のとおりです。

claude --permission-mode acceptEdits

Autoを明示的に選ぶ場合は、対応する環境で次の指定を使います。

claude --permission-mode auto

現在は「Autoは特定の有料プランだけ」と一括りにはできません。v2.1.283以降、対話型ターミナルとVS Codeの組み込みの開始モードは、プラン・接続先をまたいでAutoになっています。ただし、対応モデルの最低バージョン、組織のdisableAutoMode、サーバー側の利用条件などは引き続き関係します。現在のAutoの条件

-pやSDKは別です。機能フラグを取得するセッションは通常Manualで開始し、取得しないセッションはv2.1.285以降、条件を満たせばAutoが既定値になります。HIPAA対象の組織にはManualの別条件があります。無人実行のスクリプトでは、既定値を推測せず、必要なモードを明示すると挙動を理解しやすくなります。

決まったテストだけを無人実行する例

たとえば、内容を確認済みのtest:unitスクリプトを実行し、追加の許可が必要になったら拒否したい場合は、bypassを使わずに構成できます。次は、対象プロジェクトにそのnpmスクリプトが存在することを前提にした文書上の例です。

claude -p "npm run test:unitを実行し、失敗したテストと原因を報告してください。ファイルは変更しないでください。" \
  --permission-mode dontAsk \
  --tools "Read,Bash" \
  --allowedTools "Read" "Bash(npm run test:unit)"

dontAskは、許可されていないツール呼び出しを確認待ちにせず拒否します。--allowedToolsはその呼び出しを事前承認し、--toolsは利用できる組み込みツールを絞ります。成功は、実際に指定のテストが実行され、終了結果が報告されたことで判断します。呼び出しが拒否された場合は、拒否の対象を確認して必要な操作だけを見直します。Claudeの最終文章が返ってきたことだけでは、テストの実行完了を意味しません。CLI指定の意味

この例にも範囲があります。--toolsはMCPツールを制限しません。また、Readを許可すると読み取り範囲がそのプロジェクトだけに限定されるわけではなく、Bashから起動するnpmスクリプトにもファイルやネットワークへのアクセス能力があります。プロンプトの「変更しない」という指示だけで、シェル経由の書き込みを強制的に止めることはできません。信頼できないプロジェクトにこの例をそのまま使わず、後述の隔離を組み合わせてください。

設定ファイルで許可ルールを保存する例

毎回同じ作業をする場合は、必要なルールをJSONとして保存できます。次は、Manualを開始モードにし、単体テストを許可し、npmのインストールは確認対象にする例です。permissions-example.jsonというファイルに保存した想定です。

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm run test:unit)"],
    "ask": ["Bash(npm install *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

claude --settings ./permissions-example.json

既存設定との関係にも注意してください。--settingsは指定したキーを追加・上書きするためのもので、ほかの設定をすべて空にする指定ではありません。CLIの開始モードは、明示的な起動フラグ、適用される設定、組み込みの既定値の順に決まります。プロジェクト設定のdefaultModeにbypassPermissionsを書いてもbypassでは開始せず、Manualになります。Autoのプロジェクト側開始指定も適用されません。設定と開始モード

このJSONは構文をオフラインで確認した例です。実際のClaude Codeでの起動・テスト実行は検証していません。Read(./.env)はReadツールへのルールであり、別プロセスからの読み取りまで防ぐ設定ではありません。

denyやフックだけで安全になる？

通常の許可ルールはdeny、ask、allowの順に評価されます。bypassでも明示的なaskは残り、通常のdenyにも従います。ただし、この説明は評価するプログラム自体が改変されていないことを前提にします。権限ルールの公式説明

Bashのルールは、認識できるコマンド分割やラッパー処理の後の文字列に照合します。絶対パスで呼ぶ実行ファイル、インタープリター、別のプログラム内部の処理まで、任意の実行をすべて解析するわけではありません。Readの禁止も、Bashの子プロセスによるファイルアクセスを完全には止めません。許可するnpmスクリプトの内部も、確認対象になります。

PreToolUseフックによるブロックはbypass中でも使えますが、正規表現や自作のコマンド分割だけをOSの境界として扱えません。日本語のwasabeef氏の記事には、2025年7月4日時点のdenyとフックを組み合わせる例があります。設定の考え方を知る資料として参照できる一方、シェルの全構文や間接実行に対応した隔離の証明ではありません。

さらに、プロセス内で動くmodのtool.checkには、確認、フック、分類器の判断や一部のdenyポリシーを上書きできる場合があります。管理フックや管理・組織のdenyには個別の保護条件がありますが、「denyを入れればどんな拡張コードにも勝つ」とは言えません。ルールを強めるだけでなく、読み込ませる拡張コードの権限も確認してください。modを含む許可評価の仕様

無人実行には、どこまでの隔離が必要？

無人でbypassを使うなら、Claude Code全体が触れられるファイルと通信先を制限する外側の環境が必要です。Gitのブランチやworktreeは変更を分ける仕組みで、ホームディレクトリ、認証情報、ネットワークへのアクセスを隔離しません。公式のサンドボックス環境の説明

組み込みサンドボックスは、Bashなどを囲う

Claude Codeの組み込みサンドボックスが囲うのは、Bash、PowerShell、Monitorとその子プロセスです。ファイル用ツール、Web用ツール、MCP、フック、LSP、ステータスライン用プログラム、mod、画面操作などは、その境界の外にあります。サンドボックス内でBashを自動承認する設定と、分類器が判断するAutoモードも別の機能です。組み込みサンドボックスの範囲

設定を見るときは、次の点をまとめて確認します。

• 有効化と起動失敗： 既定では無効です。非対応環境や依存関係不足で使えない場合、failIfUnavailableを有効にしていなければ、隔離なしで起動することがあります。
• 隔離なしの再試行： allowUnsandboxedCommands: falseは、失敗後に隔離なしで再試行する経路を閉じます。ただし、除外したコマンドや起動時の非対応まで、この1項目ですべて解決するわけではありません。v2.1.285以降はユーザー設定のfalseをプロジェクト側のtrueで緩められません。管理設定やCLI側で再試行を禁じても、サンドボックス自体が自動で有効になるわけではありません。
• 通信先： bypassでは、未登録のホストが自動承認される場合があります。allowedDomainsを空にしただけでは、通信をすべて拒否できません。strictAllowlistや管理側のドメイン制限が必要です。
• 秘密情報： 既定の読み取り範囲や引き継ぐ環境変数には、認証情報が含まれ得ます。秘密情報へのアクセスが最初から一律に禁止されているとは考えず、必要な認証だけを限定して渡します。

これらは現在の設定仕様に基づく確認点です。ネイティブWindowsはこのサンドボックスに対応せず、WSL2は対応します。起動できたことだけで、狙った制限が読み込まれたとは判断できません。

コンテナ・VMは、マウントと通信先まで見る

全プロセスを囲うサンドボックス、コンテナ、VMなら、ファイル用ツールやMCP、フックも含めた外側の制限を設計できます。ただし、ホストのフォルダーを書き込み可能でマウントすれば、そこへの変更はホストにも届きます。SSH鍵やクラウド認証情報、Dockerソケットを渡すと、その分の権限を環境内に持ち込みます。

たとえば「コピーしたテスト用プロジェクトだけを書き換え、本番システムへ接続させない」用途なら、次を満たす構成にします。

公式のDev Container手順を使う場合も、Claude Codeを追加するFeatureだけでは、既定拒否のファイアウォールは付きません。:1.0はFeatureのインストール処理のバージョンで、Claude Code本体の固定バージョンではありません。本体のバージョン指定と更新設定は別に扱います。bypass用のremoteUserは非rootにし、再構築で失われるホームと、認証・履歴が残る永続ボリュームの違いも確認します。公式の3ファイル構成は実装例であり、そのまま維持されるベースイメージではありません。

モデルへの接続まで遮断すると、通常のClaude Codeの推論も動きません。必要な推論・認証用通信と、エージェントの不要な外部アクセスを区別して制限します。また、隔離しても、プロンプトや読み取った内容は設定したモデル提供先へ送信されます。「ローカルで実行するからコードが一切外へ出ない」とは言えません。全プロセスの隔離とモデル接続

よくある質問

--dangerously-skip-permissionsを付ければ、確認は全部なくなりますか？

いいえ。通常の許可確認は通過しますが、明示的なask、人の応答が必要なツール、一部の重要パスの削除チェックなどは残ります。Claudeが文章で行う質問も別です。残る確認の条件を見て、何が止めたのかを確認してください。

--allow-dangerously-skip-permissionsは安全なPlan用フラグですか？

bypassを選択可能にするフラグです。対話型ターミナルでは、これによりPlanの編集・実行ブロックが強制されなくなるため、読み取り専用の保証には使えません。-p、SDK、VS Codeのチャットは扱いが異なります。Planとbypassの組み合わせ

dontAskとbypassPermissionsは、どちらも無人実行用ですか？

確認待ちを避ける点は共通ですが、未許可の操作の扱いが違います。dontAskは確認が必要な操作を拒否し、bypassは通常の許可確認を通過します。事前に限定した操作だけを実行するなら、dontAskと許可ルールを先に検討できます。各モードの動作

Dockerやworktreeを使えば、安全にbypassできますか？

worktreeだけではOSの権限を隔離できません。Dockerも、書き込み可能なホストのマウント、認証情報、Dockerソケット、通信先によって外へ影響が及びます。アクセスできる範囲を制限した構成で判断します。外側の隔離が必要な理由

プロンプトインジェクションも防げますか？

防げません。bypassは許可判断を緩めるモードで、外部ファイルやツール結果からの不正な指示を無害化する機能ではありません。信頼できないコードを扱うときは、必要以上の権限や秘密情報を渡さず、全プロセスの隔離を検討してください。サンドボックス環境の考え方