Claude Codeを使い込んでいる人なら、誰もが同じ壁にぶつかります。リファクタリングの真っ只中で、エージェントが快調に進んでいたのに、ふと止まる。「Allow Bash command?」。承認します。30秒後、また確認。承認。さらにもう一度。10回目の中断を迎える頃には、ドキュメントを開いて claude --dangerously-skip-permissions を見つけ、もう後戻りしません。
このフラグは、その名前が警告するとおりのことを行います。あらゆる操作において、人間をループから外してしまうのです。この記事では、このフラグが実際に何をオフにするのか、使った開発者たちの身に実際に何が起きたのか、そして多くの人が存在を知らない第3の選択肢を解説します。一度定義したルールの範囲内で、エージェントをフルスピードで動かすという方法です。
誰もがこのフラグに手を伸ばす理由
Claude Codeに権限システムが組み込まれているのには、正当な理由があります。エージェントはシェルコマンドを実行し、ファイルを書き込み、外部ツールを呼び出せるからです。デフォルトでは、リスクのある操作は一時停止し、あなたの承認を待ちます。
問題は摩擦です。1つの機能ブランチだけでも、数十回のファイル書き込みやシェルコマンドが発生し得ます。そのたびにクリックが必要なら、「自律型」のはずのエージェントは、1分ごとに割り込んでくる非常に賢いアシスタントになってしまいます。開発者は当然の行動に出ます。RedditやXでは、権限をオフにしてClaude Codeを実行することがあまりに一般的で、「YOLOモード」というニックネームまで付いています。
Anthropicがこのフラグを用意したのは、限られた目的のためです。承認をクリックする人が誰もいない、CI/CDパイプライン内のDockerコンテナのような、完全自動化された非対話型の環境です。LinuxとmacOSでは、Claude Codeはrootまたはsudo権限でこのモードを起動することすら拒否します。開発元自身がこのフラグをどう使うことを想定しているのかが、ここからうかがえます。
「サンドボックス化されたCI向けに設計された」使い方と、「何千人もの開発者が実際にノートPCで実行している」使い方とのギャップ。トラブルが潜んでいるのは、まさにそこです。
このフラグが実際に無効にするもの
claude --dangerously-skip-permissions で起動すると、エージェントが行うほぼすべての操作について、承認のチェックポイントがオフになります。実際には、Claude Codeは確認なしで次のことができるようになります。
- 任意のシェルコマンドの実行（パッケージのインストール、git操作、ネットワーク呼び出しを含む）
- ユーザーアカウントが到達できる場所であればどこでも、ファイルの作成、上書き、削除（プロジェクト内に限りません）
- 設定済みのあらゆるMCPツールの呼び出し（それらのツールが持つアクセス権限のまま）
ごく一部の極端なケースでは、バイパスモードでもプロンプトが表示されます。最近のバージョンでは、文字どおりの rm -rf / と rm -rf ~ は止められ、マネージド設定レベルで設定された拒否ルールは引き続き絶対的に有効です。これらの安全策は重要ですが、範囲は限られています。誰かがハードコードしようと考えた正確なパターンしか捕捉せず、それ以外は捕捉しません。
最後の点は、じっくり考えてほしいところです。この保護は既知の危険な文字列のブロックリストにすぎず、破壊的なコマンドの空間は無限にあります。
YOLOモードが裏目に出るとき：実際のインシデント
これらは仮定の話ではありません。
記録されている事例の1つでは、開発者がファームウェアのプロジェクトに取り組んでいたところ、Claude Codeがルートから始まる rm -rf を実行しました。エラーログは、/bin、/boot、/etc などのパスに対する「Permission denied」の行で何千行も埋め尽くされました。マシンが無事だった唯一の理由は、OSが削除の大半を拒否したことです。エージェントは削除しようとしたのです。
2025年12月には、r/ClaudeAIへの投稿が、さらに深刻な事例を伝えました。削除が成功してしまったからです。ユーザーは、古いリポジトリのパッケージを整理するようClaudeに依頼しました。エージェントが生成したのは rm -rf tests/ patches/ plan/ ~/ でした。最後の引数に注目してください。末尾の ~/ は、ユーザーのホームディレクトリ全体に展開されました。すべて消えたのです。
2つのインシデントに共通する点に注目してください。破壊的なことをするよう、誰もエージェントに頼んでいません。整理作業とファームウェアのビルドがデータ損失につながったのは、言語モデルがもっともらしく見えるコマンドに壊滅的な引数を付けて生成し、生成から実行までの間に何も立ちはだかるものがなかったからです。
「流れていくコマンドを見ながら確認すればいい」というのも、防御にはなりません。そもそもこのフラグを有効にしたのは、確認をやめたからです。
第3の選択肢：プロンプトではなくポリシー
この議論は、たいてい二者択一で語られます。すべての操作を手動で承認して、安全だが遅いままでいるか、権限をスキップして、速いが無防備になるか。第3の立場があります。エージェントは自律的なままにしつつ、実行される前にすべての操作をルールに照らしてチェックするのです。
これが、実行前ポリシーチェックの役割です。Claude Codeはフックをサポートしており、フックは各ツール呼び出しの前に実行されます。フックをポリシーエンジンに向ければ、エージェントが生成するすべてのコマンドが、まずあなたのルールに照らして評価されます。ロジックは次のようになります。
filesystem:deleteがプロジェクトディレクトリ内：許可filesystem:deleteがそれ以外の場所：拒否- mainへの
git:push：承認を必須にする - 日常的な操作はすべて：許可し、ログに記録する
明らかに問題のない操作の95%については、エージェントが確認プロンプトを目にすることは一切ありません。あなたを傷つけかねない残り5%は、自動的にブロックされるか、人間の判断待ちとして保留されます。拒否は決定論的です。モデルが慎重な気分かどうかに左右されず、1万回目のツール呼び出しでも1回目と同じように機能します。
Control Zeroは、この考え方を軸に作られています。エージェントに許可することをあなたが定義し、実行前にポリシーが適用され、すべての判断が監査ログに記録されます。この構成であれば、2025年12月のインシデントは違う結末を迎えます。~/ を引数に持つ rm -rf は拒否ルールに一致し、コマンドは実行されず、ログに残るのは空になったホームディレクトリではなく、ブロックされた1件の操作です。
実践のポイント
--dangerously-skip-permissionsは、使い捨てできる環境以外では決して使わないでください。SSHキーやdotfiles、失うと困るものがあるマシンには、このフラグは持ち込むべきではありません。- YOLOモードをどうしても使うなら、封じ込めてください。ボリュームをマウントしていないDockerコンテナや使い捨てのVMなら、被害の範囲を再構築できるものだけに限定できます。
- プロンプトからポリシーへ移行しましょう。実行前フックを設定し、プロジェクトディレクトリ外での破壊的な操作を、あなたの反応速度ではなくルールによって拒否します。
- すべてをログに記録しましょう。許可した操作であっても、監査証跡があれば、「今、何が起きたのか」は、フォレンジック調査ではなく検索で確認できます。
- MCP設定を見直してください。権限のスキップは追加したすべてのMCPツールに適用され、1つ追加するごとに、無人のエージェントが到達できる範囲が広がります。
問題はスピードではありませんでした
開発者がこのフラグを有効にするのは、不注意だからではありません。もう一方の選択肢が承認プロンプトによる「死」であり、生産性の向上が本物だからです。間違いは、このフラグが突きつける二者択一を受け入れてしまうことにあります。摩擦を全面的に受け入れるか、保護をゼロにするか、という二択です。
ポリシーは、その二者択一を打ち破ります。境界を一度定義し、その内側ではエージェントをフルスピードで動かし、1万回に1回のコマンド、つまりあなたの1週間を台無しにしていたはずのコマンドを、決定論的なルールに捕まえさせるのです。コーディングエージェントは、これからさらに自律性を高めていきます。問うべきなのは、モデルを信頼するかどうかではありません。あなたの安全網が、あなたがターミナルを見張っていることに依存していないかどうかです。
ポリシーによるアプローチを2分で確かめてみませんか？pip install controlzero は、アカウントもネットワークも不要で、ローカルで動作します。拒否ルールを1つ書いて、破壊的な呼び出しがブロックされる様子をご覧ください。Control Zeroクイックスタート