Claude Code --dangerously-skip-permissions: 使い方と制限

claude --dangerously-skip-permissionsはClaude CodeをbypassPermissionsモードで起動する。ファイル変更やシェルコマンド、ツール呼び出しのたびに表示される承認プロンプトを省略できる。ファイルや認証情報、ネットワークアクセスをあらかじめ制限した使い捨て環境で、限定的なタスクを実行する際に使う。このフラグ自体がサンドボックスを作成するわけではない。

claude --dangerously-skip-permissions

コマンドはこれだけだ。ただし、無人ジョブに組み込む前に、プロセスがどこまでアクセスできるかを確認してほしい。使い捨てのチェックアウト環境で承認をスキップするのと、本番環境の認証情報が入ったノートPCでスキップするのとでは、万が一の際のリスクが全く違う。

ここでは、このコマンドの挙動や代替手段、具体的な実行とレビューのワークフローを見ていく。Anthropicのドキュメントは2026年10月6日時点のものだ。記載している例はセットアップ手順を示すものであり、Claude Codeのセキュリティテスト結果ではない。

dangerously-skip-permissionsの機能

このフラグはclaude --permission-mode bypassPermissionsと同じ権限モードを選択する。Claudeは承認待ちで止まることなく作業を進められる。起動したプロセスのOSユーザーIDとアクセス権はそのまま引き継がれる。root権限を勝手に付与したり、認証情報を捏造したり、環境側でブロックしているネットワークへのアクセス経路を作ったりすることはない。Claude Codeの権限モード。

ただし例外もある。現在のリリースでは、明示的な拒否ルールや確認ルール、特定の重要なパスの削除に対するチェック、ユーザーの操作が必要なアクションはスキップされない。だからといって、これらの例外を任意のファイルやクラウドリソースの保護機能として過信してはいけない。ファイルシステムのルートを削除しなくても、プロジェクトを破壊するコマンドは実行できてしまう。

特に注意したいのは、バイパスモードだと保護パスのプロンプトなしで.gitや.claudeに書き込めることだ。検索エンジンの要約などでは「これらのフォルダは常に保護される」と書かれていることがあるが、現在の公式ドキュメントにそのような記載はない。権限設定のリファレンス。

「失敗しているテストを修正して」というよくあるリクエストを考えてみる。Claudeはテストを書き換え、パッケージをインストールし、設定を変更するだろう。もしそのプロセスがクラウドのAPIキーを読み取ってAPIを叩ける状態なら、ローカルフォルダを使い捨てにするだけではリモートへの影響を防げない。実行前に、環境のセットアップ段階でアクセスを絞っておく必要がある。

対話型および無人での使用向けコマンド

対話型セッションの開始

準備した環境でターミナルを開き、以下を実行する。

claude --dangerously-skip-permissions

タスクを指示する前に、表示された権限モードを確認してほしい。初回の対話型起動時には、同意を求める警告が出ることもある。rootやsudo関連のエラーが出た場合は、ホスト側の保護設定を緩めるのではなく、環境内の非rootアカウントを使うようにする。モード設定とroot権限の制限。

1つのタスクを実行して結果をキャプチャする

APIキー認証を使う現在のClaude Codeリリースでは、以下のようになる。

claude --bare -p \
  "Fix the failing unit test in this checkout. Run the relevant tests. Report changed files and failures. Do not commit or push." \
  --dangerously-skip-permissions \
  --max-turns 12 \
  --output-format json > /tmp/claude-result.json

ここで、-pは非対話型タスクを実行し、--output-format jsonはランナーが応答を収集しやすくするためのものだ。--max-turnsはエージェントのループ回数を制限するが、ジョブ自体の実行時間を制限するわけではない。タイムアウトはランナー側で設定する必要がある。CLIフラグのリファレンス。

--bareをつけると、通常の環境フックやプラグイン、メモリ、リポジトリの指示を読み込まなくなる。AnthropicのAPIを使う場合はANTHROPIC_API_KEYが必要だ。サブスクリプションのOAuthログインは使わず、ランナーのシークレット設定経由でキーを渡す。古いリリースを使っている場合は、この例をコピーする前にサポート状況を確認してほしい。プログラムからの実行とbareモード。

プロンプトにある「コミットやプッシュをしないこと」は、あくまでタスクの意図を伝えているにすぎない。実際にこれを強制するには、リモートリポジトリへの書き込み権限を与えないことだ。プロンプトに書いた1文が、適切な認証情報のスコープ設定やネットワークポリシーの代わりになるわけではない。

結果の収集や失敗したジョブの処理について詳しくは、Claude Codeのヘッドレス実行ガイドを参照してほしい。

セッションの後半でバイパスを有効にする

似た名前のフラグがあるが、効果は異なる。

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

--allow-dangerously-skip-permissionsは後からバイパスを選べるようにするだけで、最初からバイパス状態で起動するわけではない。切り替えるにはターミナルのShift+Tabモードサイクルを使う。起動時にバイパスを有効にしなかった場合は、有効化フラグを付けて再起動する。CLIリファレンス。

autoモードとdangerously-skip-permissionsの比較

タスクを完了できる範囲で、最も権限の少ないモードを選ぶのが基本だ。

モード名と挙動は権限設定のリファレンスに基づいている。

autoモードは、シェルコマンドや外部ツール呼び出しなどのアクションをレビューするために別の分類器を使う。危険なアクションをブロックし、Claudeに別のアプローチを試させることができるが、分類器が間違えることもある。Anthropicはこれを承認の手間を減らす方法として説明しており、手動レビューや完全なバイパスとは異なるトレードオフがある。Anthropicによるautoモードの仕組みの解説。

何度もプロンプトが出るのが煩わしいだけなら、アカウントが対応している限り、まずはautoモードを試すといい。

claude --permission-mode auto

ジョブに必要なツールが決まっているなら、許可ルールを絞ったdontAskを検討する。これは自動化に向いている。権限がない場合、人間の承認を待ってジョブを止めるのではなく、単にアクションを失敗させるからだ。ルールを広げる前に、どのアクションが拒否されたのかを確認できる。

Claude Codeのサンドボックスはバイパスを安全にするか？

Claude Codeに組み込まれたBashサンドボックスは、ファイルやネットワークへのシェルアクセスを制限する。自動許可オプションを使えば、プロンプトなしでサンドボックス内のコマンドを承認できる。このオプションはautoモードの分類器とは別物だ。Bashサンドボックスの設定。

ただし、組み込みのBashサンドボックスがアプリケーション全体を保護するわけではない。ファイルツールやMCPサーバー、フックには、それぞれ独自の境界を設けるか、Claude Codeプロセス全体を囲い込む外部環境が必要になる。VMとコンテナでも分離のレベルは異なる。実行するコードと、どこまでの障害なら許容できるかに応じて選んでほしい。サンドボックス環境の比較。

再試行の挙動も確認が必要だ。バイパスが有効だと、サンドボックス化されていない再試行が確認なしで走ってしまう可能性がある。サポートされている環境なら、以下の設定でサンドボックスの起動を必須にし、無防備な再試行を防ぐことができる。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

excludedCommandsのエントリも確認する。これらは依然としてBashサンドボックスの外で実行される可能性がある。設定を確実に強制したいなら、エージェントが編集できない管理ポリシーを使う。厳格なサンドボックス設定。

無人実行のための実践的なワークフロー

失敗している小さなテストを修正するタスクを例に挙げる。欲しい出力はパッチとテストレポートだけだ。このジョブにデプロイ権限を持たせる理由はない。

1. 別のチェックアウトを準備する

新しいコンテナかVMを作り、特定のコミットのリポジトリをコピーする。メインの作業ディレクトリを書き込み可能にしてマウントするより、コピーを渡す方がいい。ワークツリーは変更を分けるのには役立つが、OSや認証情報まで分離してくれるわけではない。

セットアップ時に必要なランタイムとパッケージをインストールし、開始時のコミットとツールのバージョンを記録しておく。エージェントは非rootアカウントで動かす。開発コンテナを使う場合は、マウント設定を確認する。ホストのディレクトリを書き込み可能にしてしまうと、コンテナ内からホストのファイルを編集できてしまう。Anthropicの開発コンテナのガイドに、セットアップと制限事項がまとまっている。

2. ジョブに必要なアクセスのみを与える

モデルの認証情報は個別に渡す。リポジトリがプライベートなら、チェックアウトには読み取り専用のアクセス権を使う。デプロイキー、SSHエージェント、Dockerソケット、無関係なホームディレクトリのファイルなどは環境に入れない。

モデルのエンドポイントと、タスクに必要なパッケージやソースのホストへの通信だけを許可する。環境のネットワーク制御を使って、それ以外の外向き通信を制限する。依存関係のダウンロードに失敗した場合は、むやみに通信先を開放するのではなく、本当に必要なホストを特定してから許可する。

タスクに必要なMCPサーバーがあるなら、ここで決めておく。データベースやクラウドへのMCP接続を許可すると、ローカルのファイルシステムが使い捨てでも、リモートを操作できてしまう点には注意が必要だ。

3. 明確な終了条件でタスクを実行する

認証と依存関係の準備ができたら、先ほどのヘッドレスコマンドを実行する。ジョブにはランナー側でタイムアウトを設定し、終了ステータス、標準出力、標準エラー出力を記録する。エージェントが書いたサマリーだけを鵜呑みにしないよう、テストコマンド自体はこちらで制御する。

1つの失敗しているテストや、すでに報告されている1つのバグなど、小さな変更から始めるのが無難だ。「リポジトリ全体をクリーンアップして」といった指示は、レビューしきれないほどの変更を生むリスクがある。

4. 実際のファイルをレビューする

ジョブが終わったら、チェックアウトした環境を調べる。

git status --short
git diff --stat
git diff --check
git diff
git ls-files --others --exclude-standard

最後のコマンドは、通常のdiffでは見逃しがちな未追跡ファイルをリストアップするものだ。これも確認する。勝手にコミットされて作業ツリーのdiffから変更が隠れていないか、最終コミットと開始コミットを比較する。信頼できるランナーでテストを再実行し、パッチをレビューしてからマージする。

環境を破棄する前に、必要なファイルをエクスポートしておく。ログや成果物に認証情報が混ざらないように注意する。レビュー用のデータが確保できたら、タスクに使った認証情報を無効化し、使い捨てワークスペースを削除する。

Lizard Sandboxesを使う場面

LizardのSandboxesを使えば、このパターンのためのリモートワークスペースを用意できる。環境を作り、タスクを実行し、ファイルを回収して停止する。ランナーが失敗して環境が動きっぱなしにならないよう、明示的な有効期限を設定しておく。Sandboxesクイックスタートから始められる。

脅威モデルに合わせて選ぶ前に、ランタイムを確認してほしい。Sandboxesは、それぞれ独自のカーネルを持つFirecracker microVMとして動作する。ただし、既存のポッドベースのPersistent Volumeをアタッチするサンドボックスや、古いポッドスナップショットを復元するサンドボックスは、Kubernetesポッド（runc）として動作し、ホストカーネルを共有する。Lizard SDKでは、getInfo().runtimeでどちらが使われているかを確認できる。どちらの場合でも、認証情報のスコープは絞っておく。ランタイムのドキュメント。

リモート実行は、ジョブごとに新しいワークスペースが欲しい場合や、大量のジョブを並行して回す場合に便利だ。それでも、ネットワークポリシーとレビューの工程は欠かせない。本番データベースのトークンを持たせてしまえば、サンドボックスがどこで動いていようと、そのデータベースにはアクセスできてしまう。

よくある質問

デフォルトでdangerously-skip-permissionsを使用できるか？

はい。専用のコンテナまたはVMでワーカーを動かす場合は、そのワーカーの実行ユーザーの~/.claude/settings.jsonに次の設定を追加する。

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

以後、新しいターミナルセッションはバイパスモードで起動する。この既定値は使い捨てのワーカー内に限定し、単発のジョブでは起動フラグを明示する。現在のバージョンでは、リポジトリの.claude/settings.jsonや.claude/settings.local.jsonにこの値を設定してもバイパスは有効にならない。組織の管理ポリシーがこのモードを無効にしている場合もある。設定の適用範囲と優先順位。

サブエージェントはバイパス権限を継承するか？

はい。現在のドキュメントの仕様では、メインの会話がバイパスモードだと、サブエージェント自身の権限設定を上書きして同じモードで動かす。サブエージェントは独立したセキュリティ境界ではない。サブエージェントの権限。

なぜClaudeはまだ質問してくるのか？

承認プロンプトと、タスクに関する質問は別物だ。バイパスモードでも対話が必要なアクションはあるし、設定した確認ルールが適用されることもある。フラグが効いていないと判断する前に、実際のプロンプトを読んでほしい。無人ジョブの場合は、期待する出力と失敗時の挙動をあらかじめ指定しておく。

このフラグはClaude Codeを無料にしたり、レート制限を解除したりするか？

いいえ。これはあくまで権限の処理を変えるだけのものだ。認証や利用料金、レート制限は引き続きモデルプロバイダー側で管理される。承認プロンプトが出なくても、再試行を繰り返せばそれだけトークンを消費する。

普段の作業なら、まずはautoモードかBashサンドボックスの自動許可オプションを試すといい。無人でバイパス実行させるなら、環境を使い捨てにし、アクセス範囲を絞り、メインプロジェクトに影響が出る前に結果のファイルをレビューする。