エージェントの承認とセキュリティ

Codex はコードとデータを保護し、不正使用のリスクを軽減するのに役立ちます。

デフォルトでは、エージェントはネットワークアクセスが無効な状態で実行されます。ローカル環境では、Codex は OS によって強制されるサンドボックスを使用して、アクセスできる範囲を制限します（通常は現在のワークスペースに限定されます）。さらに、操作前に停止して承認を求める必要があるタイミングを、承認ポリシーによって制御します。

ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能全体でサンドボックス化がどのように機能するかについての概要は、サンドボックス化を参照してください。エンタープライズセキュリティのより広範な概要については、Codex セキュリティホワイトペーパーを参照してください。

サンドボックスと承認

Codex のセキュリティ制御は、連携して機能する次の 2 つのレイヤーで構成されます。

• サンドボックスモード：モデルが生成したコマンドを実行するときに、Codex が技術的に実行できる操作（たとえば、書き込み可能な場所やネットワークに接続できるかどうか）を制御します。
• 承認ポリシー：Codex が操作を実行する前に承認を求める必要があるタイミング（たとえば、サンドボックスの外に出る、ネットワークを使用する、信頼済みセットに含まれないコマンドを実行する場合）を制御します。

Codex は、実行する場所に応じて異なるサンドボックスモードを使用します。

• Codex cloud：OpenAI が管理する分離されたコンテナ内で実行されるため、ホストシステムや無関係なデータにはアクセスできません。2 段階のランタイムモデルを使用します。セットアップはエージェントフェーズの前に実行され、指定された依存関係をインストールするためにネットワークへアクセスできます。その後、エージェントフェーズは、その環境でインターネットアクセスを有効にしない限り、デフォルトでオフライン実行されます。クラウド環境に設定されたシークレットはセットアップ中のみ利用でき、エージェントフェーズが開始される前に削除されます。
• Codex CLI / IDE 拡張機能：OS レベルの仕組みによってサンドボックスポリシーが適用されます。デフォルトではネットワークアクセスが無効で、書き込み権限はアクティブなワークスペースに限定されます。リスク許容度に応じて、サンドボックス、承認ポリシー、ネットワーク設定を構成できます。

Auto プリセット（たとえば、--sandbox workspace-write --ask-for-approval on-request）では、Codex は作業ディレクトリ内のファイルの読み取り、編集、コマンドの実行を自動的に行えます。

Codex は、ワークスペース外のファイルを編集する場合や、ネットワークアクセスが必要なコマンドを実行する場合に承認を求めます。変更を加えずにチャットや計画だけを行いたい場合は、/permissions コマンドで read-only モードに切り替えてください。

Codex は、シェルコマンドやファイル変更ではない操作でも、副作用があると示されている app（connector）ツール呼び出しについて承認を求めることがあります。破壊的な注釈が示されている app/MCP ツール呼び出しは、ほかのヒント（たとえば、読み取り専用のヒント）も示されている場合でも、必ず承認が必要です。

ネットワークアクセス

Codex cloud で完全なインターネットアクセスまたはドメインの許可リストを有効にする方法については、エージェントのインターネットアクセスを参照してください。

ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能では、設定で有効にしない限り、デフォルトの workspace-write サンドボックスモードでネットワークアクセスは無効になります。

[sandbox_workspace_write]
network_access = true

ネットワーク分離

ネットワークアクセスは、コマンドによって起動されたスクリプト、プログラム、サブプロセスに適用される接続先ルールによって制御されます。コマンドのネットワークアクセスがすでに有効になっている場合は、network_proxy 機能を有効にして、そのトラフィックを設定したネットワークポリシーの範囲内に制限します。

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

1 回限りの CLI セッションでは、切り替えだけが必要な場合はブール値の省略形を使用し、ポリシーオプションも設定する場合はテーブル形式を使用します。

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

この機能は、有効なネットワークアクセスを適用する方法を変更するものであり、それ自体でネットワークアクセスを許可するものではありません。workspace-write 設定では、コマンドにネットワークアクセスを許可するかどうかを sandbox_workspace_write.network_access で決定します。

• ネットワーク無効 + network_proxy 有効：ネットワークは無効のままで、この機能は何も行いません。
• ネットワーク有効 + network_proxy 無効：ネットワークは有効なままで、制限のない直接のアウトバウンドアクセスが許可されます。
• ネットワーク有効 + network_proxy 有効：ネットワークは有効なままで、アウトバウンドトラフィックは設定されたネットワークポリシーによって制限されます。

管理者が管理する experimental_network 要件は、ユーザーの機能切り替えとは別のものです。この要件では、features.network_proxy を使用せずにサンドボックス化されたネットワークを構成して開始できますが、アクティブなサンドボックスでネットワークが無効になっている場合、ネットワークアクセスは有効になりません。管理者側の requirements.toml の形式については、管理対象の設定を参照してください。

ネットワークポリシー

ドメインルールでは、許可リストが優先されます。

• 完全一致のホストは、そのホスト自体にのみ一致します。
• *.example.com は api.example.com などのサブドメインに一致しますが、 example.com には一致しません。
• **.example.com は、ルートドメインとサブドメインの両方に一致します。
• グローバルな * 許可ルールは、拒否されていないすべてのパブリックホストに一致します。* は広範なネットワークアクセスとして扱い、可能な場合は範囲を限定したルールを使用してください。
• deny は常に allow より優先され、グローバルな * は許可ルールでのみ有効です。

ローカルおよびプライベートな接続先

デフォルトでは、allow_local_binding = false により、ループバック、リンクローカル、プライベートな接続先がブロックされます。

• 特定の例外：コマンドが単一のローカルターゲットを必要とする場合は、ローカル IP の正確なリテラルまたは localhost の許可ルールを追加します。
• より広範なアクセス：ローカル／プライベートネットワークへのアクセス範囲を意図的に広げる場合にのみ、 allow_local_binding = true を設定します。
• ワイルドカード：ワイルドカードルールは、明示的なローカル例外とは見なされません。
• 解決済みアドレス：許可リストに一致していても、ローカル／プライベート IP に解決されるホスト名は引き続きブロックされます。

DNS リバインディング対策

ホスト名を許可する前に、Codex はベストエフォートで DNS と IP の分類チェックを実行します。

• 参照に失敗した場合やタイムアウトした場合はブロックされます。
• 非公開アドレスに解決されるホスト名はブロックされます。
• このチェックにより DNS リバインディングのリスクは軽減されますが、完全に排除できるわけではありません。リバインディングを完全に防ぐには、解決済み IP をトランスポートレイヤー全体で固定する必要があります。

悪意のある DNS が脅威の対象に含まれる場合は、より下位のレイヤーでも送信制御を適用してください。

危険な設定

次の 2 つの設定は、信頼境界を意図的に広げます。

• dangerously_allow_non_loopback_proxy = true は、プロキシリスナーをループバックの外部に公開する可能性があります。
• dangerously_allow_all_unix_sockets = true は、Unix ソケットの許可リストを迂回します。

厳格に管理された環境でのみ使用してください。Unix ソケットのプロキシが有効な場合、非ループバックへのバインドが要求されていてもリスナーはループバックのみに維持されるため、サンドボックス化されたネットワークがローカルデーモンへのリモートブリッジになることはありません。

network_proxy はデフォルトで無効です。有効にした場合：

生成されたコマンドに完全なネットワークアクセスを許可せずに、Web 検索ツールを制御することもできます。Codex はデフォルトで、Web 検索キャッシュを使用して結果にアクセスします。このキャッシュは OpenAI が管理する Web 検索結果のインデックスであるため、キャッシュモードではライブページを取得する代わりに、事前にインデックス化された結果が返されます。これにより、任意のライブコンテンツからプロンプトインジェクションを受けるリスクは軽減されますが、Web 検索結果は引き続き信頼できないものとして扱ってください。--yolo または別のフルアクセスのサンドボックス設定を使用している場合、Web 検索はデフォルトでライブ結果を使用します。ライブブラウジングを許可するには --search を使用するか web_search = "live" を設定し、ツールを無効にするには "disabled" に設定します。

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

外部 Web アクセスを検索インデックスによって制限する必要がある場合は、web_search = "indexed" を設定します。 Codex でネットワークアクセスや Web 検索を有効にする場合は注意してください。プロンプトインジェクションにより、エージェントが信頼できない指示を取得して従ってしまう可能性があります。

デフォルトと推奨事項

• 起動時に Codex はフォルダーがバージョン管理されているかどうかを検出し、次の設定を推奨します。
  • バージョン管理されているフォルダー：Auto（ワークスペースへの書き込み + リクエスト時の承認）
  • バージョン管理されていないフォルダー：read-only
• セットアップによっては、作業ディレクトリを明示的に信頼するまで（たとえば、オンボーディングのプロンプトや /permissions を介して）、Codex が read-only で起動する場合もあります。
• ワークスペースには、現在のディレクトリと /tmp などの一時ディレクトリが含まれます。ワークスペースに含まれるディレクトリを確認するには、/status コマンドを使用してください。
• デフォルトを受け入れるには、codex を実行します。
• 次のように明示的に設定することもできます。
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

書き込み可能なルート内の保護されたパス

デフォルトの workspace-write サンドボックスポリシーでは、書き込み可能なルート内であっても、次のパスは保護されます。

• <writable_root>/.git は、ディレクトリとファイルのどちらとして存在する場合でも、読み取り専用として保護されます。
• <writable_root>/.git がポインターファイル（gitdir: ...）の場合、解決された Git ディレクトリのパスも読み取り専用として保護されます。
• <writable_root>/.agents がディレクトリとして存在する場合、読み取り専用として保護されます。
• <writable_root>/.codex がディレクトリとして存在する場合、読み取り専用として保護されます。
• 保護は再帰的に適用されるため、これらのパス配下にあるすべてのものが読み取り専用になります。

承認プロンプトなしで実行する

--ask-for-approval never または省略形の -a never を使用すると、承認プロンプトを無効にできます。

このオプションはすべての --sandbox モードで機能するため、Codex の自律性のレベルは引き続き制御できます。Codex は、設定された制約の範囲内で最善を尽くします。

承認プロンプトなしで Codex にファイルの読み取り、編集、ネットワークアクセスを伴うコマンドの実行を許可する必要がある場合は、--sandbox danger-full-access（または --dangerously-bypass-approvals-and-sandbox フラグ）を使用してください。実行する際は十分注意してください。

中間的な選択肢として、approval_policy = { granular = { ... } } を使用すると、特定の承認プロンプトのカテゴリを対話形式のままにし、それ以外を自動的に拒否できます。きめ細かなポリシーの対象には、サンドボックス承認、execpolicy ルールのプロンプト、MCP プロンプト、request_permissions プロンプト、スキルスクリプトの承認が含まれます。

承認の自動レビュー

デフォルトでは、承認リクエストはユーザーに送られます。

approvals_reviewer = "user"

承認の自動レビューは、approval_policy = "on-request" やきめ細かな承認ポリシーなど、承認が対話形式の場合に適用されます。Codex がリクエストを実行する前に、対象となる承認リクエストをレビュー担当のエージェントに送るには、approvals_reviewer = "auto_review" を設定します。

approval_policy = "on-request"
approvals_reviewer = "auto_review"

レビュー担当のライフサイクル全体、トリガー条件、設定の優先順位、および障害時の動作については、 自動レビューを参照してください。

レビュー担当は、サンドボックスの権限昇格、ブロックされたネットワークリクエスト、request_permissions プロンプト、副作用を伴うアプリや MCP ツールの呼び出しなど、すでに承認が必要なアクションのみを評価します。サンドボックス内に収まるアクションは、追加のレビューステップなしで続行されます。

レビューポリシーでは、データの持ち出し、認証情報の探索、永続的なセキュリティの弱体化、破壊的なアクションがチェックされます。ポリシーで許可されている場合、低リスクおよび中リスクのアクションは実行できます。重大リスクのアクションはポリシーによって拒否されます。高リスクのアクションには、十分なユーザー承認があり、一致する拒否ルールがないことが必要です。プロンプト構築、レビューセッション、解析に失敗した場合は、安全側に倒して拒否されます。タイムアウトは個別に表示されますが、その場合もアクションは実行されません。

デフォルトのレビューポリシー は、オープンソースの Codex リポジトリにあります。企業は、管理対象要件の guardian_policy_config を使用して、テナント固有のセクションを置き換えることができます。ローカルの [auto_review].policy テキストもサポートされていますが、管理対象要件が優先されます。設定の詳細については、 管理対象の設定を参照してください。

ChatGPT デスクトップアプリでは、これらのレビューは「レビュー中」「承認済み」「拒否」「中止」「タイムアウト」などのステータスを持つ自動レビュー項目として表示されます。レビュー対象のリクエストについて、リスクレベルやユーザー承認の評価が表示される場合もあります。

自動レビューでは追加のモデル呼び出しが使用されるため、Codex の使用量が増える可能性があります。管理者は allowed_approvals_reviewers を使用して制限できます。

サンドボックスと承認の一般的な組み合わせ

非対話型の実行では codex exec --sandbox workspace-write を使用してください。Codex は、以前の codex exec --full-auto の呼び出しを非推奨の互換経路として維持し、警告を表示します。

--ask-for-approval untrusted を指定すると、Codex は安全であることが確認されている読み取り操作のみを自動的に実行します。状態を変更したり、外部の実行経路を起動したりする可能性があるコマンド（たとえば、破壊的な Git 操作や Git の出力／設定上書きフラグ）には承認が必要です。

config.toml での設定

より広範な設定ワークフローについては、設定の基本、高度な設定、設定リファレンスを参照してください。

# Always ask for approval mode
approval_policy = "untrusted"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

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

プリセットをプロファイル ファイルとして保存し、codex --profile profile-name で選択することもできます。

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

サンドボックスをローカルでテストする

Codex サンドボックス内でコマンドを実行したときの動作を確認するには、次の Codex CLI コマンドを使用します。

# 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）。

OS レベルのサンドボックス

Codex は、使用している OS に応じて異なる方法でサンドボックスを適用します。

• macOS では Seatbelt ポリシーを使用し、選択した --sandbox モードに対応するプロファイル（-p）を指定して sandbox-exec でコマンドを実行します。制限付き読み取りアクセスでプラットフォームのデフォルトが有効になる場合、Codex は一般的なツールとの互換性を維持するため、/System を広範に許可する代わりに、厳選された macOS プラットフォーム ポリシーを追加します。
• Linux では、デフォルトで bwrap と seccomp を使用します。
• Windows では、Windows Subsystem for Linux 2（WSL2） 上で実行する場合、Linux のサンドボックス実装を使用します。WSL1 は Codex 0.114 までサポートされていましたが、0.115 以降では Linux サンドボックスが bwrap に移行したため、WSL1 はサポートされなくなりました。Windows 上でネイティブ実行する場合、Codex は Windows サンドボックス実装を使用します。

Windows で Codex IDE 拡張機能を使用する場合、WSL2 が直接サポートされます。WSL2 が利用可能なときにエージェントを常に WSL2 内で動作させるには、VS Code の設定で次の項目を指定します。

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

これにより、ホスト OS が Windows であっても、コマンド、承認、ファイルシステムへのアクセスについて、IDE 拡張機能が Linux のサンドボックスのセマンティクスを継承します。詳しくは、WSL ガイドをご覧ください。

Windows 上でネイティブに実行する場合は、config.toml でネイティブのサンドボックスモードを設定します。

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

詳しくは、Windows セットアップガイドをご覧ください。

Docker などのコンテナ環境で Linux を実行する場合、ホストまたはコンテナの設定によって、Codex が必要とする名前空間、setuid bwrap、または seccomp の操作がブロックされると、サンドボックスが機能しないことがあります。

その場合は、必要な分離を提供するように Docker コンテナを設定してから、コンテナ内で --sandbox danger-full-access（または --dangerously-bypass-approvals-and-sandbox フラグ）を指定して codex を実行します。

Dev Containers で Codex を実行する

ホストで Linux サンドボックスを直接実行できない場合や、組織ですでにコンテナ化された開発環境を標準としている場合は、Dev Containers で Codex を実行し、Docker を外側の分離境界として使用します。これは Visual Studio Code Dev Containers および互換性のあるツールで利用できます。

リファレンス実装として、Codex のセキュアな devcontainer のサンプルを使用してください。このサンプルでは、Codex、一般的な開発ツール、bubblewrap、およびファイアウォールベースの外向き通信制御がインストールされます。

リファレンス実装には、次のものが含まれています。

• Codex と一般的な開発ツールがインストールされた Ubuntu 24.04 ベースイメージ。
• 外向きアクセス用の許可リスト方式のファイアウォールプロファイル。
• コンテナ内でワークスペースを再度開くための VS Code 設定と拡張機能の推奨事項。
• コマンド履歴と Codex 設定用の永続マウント。
• コンテナに必要な権限が付与されている場合に、Codex が引き続き Linux サンドボックスを使用できるようにする bubblewrap。

試すには、次の手順に従います。

1. Visual Studio Code と Dev Containers 拡張機能をインストールします。
2. Codex のサンプル .devcontainer 設定をリポジトリにコピーするか、Codex リポジトリから直接開始します。
3. VS Code で Dev Containers: Open Folder in Container... を実行し、.devcontainer/devcontainer.secure.json を選択します。
4. コンテナが起動したら、ターミナルを開いて codex を実行します。

CLI からコンテナを起動することもできます。

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

サンプルは、主に次の 3 つの部分で構成されています。

• .devcontainer/devcontainer.secure.json は、コンテナの設定、権限、マウント、環境変数、VS Code 拡張機能を制御します。
• .devcontainer/Dockerfile.secure は、Ubuntu ベースのイメージとインストールされるツールを定義します。
• .devcontainer/init-firewall.sh は、外向きネットワークポリシーを適用します。

リファレンスのファイアウォールは、意図的に出発点として提供されています。分離のためにドメインの許可リストに依存する場合は、TTL を考慮した更新や DNS 対応ファイアウォールなど、環境に適した DNS リバインディング対策と DNS 更新対策を実装してください。

コンテナ内では、次のいずれかのモードを選択します。

• Dev Container プロファイルで、bwrap が内部サンドボックスを作成するために必要な権限が付与されている場合は、Codex の Linux サンドボックスを有効のままにします。
• コンテナを意図したセキュリティ境界として使用する場合は、Codex が第 2 のサンドボックスレイヤーを作成しようとしないように、コンテナ内で --sandbox danger-full-access を指定して Codex を実行します。

バージョン管理

Codex は、バージョン管理ワークフローと組み合わせることで最も効果的に機能します。

• 機能ブランチで作業し、作業を委任する前に git status をクリーンな状態に保ちます。これにより、Codex のパッチを分離して元に戻しやすくなります。
• 追跡対象ファイルを直接編集するよりも、パッチベースのワークフロー（たとえば git diff/git apply）を推奨します。小さな単位でロールバックできるよう、頻繁にコミットしてください。
• Codex の提案は他の PR と同様に扱ってください。対象を絞った検証を実行し、差分をレビューし、監査のためにコミットメッセージへ判断内容を記録します。

監視とテレメトリ

Codex は OpenTelemetry (OTel) を介したオプトインの監視をサポートしており、チームはローカルセキュリティのデフォルト設定を弱めることなく、利用状況の監査、問題の調査、コンプライアンス要件への対応を行えます。テレメトリはデフォルトで無効になっているため、設定で明示的に有効化してください。

概要

• Codex は、ローカルでの実行を自己完結させるため、デフォルトで OTel のエクスポートを無効にします。
• 有効にすると、Codex はチャット、API リクエスト、SSE/WebSocket ストリームのアクティビティ、ユーザーのプロンプト（デフォルトでは編集済み）、ツールの承認判断、ツールの結果を対象とする構造化ログイベントを生成します。
• Codex は、開発環境、ステージング環境、本番環境のトラフィックを区別するため、エクスポートされるイベントに service.name（生成元）、CLI バージョン、環境ラベルを付与します。

OTel を有効にする（オプトイン）

Codex の設定（通常は ~/.codex/config.toml）に [otel] ブロックを追加し、エクスポーターとプロンプトのテキストをログに記録するかどうかを選択します。

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none" は計測を有効なままにしますが、データはどこにも送信しません。
• 独自のコレクターにイベントを送信するには、次のいずれかを選択します。

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex はイベントをバッチ処理し、シャットダウン時にフラッシュします。Codex がエクスポートするのは、OTel モジュールによって生成されたテレメトリのみです。

イベントのカテゴリー

代表的なイベントタイプは次のとおりです。

• codex.conversation_starts（モデル、推論設定、サンドボックス／承認ポリシー）
• codex.api_request（試行、ステータス／成功、所要時間、エラーの詳細）
• codex.sse_event（ストリームイベントの種類、成功／失敗、所要時間、および response.completed におけるトークン数）
• codex.websocket_request および codex.websocket_event（リクエストの所要時間と、メッセージごとの種類／成功／エラー）
• codex.user_prompt（長さ。明示的に有効化しない限り、内容は編集されます）
• codex.tool_decision（承認／拒否、判断元：設定またはユーザー）
• codex.tool_result（所要時間、成功、出力の抜粋）

関連する OTel メトリクス（カウンターと所要時間ヒストグラムのペア）には、codex.api_request、codex.sse_event、codex.websocket.request、codex.websocket.event、codex.tool.call（それぞれに対応する .duration_ms インストゥルメントを含む）があります。

イベントの完全なカタログと設定リファレンスについては、GitHub の Codex 設定ドキュメントを参照してください。

セキュリティとプライバシーに関するガイダンス

• ポリシーでプロンプト内容の保存が明示的に許可されていない限り、log_user_prompt = false のままにしてください。プロンプトにはソースコードや機密データが含まれる可能性があります。
• テレメトリは、自身で管理するコレクターにのみ送信してください。コンプライアンス要件に合わせて、保持期限とアクセス制御を適用します。
• ツールの引数と出力は機密情報として扱ってください。可能な場合は、コレクターまたは SIEM での編集を推奨します。
• Codex が CODEX_HOME 配下にセッショントランスクリプトを保存しないようにする場合は、ローカルデータの保持設定（たとえば、history.persistence / history.max_bytes）を確認してください。高度な設定および設定リファレンスを参照してください。
• ネットワークアクセスを無効にして CLI を実行すると、OTel のエクスポート先であるコレクターに接続できません。エクスポートするには、workspace-write モードで OTel エンドポイントへのネットワークアクセスを許可するか、コレクタードメインを承認済みリストに追加したうえで Codex cloud からエクスポートしてください。
• 承認／サンドボックスの変更や予期しないツール実行がないか、イベントを定期的に確認してください。

OTel は任意の機能であり、上記のサンドボックスおよび承認による保護を置き換えるものではなく、補完するために設計されています。

管理対象の設定

エンタープライズ管理者は、管理対象の設定でワークスペースの Codex セキュリティ設定を構成できます。セットアップとポリシーの詳細については、同ページを参照してください。