自動レビュー¶
自動レビューは、サンドボックス境界での手動承認を、専用のレビュアーエージェントによるレビューに置き換えます。メインの Codex エージェントは、同じサンドボックス内で、同じ承認ポリシーと同じネットワークおよびファイルシステムの制限のもとで引き続き実行されます。異なるのは、承認のエスカレーションが必要なリクエストを誰がレビューするかです。
自動レビューは、承認がインタラクティブな場合にのみ適用されます。実際には、approval_policy = "on-request" または、該当するプロンプトカテゴリを引き続き表示するきめ細かな承認ポリシーが該当します。approval_policy = "never" では、レビュー対象がありません。
自動レビューの仕組み¶
大まかな流れは次のとおりです。
- メインエージェントが
read-onlyまたはworkspace-write内で作業します。 - サンドボックス境界を越える必要がある場合、承認をリクエストします。
approvals_reviewer = "auto_review"の場合、Codex はその承認リクエストを、人による確認のために停止する代わりに、専用のレビュアーエージェントへルーティングします。- レビュアーがアクションを実行すべきかどうかを判断し、理由を返します。
- アクションが承認されると実行が続行されます。拒否された場合、メインエージェントには、実質的により安全な方法を探すか、停止してユーザーに尋ねるよう指示されます。
自動レビューは権限の付与ではなく、レビュアーの置き換えです。writable_roots を拡張したり、ネットワークアクセスを有効にしたり、保護対象パスを無防備にしたりすることはありません。すでに承認が必要なアクションを Codex が処理する方法だけを変更します。
トリガーされるタイミング¶
自動レビューは、人による確認のために一時停止される承認リクエストを評価します。これには次が含まれます。
- サンドボックス権限のエスカレーションを要求する Shell または exec ツールの呼び出し。
- 現在のサンドボックスまたはポリシーによってブロックされているネットワークリクエスト。
- 許可された書き込み可能なルートの外部に対するファイル編集。
- ツールのアノテーションまたは設定された承認モードに基づいて承認が必要な MCP またはアプリツールの呼び出し。
- 新しい Web サイトまたはドメインへの Computer Use アクセス。
サンドボックス内ですでに許可されている通常のアクションに対して、自動レビューは実行されません。コマンドがアクティブな sandbox_mode のもとで実行できる場合や、ツールの呼び出しが許可されたポリシーの範囲内にとどまる場合、メインエージェントはレビューなしで続行します。
Computer Use は別のケースです。Computer Use のアプリ承認は引き続きユーザーに直接表示されるため、自動レビューがそれらのアプリレベルのプロンプトに置き換わることはありません。
自動レビューがブロックする対象¶
大まかに、自動レビューは次のようなアクションをブロックするよう設計されています。
- プライベートデータ、シークレット、または認証情報を信頼できない送信先に送信すること
- 認証情報、トークン、Cookie、またはセッション情報を探索すること
- セキュリティを広範囲または永続的に弱めること
- 取り返しのつかない重大な損害をもたらすリスクのある破壊的なアクション
正確なポリシーは、オープンソースの Codex リポジトリにあります。
policy_template.md
および
policy.md。
このポリシーは、エンタープライズごとに guardian_policy_config を使用して、またはユーザーごとにローカルの [auto_review].policy を使用してカスタマイズできます。
レビュアーに表示される内容¶
レビュアー自身も Codex エージェントですが、メインエージェントより狭い役割を担います。具体的な境界越えアクションを実行すべきかどうかを判断します。
レビュアーには、簡潔なトランスクリプトと正確な承認リクエストが表示されます。通常、これにはユーザーメッセージ、表示されたアシスタントの更新、関連するツールの呼び出しとツールの出力、そして承認を求めて現在提案されているアクションが含まれます。不足しているコンテキストを収集するために読み取り専用のチェックを実行することもありますが、これは頻繁には行われません。
非表示のアシスタント推論は含まれません。自動レビューが参照するのは、保持されたチャット項目とツールの証拠であり、非公開の chain-of-thought ではありません。
拒否と障害時の動作¶
明示的な拒否は、通常のサンドボックスエラーとして扱われません。Codex はレビューの理由をメインエージェントに返し、さらに強い指示を追加します。
- 回避策、間接的な実行、またはポリシーの迂回によって、同じ結果を追求しないでください。
- 実質的により安全な代替手段がある場合にのみ続行してください。
- それ以外の場合は停止して、ユーザーに尋ねてください。
Codex は、ターンごとに拒否のサーキットブレーカーも適用します。現在のオープンソース実装では、同じターン内で連続して 3 回拒否された場合、または直近の 50 件のレビュー中に 10 回拒否された場合、自動レビューはターンを中断します。
拒否以外の結果が返ると、連続拒否カウンターはリセットされます。ブレーカーが作動すると、Codex は警告を出力し、エージェントがさらなるエスカレーションの試行を繰り返すのではなく、割り込みによって現在のターンを中止します。
タイムアウトは明示的な拒否とは別に表示され、メインエージェントには、タイムアウトだけではアクションが安全でないことの証明にはならないと伝えられます。
拒否されたアクションには、明示的な上書き経路もあります。現在のオープンソース TUI では、/approve を実行して 自動レビューの拒否 ピッカーを開き、最近拒否されたアクションを 1 つ選択して 1 回の再試行を承認します。Codex はタスクごとに、最近の拒否を最大 10 件記録します。この承認の範囲は限定されています。対象は拒否された正確なアクションであり、今後の類似アクションではありません。また、同じコンテキストでの 1 回の再試行に対して記録され、再試行も自動レビューを通過します。内部では、Codex がそのアクションに対する開発者スコープの承認マーカーを注入します。その後、レビュアーはこの明示的なユーザーによる上書きをコンテキストとして確認しますが、引き続きポリシーに従うため、ユーザーがその種類の拒否を上書きできないとポリシーが定めている場合は再度拒否できます。
設定¶
セットアップの詳細については、 管理対象の設定 を参照してください。
デフォルトのレビュアーポリシーは、オープンソースの Codex リポジトリにあります。
core/src/guardian/policy.md。
エンタープライズでは、管理要件の guardian_policy_config を使用して、テナント固有のセクションを置き換えることができます。個々のユーザーも、config.toml にローカルの
[auto_review].policy
を設定できますが、管理要件が優先されます。
ポリシーをカスタマイズするには、まずデフォルトポリシーの全文をコピーし、その後、個々のリスクプロファイルに基づいて調整してください。
セキュリティを弱めずにレビュー量を減らす¶
自動レビューは、サンドボックスが一般的な安全なワークフローをすでにカバーしている場合に最も効果を発揮します。ありふれたアクションがレビューを必要としすぎる場合は、レビュアーにノイズの多いエスカレーションを恒久的に承認させるのではなく、まず境界を修正してください。
実際には、最も効果の大きい変更は次のとおりです。
- 意図的に使用するスクラッチディレクトリや隣接リポジトリに対して、範囲を限定した
writable_rootsを追加します。 - 範囲を限定した プレフィックスルール を追加します。
["cargo", "test"]や["pnpm", "run", "lint"]のような正確なコマンドプレフィックスを、["python"]や["curl"]のような広範なパターンよりも優先してください。広範なルールは、自動レビューが保護するよう設計された肝心の境界を消してしまうことがよくあります。
自動レビューのセッションのトランスクリプトは、デフォルトで ~/.codex/sessions に保持されます。そのため、ポリシーや権限を変更する前に、Codex にそこで過去のトラフィックを分析させることができます。
制限¶
自動レビューは、長時間実行されるエージェント型の作業におけるデフォルトの運用ポイントを改善しますが、決定論的なセキュリティ保証ではありません。
- 境界越えを求めるアクションのみを評価します。
- 特に敵対的なコンテキストや通常とは異なるコンテキストでは、誤る可能性があります。
- 適切なサンドボックス設計、監視、組織固有のポリシーを補完するものであり、それらに置き換わるものではありません。
研究上の根拠と公開された評価結果については、 自動レビューに関する Alignment Research の投稿 を参照してください。