yolo mode Codexの危険性と安全な使い分け確認ポイント

Codex yolo modeとは何か

Codexのyolo modeは、Codex CLIに用意された極めて強い権限の呼び方です。一般に次のような指定で起動します。

codex --yolo

長い形式では、次のフラグが使われます。

codex --dangerously-bypass-approvals-and-sandbox

名前が示すとおり、これは「返答を速くするモード」でも「推論を軽くするモード」でもありません。Codexがコマンドを実行する際の承認確認と、OSが適用するサンドボックスの境界を、通常の設定より大きく緩める指定です。使うモデルやプロンプトの内容を変えるものではなく、エージェントが手元の環境へ働きかけるときの制限を変えます。

OpenAI公式のサンドボックス文書では、通常のローカル作業をread-only、workspace-write、danger-full-accessという段階で整理しています。read-onlyは調査を中心にし、workspace-writeは現在の作業場所で編集や通常のコマンドを許し、danger-full-accessはファイルとネットワークの境界を取り除く設定です。yolo modeは、この最後の危険な側へ一気に移る短縮操作だと考えると、意味を取り違えません（出典: OpenAI公式サンドボックス文書）。

yolo modeは「確認を減らす」だけではない

確認画面が表示されないことだけを見ると、yolo modeは操作回数を減らす機能に見えます。しかし実際には、確認がなくなることと、サンドボックスがなくなることが同時に起きます。前者は人が止める機会を減らし、後者はコマンドが参照・変更できる範囲を広げます。二つを分けて考えないと、少しだけ許可したい場面で環境全体を開放する結果になります。

たとえば、依存関係の取得だけで外部接続が必要な場合、作業場所はそのままにしてネットワーク許可だけを検討できます。別のフォルダーにある設定を読む必要がある場合は、対象の読み取り範囲を明確にしてから広げるべきです。どちらも、yolo modeのように全境界を一度に外す必要はありません。

--yoloと--full-autoを混同しない

記事や掲示板では、確認が少ない起動方法をまとめて同じものとして扱うことがありますが、Codexの権限は同じではありません。作業場所の中で編集できる設定と、サンドボックスそのものを外す設定では、失敗したときの影響がまったく違います。コマンドの名前だけで判断せず、sandbox_modeとapproval_policyが何になっているかを確認してください。

OpenAI公式文書が示す低リスク側の組み合わせは、sandbox_mode = "workspace-write"とapproval_policy = "on-request"です。必要な場面で確認を受けながら作業場所を限定できます。yolo modeは、この組み合わせの延長ではなく、別のリスク水準にある指定です。

なぜ今 yolo modeを確認するのか

2026年5月8日、OpenAIはCodexを安全に運用するための考え方を公式記事で説明しました。そこでは、サンドボックスがファイルやネットワークの技術的な境界を定め、承認方針が境界を越える前に止める役割を持つと整理されています。低リスクの通常作業を進めやすくしながら、影響の大きい操作は明示的な確認に戻す、という分け方です（出典: OpenAI「Running Codex safely」）。

同じ時期のWindows向け解説でも、Codexを完全な権限で動かすことは、確認を減らす代わりに監視の余地を失う選択として扱われています。Windowsではネイティブの実行環境とWSL2の実行環境で、サンドボックスの仕組みが異なります。環境が違えば、同じ指定でも表示される警告や制限の見え方が変わるため、短いフラグだけを信頼するのは危険です（出典: OpenAI「Building a safe, effective sandbox to enable Codex on Windows」）。

さらに、公式のCodexリポジトリには、--yoloを付けても信頼されたフォルダーの条件で停止した事例や、ポリシーによってコマンドが拒否された事例が公開されています。これは、yolo modeがすべての境界を魔法のように消すという意味ではありません。実行環境の信頼状態、管理された制約、OSの仕組みが残る場合があります。失敗したときに、さらに強い指定を重ねるより、どの境界で止まったのかを調べる方が安全です（出典: Codex公式リポジトリのIssue #7522、Issue #10827）。

公式文書と公式リポジトリを分けて読む

公式の説明ページは、各設定の意図と推奨される境界を確認する場所です。一方、公式リポジトリのIssueは、特定の版・OS・構成で利用者が遭遇した挙動を確認する材料です。Issueの報告はすべての環境に同じ結果が出ることを保証するものではありませんが、設定の思い込みを見直すきっかけになります。

とくにyolo modeでは、「承認が出ない」と「サンドボックスがない」を一つの現象として扱わないことが大切です。前者は承認方針、後者は実行境界、途中で停止する場合は信頼フォルダーや管理設定が関係しているかもしれません。複数の層を切り分けて確認すれば、必要以上に権限を広げずに済みます。

使う前に確認する4つの判断基準

yolo modeの利用を検討する場合は、起動コマンドを先に決めるのではなく、作業環境が失敗に耐えられるかを確認します。次の4項目のどれか一つでも曖昧なら、通常のサンドボックスと個別確認に戻すのが無難です。

1. 作業場所を専用にできるか

プロジェクトのルートに個人のメモ、顧客データ、公開前の設計資料、別案件のフォルダーが混在していないかを確認します。yolo modeでは、依頼文に書いたつもりの範囲と、実際のプロセスが参照できる範囲が一致しない可能性があります。専用の作業場所を用意し、必要なファイルだけを置くことが第一の境界になります。

2. 変更を戻せるか

コードを変更するだけなら、差分を確認して戻せる場合があります。しかし、ファイル削除、設定の書き換え、依存関係の更新、データベースへの接続などは、差分だけでは元に戻せないことがあります。変更前の状態を別の場所に保存し、復旧方法を実際に確認できる場合に限って検討してください。

3. 外部接続が不要か

ネットワーク接続が入ると、取得するパッケージ、参照するページ、送信される問い合わせの範囲が増えます。何を取得し、どの接続先へ到達できるのかを説明できない作業では、yolo modeを使う理由がありません。依存関係の取得が目的なら、必要な接続先だけを許可する方法を先に調べます。

4. 結果を人が検査できるか

Codexが作った差分、実行したコマンド、テスト結果を確認する時間を確保できるかを考えます。確認できない時間帯に実行する、作業後すぐに公開や配布へ進む、結果を見ずに別の処理へ渡す、といった使い方は避けてください。速く終わることより、何が変わったかを説明できることを優先します。

安全な代替設定を選ぶ

多くの開発作業では、yolo modeの代わりに「作業場所は限定するが、低リスクの操作は止めない」設定を選べます。現在の公式サンドボックス文書で示されている代表的な指定は次の形です。

# config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

CLIで一時的に指定する場合は、次のように実行します。

codex --sandbox workspace-write --ask-for-approval on-request

この設定では、現在の作業場所にあるファイルを調査・編集し、通常のローカルコマンドを進められます。作業場所の外、ネットワーク、影響の大きい操作に進むときは確認を受ける余地が残ります。WindowsでPowerShellを使う場合も、まずこの境界で動かし、必要なフォルダーや接続だけを個別に見直す方が状況を把握しやすくなります。

目的別に権限を小さくする

依存関係の確認だけなら読み取り中心、既存ファイルの修正ならworkspace-write、外部サービスとの接続が必要なら接続先を限定する、というように目的と設定を対応させます。設定の名前を覚えることより、「どのファイルを読めるか」「どこへ書けるか」「どの操作で止まるか」を表にしてから選ぶことが重要です。

たとえば、テストの実行が目的なら、テストコマンドだけを確認付きで許可できます。リポジトリの状態確認なら、読み取り系のコマンドだけを対象にできます。すべての操作を一括で開放するのではなく、困っている操作を一つずつ特定することで、作業の速さと境界を両立できます。

rulesで特定のコマンドだけを扱う

Codexには、コマンドの先頭部分に対してallow、prompt、forbiddenを設定するRulesがあります。yolo modeのように全体の境界を外すのではなく、必要なコマンドだけを対象にするための仕組みです。公式文書では、.rulesファイルを設定層のrules/フォルダーへ置き、prefix_rule()で照合する形が案内されています（出典: OpenAI公式Rules文書）。

prefix_rule(
    pattern = ["git", "status"],
    decision = "allow",
    justification = "変更前後の状態確認に限定する",
    match = ["git status", "git status --short"],
    not_match = ["git push origin main"],
)

ただし、patternを短くしすぎると対象が広がります。gitだけを指定すれば、状態確認以外の操作まで一致する可能性があります。読み取り、確認、変更、公開などの目的を分け、必要最小限の先頭部分を指定してください。複数の規則が一致する場合は、より厳しい判定が優先されます。

実際に切り替える手順

初めてyolo modeを検討する場合は、次の順序で状態を確認します。コマンドを起動する前に、作業対象と復旧方法を確定させることがポイントです。

1. 作業場所を専用のコピーにし、個人データや別案件のフォルダーを同じ場所へ置かない。
2. 現在のブランチ、未保存の変更、実行するテスト、戻す方法を確認する。確認できない変更が残っているなら、そこで止める。
3. まずread-onlyまたはworkspace-writeとon-requestの組み合わせで同じ依頼を試し、どの操作で確認が必要になるかを記録する。
4. 拒否された操作が一つだけなら、Rulesや書き込み範囲の設定で対象を狭く調整する。全体をyolo modeへ移さない。
5. それでも隔離された検証環境で全権限が必要な場合だけ、環境に認証情報や公開前データがないこと、外部接続が制限されていることを確認する。
6. 終了後は差分、削除されたファイル、追加されたファイル、実行ログ、テスト結果を人が確認し、不要な変更を戻してから作業を閉じる。

この手順で重要なのは、5番目を最初にしないことです。yolo modeを使うかどうかは、Codexがどれほど賢く見えるかではなく、誤ったコマンドが実行されたときに被害を限定できるかで判断します。

yolo modeで起きやすい問題と対処

「信頼されたフォルダーではない」と表示される

公式リポジトリのIssueでは、--yoloを付けても「信頼されたディレクトリの中ではない」という理由で停止した事例があります。これは、yolo modeが起動時のすべての確認や、実行場所の信頼条件を消すとは限らないことを示しています。まず現在のフォルダーが意図したプロジェクトか、Gitのルートがどこか、外部の隔離環境を使っているかを確認してください。

別の場所へ移動して再試行する前に、移動先に不要なファイルがないかを確認します。--skip-git-repo-checkのような追加指定を見つけても、意味を理解せずに重ねるのは避けてください。信頼確認を省くことは、作業場所を見誤ったときの安全弁を外すことになります。詳しい事例は公式リポジトリのIssue #7522で確認できます。

「ポリシーで拒否された」と表示される

別の公式Issueでは、yolo modeでコマンドを実行しようとしても、ポリシーによって拒否された事例が報告されています。サンドボックスを外したつもりでも、実行環境のポリシーや危険なコマンドの判定が残ることがあります。これは失敗ではなく、別の層が作業を止めているサインとして扱えます。

拒否されたコマンドをそのまま別の形に変えて通そうとするより、なぜその操作が必要なのかを分解してください。読み取りだけで済むのか、対象のファイルを限定できるのか、専用の検証環境に移せるのかを見直します。公式Issue #10827の報告も、yolo modeを使えば必ず任意の危険なコマンドが通るという理解が誤りであることを示す材料です（出典: Codex公式リポジトリのIssue #10827）。

Windowsで挙動が違って見える

WindowsのPowerShellとWSL2では、Codexが利用するサンドボックスの実装が異なります。PowerShellではWindows側の仕組み、WSL2ではLinux側の仕組みが関係するため、同じプロジェクトでも警告、パス、実行ファイルの見え方が変わることがあります。まずどちらの環境でCodexが動いているかを確認し、設定を片方に合わせてから比較してください。

また、Windows側のプロジェクトをWSL2から開く場合と、WSL2側のファイルをWindowsから開く場合では、ファイルの所有やパスの扱いが変わります。yolo modeで原因を探すのではなく、通常のサンドボックスで最小の読み取りコマンドを試し、どの層で差が出るかを記録する方が安全です。

どうしても使うなら検証環境に限定する

yolo modeが完全に不要とは限りません。外部の隔離環境を自分で用意し、作業対象を使い捨てのコピーに限定し、ネットワーク接続と保存先を管理できる場合には、検証目的で使う余地があります。ただし、ここでいう隔離は「別フォルダーに置いた」だけでは不十分です。OSやコンテナの境界、保存先、接続先、復旧方法を自分で確認できる必要があります。

検証環境には、個人の認証情報、社内資料、公開前のコード、重要な設定ファイルを持ち込まないでください。外部サービスに接続する必要があるなら、接続先と送信内容を先に決めます。作業が終わったら環境を廃棄し、生成物を本番のプロジェクトへ移す前に、差分とテスト結果を人が検査します。

OpenAIが公式に説明している安全な考え方は、サンドボックスと承認を組み合わせ、低リスクの操作は境界内で進め、高リスクの操作は確認へ戻すことです。yolo modeはその考え方を日常の開発へ適用する標準設定ではなく、境界を自分で管理できる特殊な検証用の選択肢として扱う方が、用途を誤りません（出典: OpenAI公式の安全運用記事）。

まとめ

Codex yolo modeは、--yoloまたは--dangerously-bypass-approvals-and-sandboxで承認確認とサンドボックスの境界を大きく外す設定です。確認の回数を減らすだけの便利機能と捉えると、ファイル、ネットワーク、コマンドの影響範囲を見誤ります。まずworkspace-writeとon-requestで作業場所を限定し、必要な操作だけをRulesや個別確認で扱うのが基本です。

使う前には、専用の作業場所、復旧可能性、外部接続、結果を検査できる時間の4点を確認します。WindowsではPowerShellとWSL2の差も切り分けます。公式リポジトリで報告されている信頼フォルダーやポリシーによる停止は、yolo modeが万能ではないことを示しています。強いフラグを足すより、止まった境界を見つけて必要最小限だけ調整することが、Codexを長く安全に使う近道です。