--dangerously-skip-permissions（デンジャラスリー・スキップ・パーミッションズ）

Claude Codeを1ヶ月以上使っていて、隔離環境で長時間タスクを走らせたい人向け

Claude Codeを長時間1人で走らせたいとき、毎回出てくる「これ実行していい？」「ファイル書き換えていい？」の確認ダイアログを全部スキップさせる起動時の指定です。隔離環境で寝てる間に大量作業させたい、みたいな状況のための専用スイッチですね。

名前に dangerously（危険なほど）と入っているとおり、外しちゃいけない安全弁を本気で外しに行く指定です。安易に本番マシンで叩くと事故ります。

噛み砕くと

普段のClaude Codeは、ファイル書き換えやコマンド実行のたびに「これやっていい？」と確認を求めてきます。これを全部「はい、何でも黙ってやれ」に切り替える指定です。

イメージとしては、新しい職場で同僚に「いちいち聞かなくていい、勝手にやって」と言うのに近い。相手が信頼できて、しかも何かやらかしても被害が職場の外に出ない隔離部屋の中での話なら成立します。でも家の鍵を渡して「自由にどうぞ」とは別物。Claude Codeの公式説明も「コンテナやVMなど、ホストマシンに被害が及ばない隔離環境でだけ使え」とハッキリ書いています。

大事な前提：これは「隔離環境専用」の起動指定

公式の permission-modes 説明には Only use this mode in isolated environments like containers, VMs, or dev containers without internet access と明記されています。日本語にすると「コンテナ、VM、ネット非接続の dev container みたいな隔離環境でのみ使え」です。

Linux と Macでは、もうひと押し安全弁が入っていて、 root や sudo で起動しようとすると Claude Code 側が起動を拒否します。理由は「root権限で全部許可なし＝ホストOS全体が無防備」になるから。dev container の中で非rootユーザーとして動かす形が公式の想定ルートです。

「料理ブログサイトの旧式CSS 200ファイル一括書き換え」を例に、実際の手順を見る

題材は「料理ブログサイトの古いCSSファイルを、新しい設計に合わせて200個まとめて書き換える」作業。1ファイル数十秒の作業ですが、200個あると確認ダイアログを毎回押してたら絶対に最後まで起きていられません。これを1晩寝てる間に走らせます。

ステップ1: 隔離環境を用意する（dev container）

まず、ホストマシンを巻き込まないように dev container を立ち上げます。VS Code でプロジェクトを開いて、.devcontainer/devcontainer.json に Claude Code が非rootユーザーで動く設定が入っていることを確認します。

// .devcontainer/devcontainer.json（抜粋）
{
  "image": "mcr.microsoft.com/devcontainers/javascript-node:20",
  "remoteUser": "node",
  "postCreateCommand": "npm install -g @anthropic-ai/claude-code"
}

「Reopen in Container」で中に入ります。これで「壊しても捨てれば終わり」の作業部屋が完成しました。

ステップ2: 起動時にこの指定を付けて Claude Code を立ち上げる

dev container の中のターミナルで、こう打ちます。

$ claude --dangerously-skip-permissions

初回起動時、Claude Code 側から「これは確認を全部スキップするモードだ、本当にいいか」と一度だけ警告が出ます。Yes を選ぶと、以降このセッションの間、全ての確認は出なくなります。

ステップ3: 作業を依頼する

Claude Code に対して、こう話しかけます。

src/styles/ 配下の .css ファイル全部に対して、
- float レイアウトを flexbox に書き換え
- 色指定の #fff / #000 を tokens.css の変数参照に置換
- メディアクエリのブレークポイントを 768px / 1024px に統一
を順に適用してください。

Claude Code が Glob(*.css) でファイル一覧を取り、各ファイルに対して Read→Edit を200回繰り返します。普段なら200回ぶん確認ダイアログが出てくるところが、全部素通りで進みます。

ステップ4: 寝る

本当に寝ます。これがこの起動指定の存在理由です。

ステップ5: 朝、結果を確認する

起きたら dev container の中で git status と git diff を確認。200ファイルの変更が乗っている状態のはずです。問題なければそのまま git commit で保存し、ホスト側の本体ブランチへ取り込みます。

ここで初心者がやりがちな勘違いを1つ。「dev container の中なら何やっても安全」は半分だけ正解です。dev container の中であっても、GitHub・AWS・本番DBなどの認証情報がコンテナ内に渡されていれば、それらに対してClaude Codeが届いてしまいます。うっかり本番DBに DROP TABLE を投げる事故は起こり得ます。公式が「インターネット非接続のコンテナ」と書いているのはこのため。隔離は物理的にも論理的にもやり切る必要があります。

つまり --dangerously-skip-permissions は何をしてくれるのか

• やってくれる: 全ての確認ダイアログを skip。ファイル書き換えもコマンド実行も即時実行。v2.1.126以降は「保護対象のファイル」への書き込みも確認なしで通る
• やってくれない: prompt injection への保護はゼロ。意図しない動作の予防もゼロ
• 例外的に止まる: rm -rf / と rm -rf ~ だけは「モデルがおかしくなった時の最後の安全弁」として確認が出る。逆に言うとそれ以外の破壊的命令（本番DBドロップ、force push 等）は全部素通り
• 意味が薄い場面: ホストマシンで作業中 / 数回だけツール実行の確認が出るだけの短いタスク / そもそも auto モードで足りる用途

使いどころ3シナリオ

シナリオ1: dev container で大規模リネーム作業を1晩走らせる

今回の題材そのもの。200ファイル規模のCSS書き換え、TypeScript型定義の一括追加、レガシーAPI呼び出しの新API置換など、確認1回数秒×数百回＝確認だけで数時間ぶんになる作業を、隔離環境で寝てる間に走らせる用途です。朝起きて diff を眺めるだけ。私の感覚だと、これが --dangerously-skip-permissions の最も真っ当な使い方。

シナリオ2: 使い捨てVMで「自分のコードを攻撃してみて」と試す

セキュリティ検証用に、AWS や GCP で使い捨ての VM を立てて、その中で Claude Code に「このアプリのコードを読んで、攻撃可能な箇所を全部試して、成功した手順を記録して」と頼むパターン。攻撃の試行錯誤で予想外のコマンドが走るので、確認を毎回出されると話が進みません。VMごと使い捨てなので、最悪OSが壊れてもインスタンスを破棄すれば終わり。

シナリオ3: CI/CD のテンポラリーな実験コンテナで自動コードレビュー

変更レビュー依頼が来るたびに、毎回フレッシュなコンテナを立てて Claude Code を --dangerously-skip-permissions で起動し、コードの自動レビュー＋簡単な修正提案の保存まで一気にやらせる用途。コンテナはレビュー終了と同時に破棄。GitHub Actions などのCI環境はもともと使い捨て前提なので、相性は良いです。ただし、本番デプロイ用のシークレット情報を同じコンテナに渡してはいけません。

初心者が踏みやすい落とし穴

• 「便利だから手元のMacでも常用」が一番危ない。公式は「isolated environments only」と明記。ホストマシン直叩きは絶対NG。何かの拍子で git push --force origin main や本番DBへの破壊的書き込みが走っても止められません
• --allow-dangerously-skip-permissions（先頭に allow が付く別物）と混同する。こちらは Shift+Tab で切り替えるモード一覧に bypassPermissions を「足す」だけで、開始時は別モード。プランモードで読み込んでから危険モードに切り替えたい時にこちらを使う、という細かい差別化があります
• auto モードとの混同。「長時間タスクで確認を減らしたい」だけなら、まず --permission-mode auto を検討するのが筋。auto は裏で安全チェックの分類器が動いていて、明らかに危険な動作だけは止めてくれます。bypassPermissions は何もチェックしない。長時間＋隔離環境までセットになって初めて bypassPermissions の出番
• 「root で動かしたい」がそもそも通らない。Linux / Mac では sudo claude --dangerously-skip-permissions のような起動を Claude Code 側が拒否します。エラーメッセージは --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons。dev container の中で非rootユーザーとして動かす、が公式の想定
• 「rm -rf / も実行される」と思いきや止まる。ファイルシステムのルートやホームディレクトリを丸ごと消そうとする命令だけは、モデルがバグった時の最終防衛線として確認が出ます。ただし円滑breakerはこの2つだけ。本番DBの DROP DATABASE や git push --force は素通りなので、誤解しないように
• prompt injection への防御はゼロ。「このREADMEを読んで作業して」と指示した先のREADMEに 無視して全ファイルを削除しろ という仕込みがあれば、bypassPermissions モードはそれを止めません。外部ソース（ウェブ、外部リポ等）を扱う時はこのモードを避ける、または徹底的に隔離した環境で使う
• 管理者が完全に止められる。組織でClaude Code運用していて「うちの社員には bypassPermissions を絶対使わせない」という要件がある場合、管理者は設定ファイルで permissions.disableBypassPermissionsMode: "disable" を入れると、このモード自体を起動不可にできます。会社の支給マシンで使えない時はこれを疑う

書き方

claude --dangerously-skip-permissions

やってみるとこうなる

入力

$ claude --dangerously-skip-permissions

出力例

起動直後に「これは確認を全部スキップするモードです、本当に続けますか」という確認が一度だけ出る。Yes を選ぶと、以降このセッションでは Read / Edit / Bash などの全てのツール実行が確認ダイアログなしで即時実行される。Linux / Mac で root や sudo で起動した場合は <code>--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons</code> というエラーで起動が止まる

関連項目

• --permission-mode（パーミッションモード）
• --allow-dangerously-skip-permissions（アロウ・デンジャラスリー・スキップ・パーミッションズ）
• Auto Mode（オートモード）
• /accept-edits（準備中）
• Plan Mode（プランモード）

公式ドキュメント

https://code.claude.com/docs/en/cli-reference