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

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 での安全性監視が組み込まれています。監視は非同期で実行され、モデルに安全でない可能性のある動作が検出されると、タスクを一時停止することがあります。一時停止は、その原因となった操作の後に発生する場合があります。監視は、サンドボックス、権限、結果のレビューに代わるものではありません。

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

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

ネットワークアクセス Elevated Risk

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'

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

• ネットワークが無効 + 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 によってループバック、リンクローカル、 プライベートの接続先がブロックされます。

• 個別の例外：コマンドが特定のローカル接続先にアクセスする必要がある場合は、 そのローカル 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 サーバーへの接続、ブラウザやコンピューターの使用による操作、Codex Cloud のタスク、クライアントによるモデルリクエストや認証リクエストはフィルタリングしません。これらには、それぞれ別のサービス接続、機能設定、ワークスペースポリシー、環境の制御が適用されます。

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

管理対象のユーザーには、コマンドのネットワークポリシーに加えて、 allowed_web_search_modes、承認済みの mcp_servers、アプリ、プラグイン、ブラウザ、コンピューターの使用に関する 機能要件などの制御を組み合わせてください。 管理対象の設定を参照してください。

起動されるコマンドに全面的なネットワークアクセスを許可せずに、ウェブ検索ツールを制御することもできます。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 exec --full-auto による呼び出しは、互換性のために非推奨の方法として引き続き利用できますが、Codex は警告を表示します。

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 に移行したため、サポート対象外となりました。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 コンテナーを設定してから、コンテナー内で --sandbox danger-full-access（または --dangerously-bypass-approvals-and-sandbox フラグ）を指定して codex を実行します。

Dev Containers での Codex の実行

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

リファレンス実装として、Codex のセキュアな開発コンテナーのサンプルを参照してください。このサンプルでは、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 セキュリティ設定を構成できます。セットアップとポリシーの詳細は、同ページを参照してください。