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

Codex はコードとデータの保護を支援し、悪用のリスクを軽減します。

このページでは、サンドボックス化、承認、ネットワークアクセスなど、Codex を安全に操作する方法について説明します。接続された GitHub リポジトリをスキャンする製品である Codex Security をお探しの場合は、Codex Securityを参照してください。

デフォルトでは、エージェントはネットワークアクセスを無効にして実行されます。ローカルでは、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 は、シェルコマンドやファイル変更ではない場合でも、副作用を示すアプリ（コネクター）ツール呼び出しについて承認を求めることがあります。破壊的なアプリ / 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" }

一時的な 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'

この機能は、有効化されたネットワークアクセスの適用方法を変更するものであり、それ自体がネットワークアクセスを付与するわけではありません。sandbox_workspace_write.network_access と workspace-write config を使用して、コマンドがネットワークアクセスを持つかどうかを決定します。

ネットワークオフ + network_proxy オン: ネットワークはオフのままで、機能は何も行いません。
ネットワークオン + network_proxy オフ: ネットワークは制限のない直接の外向きアクセスで有効なままです。
ネットワークオン + network_proxy オン: ネットワークは有効なままで、外向きトラフィックは設定されたネットワークポリシーによって制限されます。

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

ネットワークポリシー¶

ドメインルールは許可リスト優先です。

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

ローカルおよびプライベートな宛先¶

デフォルトでは、allow_local_binding = false はループバック、リンクローカル、プライベートな宛先をブロックします。

特定の例外: コマンドで 1 つのローカルターゲットが必要な場合は、完全一致のローカル 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 はデフォルトでオフです。有効にすると、次のようになります。

設定	デフォルト	動作
`enabled`	`false`	コマンドのネットワークアクセスがすでにオンの場合にのみ、サンドボックス化されたネットワークを開始します。
`domains`	unset	許可リスト動作を使用するため、`allow` ルールを追加するまで外部の宛先は許可されません。完全一致ホスト、範囲を限定したワイルドカード、グローバルな `*` 許可ルールをサポートし、`deny` が常に優先されます。
`unix_sockets`	unset	明示的な `allow` ルールを追加するまで、Unix ソケットの宛先は許可されません。
`allow_local_binding`	`false`	完全一致のローカル IP リテラルまたは `localhost` 許可ルールを追加するか、より広いローカル / プライベートアクセスを明示的に選択しない限り、ローカルおよびプライベートネットワークの宛先をブロックします。
`enable_socks5`	`true`	ポリシーで許可されている場合に SOCKS5 サポートを公開します。
`enable_socks5_udp`	`true`	SOCKS5 が利用可能な場合に SOCKS5 経由の UDP を許可します。
`allow_upstream_proxy`	`true`	サンドボックス化されたネットワークが環境変数の上流プロキシを使用できるようにします。
`dangerously_allow_non_loopback_proxy`	`false`	localhost の外部に意図的に公開しない限り、リスナーエンドポイントをループバック上に保持します。
`dangerously_allow_all_unix_sockets`	`false`	この保護を意図的にバイパスしない限り、Unix ソケットアクセスを許可リストベースに保ちます。

完全なネットワークアクセスを起動されたコマンドに付与せずに、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
設定によっては、作業ディレクトリを明示的に信頼するまで Codex が read-only で起動することもあります（オンボーディングプロンプトや /permissions などを使用します）。
ワークスペースには現在のディレクトリと /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-rule プロンプト、MCP プロンプト、request_permissions プロンプト、スキルスクリプト承認を対象とします。

自動承認レビュー¶

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

approvals_reviewer = "user"

approval_policy = "on-request" やきめ細かな承認ポリシーなど、承認が対話的な場合に自動承認レビューが適用されます。approvals_reviewer = "auto_review" を設定すると、Codex がリクエストを実行する前に、対象となる承認リクエストをレビュアーエージェント経由で処理できます。

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

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

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

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

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

ChatGPT デスクトップアプリでは、これらのレビューは、Reviewing、Approved、Denied、Aborted、Timed out などのステータスを持つ自動レビュー項目として表示されます。レビュー対象のリクエストについて、リスクレベルとユーザー認可の評価が含まれることもあります。

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

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

意図	フラグ / 設定	効果
自動（プリセット）	フラグ不要または `--sandbox workspace-write --ask-for-approval on-request`	Codex はワークスペース内のファイルを読み取り、編集し、コマンドを実行できます。ワークスペース外の編集やネットワークアクセスには承認が必要です。
安全な読み取り専用ブラウジング	`--sandbox read-only --ask-for-approval on-request`	Codex はファイルを読み取り、質問に回答できます。編集、コマンド実行、ネットワークアクセスには承認が必要です。
非対話型の読み取り専用（CI）	`--sandbox read-only --ask-for-approval never`	Codex はファイルの読み取りのみが可能で、承認を求めることはありません。
自動編集。ただし信頼できないコマンドの実行には承認を求める	`--sandbox workspace-write --ask-for-approval untrusted`	Codex はファイルを読み取り、編集できますが、信頼できないコマンドを実行する前に承認を求めます。
自動レビューモード	`--sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review` または `approvals_reviewer = "auto_review"`	標準のオンデマンドモードと同じサンドボックス境界ですが、対象となる承認リクエストはユーザーに表示されず、自動レビューによってレビューされます。
危険な完全アクセス	`--dangerously-bypass-approvals-and-sandbox`（エイリアス: `--yolo`）	サンドボックスなし、承認なし（推奨されません）

非対話型の実行には 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 内に保持するには、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 が必要とする namespace、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、ファイアウォールベースの外向き制御をインストールします。

Dev Containers は大幅な保護を提供しますが、すべての攻撃を防ぐわけではありません。コンテナ内で --sandbox danger-full-access または --dangerously-bypass-approvals-and-sandbox を使用して Codex を実行すると、悪意のあるプロジェクトによって、Codex の認証情報を含む devcontainer 内で利用可能なあらゆるものが外部へ流出する可能性があります。このパターンは信頼できるリポジトリでのみ使用し、他の権限昇格された環境と同様に Codex のアクティビティを監視してください。

リファレンス実装には次が含まれます。

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

試すには、次の手順を実行します。

Visual Studio Code と Dev Containers 拡張機能をインストールします。
Codex の例にある .devcontainer のセットアップをリポジトリにコピーするか、Codex リポジトリから直接開始します。
VS Code で Dev Containers: Open Folder in Container... を実行し、.devcontainer/devcontainer.secure.json を選択します。
コンテナの起動後、ターミナルを開いて 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 サンドボックスを有効にしたままにします。
コンテナを意図したセキュリティ境界とする場合は、コンテナ内で --sandbox danger-full-access を指定して Codex を実行し、Codex が 2 つ目のサンドボックスレイヤーを作成しないようにします。

バージョン管理¶

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 エクスポートはコレクターに到達できません。エクスポートするには、OTel エンドポイントに対して workspace-write モードでネットワークアクセスを許可するか、コレクターのドメインを承認済みリストに登録して Codex cloud からエクスポートします。
承認 / サンドボックスの変更や予期しないツール実行がないか、イベントを定期的に確認してください。

OTel はオプションであり、上記のサンドボックスおよび承認による保護を補完するよう設計されています。置き換えるものではありません。

管理対象設定¶

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