Agent approvals & security

概要

Codex をローカルで安全に動かすための sandbox・承認ポリシー・ネットワークアクセスの仕様。既定でエージェントはネットワークアクセスを切った状態で動き、OS 強制の sandbox（通常は現在のワークスペースに限定）と承認ポリシーの 2 層で制御される。

仕様

2 つの層

• Sandbox mode: モデルが生成したコマンドを実行するとき、技術的に何ができるか（どこに書けるか、ネットワークに到達できるか）
• Approval policy: 実行前にユーザーへ確認が必要な場面（sandbox から出る、ネットワークを使う、trusted な集合の外のコマンドを実行する、など）

実行環境ごとの sandbox

既定と推奨

• 起動時にフォルダがバージョン管理下かを検出して推奨する
  • バージョン管理下: Auto（workspace write + on-request approvals）
  • バージョン管理外: read-only
• 環境によっては、作業ディレクトリを明示的に信頼する（オンボーディングのプロンプトや /permissions）まで read-only で開始することがある
• ワークスペースには現在のディレクトリと /tmp などの一時ディレクトリが含まれる。/status でワークスペースに入っているディレクトリを確認する
• 明示指定の例: codex --sandbox workspace-write --ask-for-approval on-request、codex --sandbox read-only --ask-for-approval on-request
• Auto プリセットでは、作業ディレクトリ内でのファイル読み取り・編集・コマンド実行を自動で行う。ワークスペース外の編集やネットワークアクセスには承認を求める
• 変更を伴わずに相談・計画したい場合は /permissions で read-only に切り替える
• app（connector）のツール呼び出しでも、副作用を宣言しているものは承認を求めることがある。destructive アノテーションを宣言する app / MCP ツール呼び出しは、read-only ヒントなど他のヒントを併せて宣言していても常に承認が必要

writable root 内の保護パス

既定の workspace-write sandbox policy では、書き込み可能な root の中にも読み取り専用の保護パスがある。

• <writable_root>/.git は、ディレクトリでもファイルでも read-only として保護される
• <writable_root>/.git がポインタファイル（gitdir: ...）の場合、解決先の Git ディレクトリパスも read-only として保護される
• <writable_root>/.agents はディレクトリとして存在するとき read-only
• <writable_root>/.codex はディレクトリとして存在するとき read-only
• 保護は再帰的で、これらの配下はすべて read-only

承認プロンプトの制御

• --ask-for-approval never（短縮 -a never）で承認プロンプトを無効にできる。すべての --sandbox モードと併用できる
• 承認プロンプト無しで読み書きとネットワーク付きコマンド実行まで行うには --sandbox danger-full-access（または --dangerously-bypass-approvals-and-sandbox）
• 中間として approval_policy = { granular = { ... } } があり、特定カテゴリの承認プロンプトだけを対話的に残し、他は自動拒否する。granular policy が扱うのは sandbox approvals、execpolicy-rule のプロンプト、MCP のプロンプト、request_permissions のプロンプト、skill-script の承認
• --ask-for-approval untrusted では、既知の安全な読み取り操作だけを自動実行する。状態を変えうるコマンドや外部実行経路を起こしうるコマンド（破壊的な Git 操作、Git の出力・config 上書きフラグなど）は承認が必要

sandbox と承認の組み合わせ

• 非対話実行には codex exec --sandbox workspace-write を使う。codex exec --full-auto は deprecated な互換経路として残っており、警告を表示する

自動承認レビュー（Auto-review）

• 既定は approvals_reviewer = "user"
• 自動承認レビューは、承認が対話的な場合（approval_policy = "on-request" や granular approval policy）に適用される。approvals_reviewer = "auto_review" にすると、対象の承認要求を reviewer agent 経由にする
• reviewer が評価するのは 既に承認が必要なアクションのみ（sandbox escalation、ブロックされたネットワークリクエスト、request_permissions のプロンプト、副作用のある app / MCP ツール呼び出し）。sandbox 内に留まるアクションは追加のレビュー無しで進む
• reviewer policy は data exfiltration、credential probing、恒久的なセキュリティ低下、破壊的アクションを検査する
  • low / medium リスクはポリシーが許せば進める
  • critical リスクは拒否する
  • high リスクは十分なユーザー認可があり、かつ一致する deny ルールが無いことが条件
  • prompt-build / review-session / parse の失敗は fail closed。タイムアウトは別途表示されるが、いずれにせよアクションは実行されない
• 既定の reviewer policy は open-source の Codex リポジトリにある。エンタープライズは managed requirements の guardian_policy_config でテナント固有部分を置き換えられる。ローカルの [auto_review].policy テキストも使えるが、managed requirements が優先する
• ChatGPT desktop app では Reviewing / Approved / Denied / Aborted / Timed out といった状態の自動レビュー項目として表示され、リスクレベルとユーザー認可の評価も含まれうる
• 自動レビューは追加のモデル呼び出しを使うため使用量が増える。管理者は allowed_approvals_reviewers で制約できる

ネットワークアクセス

• ChatGPT desktop app / Codex CLI / IDE extension の既定 workspace-write sandbox mode では、設定で有効にしない限りネットワークアクセスは切られている

[sandbox_workspace_write]
network_access = true

• Codex cloud のインターネットアクセス（フルアクセスまたはドメイン allow list）は別ページの扱い

network_proxy

• ネットワークアクセスは、コマンドが起動するスクリプト・プログラム・サブプロセスに適用される destination rule で制御する
• コマンドのネットワークアクセスが既に有効なとき、network_proxy フィーチャーを有効にするとその通信を設定したネットワークポリシーに制約できる
• この機能はネットワークアクセスの強制方法を変えるだけで、それ自体がネットワークアクセスを与えるわけではない

• 管理者が管理する experimental_network requirements はユーザー側のフィーチャートグルとは別物。features.network_proxy 無しで sandboxed networking を設定・起動できるが、有効な sandbox がネットワークを off にしているときにネットワークアクセスを有効化することはない

ドメインルール

allowlist を先とする。

• 完全なホスト名はそれ自身にのみ一致する
• *.example.com は api.example.com などのサブドメインに一致するが、example.com には一致しない
• **.example.com は apex とサブドメインの両方に一致する
• グローバルな * の allow ルールは、deny されていない任意のパブリックホストに一致する。広いアクセスとして扱い、可能ならスコープを絞ったルールを使う
• deny は常に allow に優先する。グローバルな * は allow ルールでのみ有効

ローカル・プライベート宛先

• 既定の allow_local_binding = false は loopback、link-local、プライベート宛先をブロックする
• 個別の例外は、正確なローカル IP リテラルまたは localhost の allow ルールを足す
• 広くアクセスさせたい場合のみ allow_local_binding = true
• ワイルドカードルールは明示的なローカル例外とは見なされない
• allowlist に一致しても、ローカル／プライベート IP に解決されるホスト名はブロックされたまま

DNS rebinding 対策

ホスト名を許可する前に best-effort の DNS / IP 分類チェックを行う。

• 失敗またはタイムアウトした lookup はブロックされる
• 非パブリックアドレスに解決されるホスト名はブロックされる
• このチェックは DNS rebinding のリスクを減らすが、無くすものではない。完全な防止には transport 層で解決済み IP を固定する必要がある

network_proxy の設定値

network_proxy は既定で off。有効にしたときの各設定:

• dangerously_allow_non_loopback_proxy = true と dangerously_allow_all_unix_sockets = true は信頼境界を意図的に広げる。厳密に管理された環境でのみ使う
• Unix socket proxying が有効なとき、non-loopback binding が要求されても listener は loopback のみに留まり、sandboxed networking がローカルデーモンへのリモートブリッジにならないようになっている

web search

• Codex は既定で web search cache を使う。OpenAI が保守するインデックスから事前取得済みの結果を返す
• キャッシュ利用は任意のライブコンテンツからの prompt injection への露出を減らすが、web の結果は引き続き untrusted として扱うべき
• --yolo などの full access sandbox 設定を使っている場合、web search は既定でライブ結果になる
• --search または web_search = "live" でライブ閲覧を許可、"disabled" でツールを切る。"indexed" は外部 web アクセスを検索インデックス経由に限定する

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

OS レベルの sandbox

• Windows で IDE extension を使う場合、VS Code 設定 "chatgpt.runCodexInWindowsSubsystemForLinux": true で WSL2 が使えるときは常にエージェントを WSL2 内に留められる
• Windows ネイティブのサンドボックスモードは config.toml の [windows] で設定する（sandbox = "unelevated" または "elevated"、sandbox_private_desktop は既定 true）
• Docker などのコンテナ環境で Linux を動かす場合、ホストやコンテナの設定が namespace / setuid bwrap / seccomp を塞いでいると sandbox が機能しないことがある。その場合はコンテナ側で隔離を用意し、コンテナ内で --sandbox danger-full-access を使う

sandbox のローカル検証

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

• sandbox コマンドは codex debug としても使える。プラットフォームヘルパーにはエイリアスがある（codex sandbox seatbelt、codex sandbox landlock など）

Dev Containers

• ホストで Linux sandbox を直接動かせない場合や、組織がコンテナ開発を標準化している場合に、Docker を外側の隔離境界として使う構成が案内されている
• 参照実装は Ubuntu 24.04 ベースイメージ、allowlist 駆動の outbound firewall プロファイル、VS Code の設定と拡張推奨、コマンド履歴と Codex 設定の永続マウント、bubblewrap を含む
• devcontainer は大きな保護になるが、あらゆる攻撃を防ぐわけではない。コンテナ内で --sandbox danger-full-access や --dangerously-bypass-approvals-and-sandbox を使うと、悪意あるプロジェクトが Codex の認証情報を含むコンテナ内のあらゆるものを持ち出しうる
• 参照 firewall は出発点に過ぎない。ドメイン allowlist に依存するなら、TTL 対応のリフレッシュや DNS-aware firewall など、環境に合った DNS rebinding / DNS refresh 対策を自前で実装する

OpenTelemetry によるモニタリング

• opt-in。既定で OTel export は off
• 有効にすると、chat、API リクエスト、SSE / WebSocket のストリーム活動、ユーザープロンプト（既定では redact される）、ツールの承認判断、ツール結果をカバーする構造化ログイベントを出す
• エクスポートされるイベントには service.name（originator）、CLI バージョン、環境ラベルが付く
• exporter = "none" は計装を有効にしたままどこにも送らない。otlp-http / otlp-grpc で自前のコレクタへ送る
• イベントをバッチ化し、シャットダウン時にフラッシュする。OTel モジュールが生成したテレメトリのみを出す
• 代表的なイベント: codex.conversation_starts、codex.api_request、codex.sse_event、codex.websocket_request / codex.websocket_event、codex.user_prompt（長さのみ。明示的に有効化しない限り内容は redact）、codex.tool_decision、codex.tool_result
• 対応するメトリクス（カウンタ + duration ヒストグラム）: codex.api_request、codex.sse_event、codex.websocket.request、codex.websocket.event、codex.tool.call（それぞれ .duration_ms 付き）
• CLI をネットワークアクセス無しで実行すると OTel export はコレクタに到達できない

設定

# 常に承認を求めるモード
approval_policy = "untrusted"
sandbox_mode    = "read-only"
allow_login_shell = false # 任意の hardening: shell 系ツールで login shell を禁じる

# 任意: workspace-write でネットワークを許可
[sandbox_workspace_write]
network_access = true

# 任意: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false

# ~/.codex/full_auto.config.toml（profile として保存し codex --profile で選ぶ）
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

制約・注意点

• ネットワークアクセスや web search を有効にするときは注意する。prompt injection によってエージェントが untrusted な指示を取得して従いうる
• 敵対的な DNS を脅威モデルに含めるなら、より下位のレイヤーでも egress 制御を強制する
• ドキュメントが挙げるテレメトリ運用上の注意: ポリシーが明示的に許さない限り log_user_prompt = false のままにする、自分で管理するコレクタにだけ送る、ツールの引数と出力を機微情報として扱う、セッションのトランスクリプトを CODEX_HOME に保存したくない場合は history.persistence / history.max_bytes を見直す
• OTel は sandbox と承認による保護を置き換えるものではなく補完するもの

関連

• facts/codex/sandbox.md
• facts/codex/permissions.md
• facts/codex/configuration-reference.md
• facts/codex/config-basics.md
• facts/codex/cli-reference.md
• facts/codex/non-interactive-mode.md