Codexには、ファイルを編集し、コマンドを実行し、その都度止まらずに作業を進めてほしい。そう思って「Full Access」を選んだのに、なぜか承認を求められることがあります。原因と、完全放置で動かすための設定を先にまとめます。検証環境はCodex CLI v0.145.0です。
確認が出る理由: Codexの「Auto mode」は単一のスイッチではありません。サンドボックスはアクセス可能な範囲を、承認ポリシーはユーザーへの確認タイミングを決める別々の設定です。さらにネットワークアクセスにも独立した制限があります。どれか一つを緩めても他は変わらず、Codexの更新後にはセッションの設定がデフォルトポリシーへ戻ることもあります。
CLIで完全放置にするなら: すべての制限を一度に外すフラグは--yoloだけです。サンドボックスを維持しつつ安全寄りに運用するなら、2つの軸を明示的に指定してください。セッション開始時に設定し、更新後にも再確認するのが確実です。
# 完全放置 — サンドボックスも確認もなし（使い捨て環境限定）:
codex --yolo
# より安全な設定 — プロジェクト内は自由に編集でき、外へ出る際は確認する:
codex --sandbox workspace-write --ask-for-approval on-requestアプリで完全放置にするなら: 承認メニューからFull accessを選びます。アップデートでモードがリセットされるため、更新のたびに選び直してください。
要点は以上です。以降では、各モードの違い、内部設定との対応関係、用途ごとの選び方を整理します。
Codexの3つの承認モードを比較
サンドボックスはエージェントが触れられる対象（ファイル、ネットワーク）を決め、承認ポリシーは作業を止めて確認する場面を決めます。Auto modeはこの2つを組み合わせたプリセットであり、デスクトップアプリとCLIでは同じ組み合わせでも名称が異なります。
| アプリ上の表示 | 動作 | CLIでの相当設定 |
|---|---|---|
| Ask for approval | ワークスペース内のファイル編集と通常のローカルコマンド実行は許可。インターネット接続やワークスペース外へのアクセス前に確認する | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me（現在のアプリのデフォルト） | 範囲は同じだが、対象となる承認リクエストはあなたではなくAIレビュアーに送られる（Auto-review） | 上記 + approvals_reviewer = "auto_review" |
| Full access | サンドボックスも承認プロンプトもなく、ファイルとネットワークへのアクセスは無制限 | sandbox_mode = "danger-full-access" + approval_policy = "never" |
CLIを主に使うなら、--sandboxと--ask-for-approvalで直接指定できます。セッション中に変更する場合は、/permissionsピッカーでプリセットを切り替えます。そもそもクライアント選びで迷っている場合は別の論点です。CodexとClaude Codeの比較はこちらを参照してください。この記事では設定そのものに絞ります。
「Full Access」なのに承認を求められる3つの理由
理由は3つあり、複数が同時に影響することもあります。
サンドボックスと承認は別設定です。 workspace-writeとon-requestの組み合わせでは、Codexはプロジェクト内を自由に編集できますが、境界を越える処理で止まります。たとえばネットワーク呼び出し、リポジトリ外のファイル、sudoなどです。サンドボックスだけを緩め、承認をon-requestのままにすれば、境界ごとに確認が出続けます。
ネットワークには独立した制限があります。 Full Accessであっても、ファイルシステムとは別にインターネットアクセスが制限されることがあります。@mxclが2026年7月16日に指摘したように、Codexは「ユーザーがfull accessを有効にするまでインターネットを使えず、タスクを終了する」ことがあります。ファイル書き込み権限とネットワーク権限は同じではありません。
アップデートでモードがリセットされます。 2026年7月下旬には、Codexをアップグレードするとアクティブなセッションがデフォルトポリシーへ戻るケースが複数報告されました。@s_rafconは7月22日、スレッドが「Full accessフラグをデフォルトフラグへ切り替え、編集のたびに承認を求め続ける」と報告しています。モードはセッションの開始時に設定し、更新後には必ず確認してください。
CLIでは--full-autoが廃止。代わりの指定方法
以前のcodex --full-autoは、「プロジェクト内で確認なしに作業する」ためのショートカットでした。内容はapproval_policy = "on-request"とsandbox_mode = "workspace-write"の組み合わせです。しかし現在、対話型コマンドでは受け付けられません。v0.145.0で検証した結果は次のとおりです。
$ codex --full-auto
error: unexpected argument '--full-auto' found代わりに、以前のフラグが行っていた2つの設定を明示します。
# --full-autoの現行置き換え
codex --sandbox workspace-write --ask-for-approval on-request
# 非対話実行。確認は出さず、サンドボックスは維持する:
codex -a never -s workspace-write exec "your task"スクリプト用途ではcodex exec --full-autoが依然として利用できます。エラーになるのは対話型コマンドだけです。codex --helpによると、--ask-for-approvalにはuntrusted / on-request / neverを指定でき、--sandboxにはread-only / workspace-write / danger-full-accessを指定できます。アプリ上の各「モード」は、すべてこの2つの組み合わせです。
--yoloを使うべき場面：全制限を外す
--yoloは--dangerously-bypass-approvals-and-sandboxの短縮エイリアスです。これが本当の意味での「完全放置」スイッチで、danger-full-accessとneverを同時に指定します。ファイルシステムの境界も承認ゲートもありません。--full-autoが削除された後も残っているのは、名前自体がリスクを明確に示しているからでしょう。v0.145.0では、codex --full-autoはエラーになる一方、codex --yoloは問題なく解析されます。
経験豊富なユーザーのなかには、これをデフォルトで使う人も少なくありません。環境そのものを安全装置として扱えるタスクでは、合理的な選択です。ただし、マシンは使い捨て前提にしてください。
- 普段使いのマシンではなく、使い捨てのVMやdev containerで実行する。
- 本番用の認証情報は事前に環境から取り除く。
- タスクの範囲を狭く保ち、作業を続ける前に
git diffを確認する。
--yoloはすべてのゲートを外すため、誤ったrm -rf、git push、DROP TABLEも確認なしで実行されます。速度を得る代わりに負うコストです。（カスタムモデルプロバイダー経由でCodexをセルフホスト型またはAnthropic互換のエンドポイントに向けても、ここは変わりません。サンドボックスはAPIの背後にあるモデルを問いません。）
「Approve for me」とAuto-review：AIに承認判断を任せる
最新のモードであり、現在のアプリのデフォルトでもあるのがAuto-reviewです。対象となる昇格リクエストは、別のレビュアーエージェントに渡されます。これはGPT-5.4 Thinking（low）で動く小型のCodexで、理由付きで承認または拒否を判断します。OpenAIはこれを「権限付与ではなくレビュアーの交代」と説明しています。書き込み可能なディレクトリを広げたり、ネットワークを開放したりするものではなく、誰が承認するかを変えるだけです。
OpenAIが2026年4月30日に公開した評価によれば、Auto-reviewで人間の判断が必要になる頻度は手動承認より約200倍少なく、レビューした昇格リクエストのおよそ99.1%を承認します。全アクションを対象にすると99.93%です。10,000アクションの例では、9,280件がサンドボックス内でそのまま実行され、720件がレビュアーに回り、拒否されたのは7件だけでした。
拒否が連続して暴走しないためのガードレールもあります。3回連続で拒否された場合、または直近50件のレビューというローリングウィンドウ内で10回拒否された場合、そのターンは中断されます。停止したときは/approveを実行するとAuto-review Denialsピッカーが開き、1つのアクションを許可して再試行できます。
ただし、こうした安全チェックは長時間実行を止めることがあります。2026年7月下旬には、数時間に及ぶ/goalタスクの利用者から、定期的に出る「待機を続けますか？」というプロンプトにより、以前は何日も無人で動いていたワークフローが途切れたという報告がありました。OpenAIも、これは「セキュリティの保証として扱うべきではない」と明言しています。レッドチーム評価の再現率は高いものの完全ではなく、90.3% overreach、99.3% prompt injection、96.1% misaligned-modelです。通常作業には有力なデフォルトですが、重要度の高い作業でサンドボックスを置き換えるものではありません。
UIではなく設定ファイルから有効化する場合は、次のようにします。
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""結局、どのモードを選ぶべきか
- 日常的なローカル開発:
workspace-write+on-request（「Ask for approval」）。リポジトリ外へ出る操作には拒否権を残せます。実害が起きやすいのはこの境界です。 - 長時間の無人実行: 「Approve for me」（Auto-review）。ただし、フラグされた操作では停止するため、完全なノータッチ運用ではありません。
- 使い捨て環境での単発作業:
--yolo。最速で、最も危険です。環境にダメージを与えられない場合に限って使います。 - コードベースの閲覧・レビュー:
read-only。書き込みがなく、予期しない変更もありません。
率直に言えば、完全自律と完全安全を両立する設定はありません。放置度を上げるたび、自分の判断を分類器の判断に委ねることになります。定型作業では価値のある交換ですが、本番インフラでは悪手になり得ます。一度決めて固定するのではなく、タスクごとに選んでください。
FAQ
CodexにAuto modeはありますか？
あります。ただし、単一のトグルではなくプリセット群です。アプリでは「Ask for approval」「Approve for me」「Full access」が該当します。CLIでは--sandboxと--ask-for-approvalを組み合わせるか、/permissionsを使って同じ挙動を設定します。
Codexですべてのコマンドを自動承認するには？
approval_policy = "never"を設定します。workspace-writeと組み合わせれば、サンドボックス内での確認は出なくなります。danger-full-access、つまり--yoloと組み合わせれば、確認は完全になくなります。後者はすべての安全装置を外すため、隔離環境でのみ実行してください。
CodexのAuto-reviewモードとは何ですか？
Auto-review（approvals_reviewer = "auto_review"、画面上では「Approve for me」）は、承認判断をあなたではなくAIレビュアーエージェントへ送る機能です。レビュー対象のおよそ99%を承認し、人間による停止は約200分の1になりますが、セキュリティを保証するものではありません。
--full-autoはまだ使えますか？
対話型CLIでは使えません。v0.145.0で検証したところ、codex --full-autoは「unexpected argument」を返します。codex exec --full-autoは、スクリプト向けの非推奨エイリアスとして現在も受け付けられます。対話型では、代わりに--sandbox workspace-write --ask-for-approval on-requestを指定してください。
--yoloモードは安全ですか？
いいえ。それこそがこの名前の意図です。サンドボックスとすべての承認を同時に無効化します。本番認証情報を取り除き、タスクの範囲を絞った使い捨てVMまたはコンテナ内でのみ、合理的な選択肢になります。