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

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

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

ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能でのサンドボックスの仕組みの概要は、 サンドボックスを参照してください。 企業向けセキュリティのより幅広い概要は、Codex セキュリティホワイトペーパーを参照してください。

廃止された untrusted 承認ポリシーからの移行

Codex と ChatGPT Work は、approval_policy = "untrusted" をサポートしなくなりました。 この廃止された設定があると、どちらのクライアントも起動できなくなる場合があります。 ユーザー設定やプロジェクト設定、プロファイルファイル、起動スクリプト、管理対象の デフォルト設定から削除してください。対話形式で読み取り専用として使う場合は、次のようにします。

sandbox_mode = "read-only"
approval_policy = "on-request"

または、codex --sandbox read-only --ask-for-approval on-request を実行します。

on-request では、サンドボックスで許可されたコマンドを承認なしで実行し、 アクセス可能なファイルを読み取り、ネットワークアクセスが有効であれば利用できます。

より厳格なコマンド承認ルールを維持するには、 approval_policy を明示的に指定せず、ユーザーレベルの ~/.codex/config.toml にプロジェクトエントリを追加します。

[projects."/path/to/project"]
trust_level = "untrusted"

これにより、実行ポリシーのルールで許可されていないコマンドには承認が必要になります。 プロジェクトローカルの設定も無効になります。on-request を明示的に設定すると、 プロジェクトから導出されるポリシーが上書きされます。これを許可するには、管理対象の allowed_approval_policies に untrusted を含める必要があります。

サンドボックスと承認

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 ツールの呼び出しには、常に承認が必要です（ただし、読み取りアノテーションも宣言されている場合は、そちらが優先されます）。

安全性の監視とタスクの一時停止

GPT-6 Astra には、Codex と ChatGPT Work での安全性の監視機能が含まれています。監視は 非同期で実行され、安全でない可能性があるモデルの動作を検出すると、タスクを一時停止することがあります。 一時停止は、原因となった操作の後に発生する場合があります。監視は、 サンドボックス、権限、結果のレビューに代わるものではありません。

タスクが一時停止した場合は、通知を読み、確認結果が提供されていればレビューしてください。再開するのは、 タスクを安全に続行できることを確認してからにしてください。通知にタスクが 終了したと表示されている場合や、再開する選択肢がない場合は、その インターフェースから再開することはできません。

安全性の監視は、タスク中のモデルの動作を評価します。 自動承認レビューは、すでに承認が必要とされている個々の操作を、 実行前に評価します。自動承認レビューで承認された操作が 含まれるタスクでも、後から監視によって一時停止されることがあります。

ネットワークアクセス

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 の設定を使って、コマンドにネットワークアクセスを許可するかどうかを決めます。

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

プロキシ機能は権限プロファイルにも適用されます。 プロファイルの network.enabled = true はコマンドのネットワークアクセスを許可し、 features.network_proxy = true はそのプロファイルのドメインルールの 適用を有効にします。

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

この例でプロキシ機能を省略すると、コマンドはネットワークへ直接アクセスでき、 api.openai.com の許可ルールは宛先を制限しません。

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

ネットワークポリシー

ドメインルールは許可リストを基本とします。

• 完全一致のホスト指定は、そのホスト自身にのみ一致します。
• *.example.com は api.example.com などのサブドメインに一致しますが、 example.com には一致しません。
• **.example.com は、ルートドメインとサブドメインの両方に一致します。
• グローバルな * 許可ルールは、拒否されていない任意の公開ホストに一致します。* は 広範なネットワークアクセスを許可するものとして扱い、可能な限り範囲を限定したルールを使ってください。
• 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 はデフォルトで無効です。有効にすると、次のように動作します。

コマンド用ネットワークプロキシの対象外のトラフィック

ネットワークプロキシは、ローカルのコマンドサンドボックス内で実行されるスクリプト、プログラム、子プロセスを フィルタリングします。ウェブ検索、アプリや コネクターのツール呼び出し、MCP server 接続、ブラウザーや Computer Use の操作、 Codex cloud のタスク、クライアントのモデルリクエストや認証リクエストはフィルタリングしません。これらは 別のサービス接続、機能設定、ワークスペース ポリシー、環境制御を使用します。

ブラウザーツールは、オリジンにアクセスする前に、管理対象のネットワーク拒否ルールと、許可先を限定する許可リストを 個別に確認します。ブラウザーのオリジンポリシーでは、サイトへのアクセス、 アップロード、ダウンロード、開発者ツールをさらに制限できます。 管理対象のブラウザー制御を参照してください。

管理対象ユーザーの場合は、コマンドのネットワークポリシーを、 allowed_web_search_modes、承認済みの mcp_servers、アプリ、プラグイン、ブラウザー、Computer Use の 機能要件などの制御と組み合わせてください。 管理対象の設定を参照してください。

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

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

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

デフォルト設定と推奨事項

• 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" や詳細な承認ポリシーなど、 承認が対話形式の場合に適用されます。 approvals_reviewer = "auto_review" を設定すると、対象となる承認リクエストは、 Codex がそのリクエストを実行する前にレビュー担当エージェントへ送られます。

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 による呼び出しを非推奨の互換手段として維持しており、警告を表示します。

config.toml での設定

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

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
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 が必要とする名前空間操作、setuid bwrap、または seccomp の操作がホストやコンテナの設定によってブロックされると、サンドボックスが動作しない場合があります。

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

Dev Containers で Codex を実行する

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

参照実装として、Codex の安全な devcontainer の例を使ってください。この例では、Codex、一般的な開発ツール、bubblewrap、ファイアウォールによる外向き通信の制御をインストールします。

参照実装には次が含まれます。

• Codex と一般的な開発ツールをインストールした Ubuntu 24.04 のベースイメージ。
• 外向きアクセスを許可リストで制御するファイアウォールプロファイル。
• コンテナ内でワークスペースを開き直すための VS Code 設定と推奨拡張機能。
• コマンド履歴と Codex 設定を保持する永続マウント。
• bubblewrap。コンテナが必要なケーパビリティを付与している場合、Codex は引き続き Linux サンドボックスを使用できます。

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

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

OTel は任意の機能で、上記のサンドボックスと承認による保護を補完するものであり、置き換えるものではありません。

管理対象の設定

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