Claude Code --dangerously-skip-permissions：何を外し、いつ使わないか

Claude Code --dangerously-skip-permissions は、クリックを減らすだけの便利オプションではありません。現在の権限モードでは --permission-mode bypassPermissions に相当し、Claude Code が通常の確認プロンプトを挟まずに進む状態を意味します。ファイル編集、シェルコマンド、ネットワークアクセス、ツール実行のような副作用のある動作で、人間が止めて確認する機会が減ります。2026 年 5 月 7 日時点の実務ルールは明確です。普段の開発端末、本物のシークレットがあるシェル、デプロイや削除ができる環境では、標準の起動方法にしてはいけません。

まず決めるべきなのは、何の摩擦を減らしたいのかです。単に編集確認が多いだけなら acceptEdits を先に検討します。長く反復的な作業で、バージョン、プラン、モデル、provider、利用画面の条件が合うなら Auto mode を確認します。未知のリポジトリや影響範囲が広い変更では、通常モードか plan から始めます。完全な bypass は、失敗しても一時環境だけが壊れるように隔離できた場合の最後の選択です。

短い判定：

• 初めて見るコード、原因調査、影響範囲が不明: default または plan。
• 予測できる編集確認だけを減らしたい: acceptEdits。
• 反復的で低リスクの長い作業: 条件を満たすなら Auto mode。
• シークレット、prod、DB、クラウド権限、デプロイが見える: bypass しない。
• ファイル、ネットワーク、認証情報、コマンド範囲、戻し方を隔離できた: そこで初めて bypassPermissions を検討する。

まず結論：このフラグが外すもの

Claude Code の権限モード文書では、--dangerously-skip-permissions は --permission-mode bypassPermissions と同じ契約として扱われます。これはモデルの判断力を上げる機能ではありません。確認プロンプトという制御面を外し、通常ならユーザーが見る場所を通過しやすくする設定です。

確認プロンプトは面倒ですが、単なる邪魔ではありません。どのファイルを書こうとしているのか、どのコマンドを実行するのか、ネットワークへ出ようとしているのか、タスクがいつの間にか危険な範囲へ広がっていないかを確認する安いチェックポイントです。たとえばドキュメント修正のつもりが install script を走らせる、テスト実行のつもりが生成物を大量更新する、設定確認のつもりが .env を読みにいく、といったズレはここで見つかります。

先にモードを選びます：

コマンドより前にこの表を置く理由は、起動自体は簡単だからです。難しいのは、悪いアクションがどこまで届くかを先に小さくすることです。

権限モードの階段：必要な段だけ上がる

Claude Code の権限は、確認を消すスイッチではなくリスクの階段として見ると判断しやすくなります。通常モードは未知の作業に向いています。副作用のある操作の前に止まるため、ファイル、コマンド、対象、意図を確認できます。調査、初回導入、依存関係、設定、認証、リリース周辺では、この一時停止が価値になります。

plan は、コマンドそのものより方針が危ない場合に使います。移行、権限変更、横断的リファクタ、課金ロジック、データ処理では、いきなり編集するより先に計画を固定した方が安全です。間違った道筋を早く止める方が、後で個別コマンドを止めるより安く済みます。

acceptEdits は、多くの承認疲れに対する現実的な答えです。Claude Code にファイル編集を任せつつ、shell、network、外部ツールの判断は残せます。ドキュメント、テスト、型修正、小さな整理では、完全 bypass を使わなくても十分に速くなります。

Auto mode は中間の選択です。ユーザーが多くのプロンプトを承認していた一方で、完全な bypass は開きすぎていたために用意されたものです。ただし、利用可否は Claude Code のバージョン、プラン、モデル、provider、利用表面に依存します。古い説明の対象プランやモデルをそのままコピーせず、自分の環境で確認する必要があります。

dontAsk と bypassPermissions は、環境側に安全を寄せる領域です。ここで大事なのは「Claude を信じる」ではなく「この環境には壊されて困る権限がない」です。home directory、SSH key、cloud CLI、社内ネットワーク、ブラウザログインが見えるなら、階段を上がる条件を満たしていません。

赤線：この作業では bypass しない

共有システムを壊す、秘密情報を漏らす、不可逆の状態を作る、金銭や権限を変える可能性があるなら、--dangerously-skip-permissions は間違った近道です。これは Claude Code だけの問題ではなく、shell、ファイル、ネットワークを持つ自動化エージェント全般の問題です。

避けるべきカテゴリ：

• 本番 deploy、rollback、release promotion、service restart。
• database migration、destructive query、bulk data change。
• Terraform、IAM、cloud resource、repository permission、billing。
• secret rotation、token search、.env cleanup、credential debugging。
• downloaded code execution、unknown install script、curl | bash、未確認 binary。
• force push、protected branch への direct push、大量削除。
• 実環境の credential、cloud CLI、SSH、管理ブラウザセッションがある作業。

Auto mode のブロック例も同じ発想です。downloaded code、production deploy、migration、sensitive data exfiltration、cloud storage mass deletion、IAM、repo permission、shared infrastructure、irreversible destruction、force push、direct push to main は、確認を減らす対象ではありません。

チームで使うなら、禁止条件を alias や wrapper にも入れるべきです。main branch、汚れた diff、production token、deploy script、migration script、cloud profile が見えるなら起動を止めます。これは bypass を安全にする工夫ではなく、起動すべきでない場面を早く失敗させる仕組みです。

bypass 前の隔離チェックリスト

Claude Code の sandboxing 文書が示す重要点は、ファイルシステムとネットワークの両方を狭めることです。新しい branch は sandbox ではありません。Docker も、host mount、広い egress、本物の credentials、cloud CLI、社内 API があるなら sandbox ではありません。

最低限の確認：

準備の例：

bash
git status --short
git worktree add ../tmp-claude-bypass-work -b claude-bypass-test
cd ../tmp-claude-bypass-work

速度より先に権限を外します：

bash
env | grep -E 'TOKEN|KEY|SECRET|AWS|GCP|AZURE|ANTHROPIC|OPENAI'
ls -la | grep -E '\.env|credentials|secrets'
git diff --stat

ここで本物の credential や広い workspace が見えたら止めます。必要なのは勇気ではなく、失敗の価格を下げる設計です。隔離できないなら、確認プロンプトを外す理由もありません。

利用表面：CLI、IDE、Remote Control、cloud、CI を分ける

すべての Claude Code 表面が同じ権限を出すとは限りません。local CLI は起動フラグ、permission mode、/permissions を確認しやすい場所です。IDE、Remote Control、cloud session、non-interactive run はそれぞれ別の制約を持ちます。

Remote Control は、別端末から承認や方向修正をするための表面です。Auto mode は、一部の長い低リスク作業で確認を減らすための中間層です。完全 bypass は、それらと同じものではありません。用途を混ぜるほど、誤った安全感が生まれます。

安全判断後のコマンド

境界を確認してから、初めてコマンドを出します。

bash
claude --permission-mode bypassPermissions

よく見かける alias は次です。

bash
claude --dangerously-skip-permissions

新しい runbook では、前者の方が現在の permission mode 名とそろいます。既存 script、issue、同僚の再現手順では後者が出てくることがあります。どちらも同じ安全契約に属することを明記してください。

起動前に確認します。

bash
claude --version
claude --help

会話内では次を使います。

text
/permissions

作業中に mode を変えたなら、commit message や作業メモに残します。reviewer が diff だけ見ても、いつから確認なしで走っていたのか分からない状態が一番危険です。

バージョン差にも注意します。2026 年 5 月 7 日に確認した docs では、v2.1.126 以降の protected paths と root/home deletion の扱いに触れています。これは永続保証ではなく、日付付きの現在値です。最初から危険な filesystem を見せない方が安定します。

まだ確認が出る、または mode が見えないとき

最初に利用表面を見ます。cloud session、Remote Control、IDE、local CLI は同じではありません。ある表面で見えないことは、permission mode 全体が消えた証拠ではありません。

次に、Auto mode と bypass を混同していないか確認します。Auto はより安全な少確認ルートですが、バージョン、プラン、モデル、provider、表面条件があります。見えない場合は eligibility の問題かもしれません。

三つ目は circuit breaker です。bypass 中でも root や home directory の削除で止まる場合、それは通常の安全確認ではなく非常停止に近いものです。存在するから安全、ではありません。

四つ目は managed settings です。組織が allowlist、denylist、dev container、audit policy を入れている場合、ローカル挙動は公開例より狭くなります。そこで権限を広げるのではなく、組織ポリシーに合う運用に直すべきです。

最後に、Claude Code が危険な方向へ進み続けるなら権限を上げないでください。plan で範囲を戻す、acceptEdits で編集だけ楽にする、条件が合うなら Auto を使う、という順番に戻ります。

よくある質問

--dangerously-skip-permissions と bypassPermissions は同じですか？

はい。現在の権限モード文書では同じ契約として扱われます。古い flag と現在の mode 名をチーム内で対応付けてください。

Docker なら安全ですか？

本当に隔離されている場合だけです。host mount、広い network、real credentials、production CLI がある Docker は、普通の危険な端末とほぼ同じです。

ただ確認が面倒なだけなら？

まず acceptEdits です。編集確認を減らしつつ、コマンドやネットワークの判断を残せます。条件が合うなら Auto mode も候補です。

prompt injection を防げますか？

防げません。bypassPermissions は prompt injection や unintended actions への保護を提供しません。外部ファイルや依存関係が会話に影響するなら、確認なしはリスクを広げます。

CI で使えますか？

標準にはしない方がよいです。CI は secrets、deploy、package publishing、shared infrastructure とつながりがちです。必要なら narrow script、dry run、approval gate、権限のない sandbox を設計してください。

一番安全な実務ルールは？

実際の摩擦を解く最小権限を使います。編集疲れは acceptEdits、条件を満たす長時間作業は Auto、完全 bypass は本物の権限を持たない使い捨て隔離だけです。