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

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

デフォルトでは、エージェントはネットワークアクセスを無効にした状態で動作します。ローカルでは、OS が強制するサンドボックスによって、Codex がアクセスできる範囲を通常は現在のワークスペースに限定します。さらに、どの操作の前に Codex が処理を止めてユーザーに承認を求めるかを、承認ポリシーで制御します。

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 を含める必要があります。

サンドボックスと承認

Work Cloud からローカルコンピューターにアクセスする場合、ローカルとクラウドには別々の実行ポリシーが適用されます。

• クラウドでの実行： Work のクラウドコンテナには、既存の Work Cloud ポリシーが適用されます。
• ローカルでの実行： 接続先のコンピューターには、ローカル実行の要件が適用されます。MDM と従来の管理対象デバイスの要件が最優先され、次に Agent Security、最後にデバイスのシステム要件ファイルが適用されます。

ローカルアクセスを利用する Work と dot では、管理ポリシーが有効な場合、共有クラウドオーケストレーターに、対応する Global ポリシーが適用されます。Work のクラウドコンテナと dot のクラウドコンピューターは、それぞれ独自の実行設定と要件を使用します。ローカルとクラウドの制御は個別にテストしてください。承認やウェブ検索など、オーケストレーターに関する制御は Global で設定します。許可する承認ポリシーとウェブ検索モードは、専用の設定項目があればそこで指定し、その他の対応フィールドには TOML を使用してください。Work Cloud からローカルコンピューターにアクセスするための設定に Codex の例を適用する前に、設定リファレンスでフィールドの一覧と各設定が適用される実行範囲を確認してください。

デスクトップ、Web、モバイルを切り替えても、別のコンピューターへのアクセス権は付与されません。同期を有効にする前やアクセス範囲を広げる前に、Agent Security の基本設定を確認し、各実行環境で許可される操作とブロックされる操作をそれぞれテストしてください。詳しくは管理対象の設定を参照してください。

Codex のセキュリティ制御には、次の 2 つの仕組みを組み合わせて使用します。

• サンドボックスモード：モデルが生成したコマンドを実行する際に、Codex が技術的に実行できる操作を定めます。たとえば、書き込み可能な場所やネットワークにアクセスできるかどうかを制御します。
• 承認ポリシー：どの操作の実行前に Codex がユーザーに承認を求めるかを定めます。たとえば、サンドボックスの外での実行、ネットワークの利用、信頼済みのコマンド群に含まれないコマンドの実行が対象です。

Codex が使用するサンドボックスモードは、実行環境によって異なります。

• Codex Cloud（従来版）：OpenAI が管理する隔離されたコンテナで動作し、ホストシステムや無関係なデータへのアクセスを防ぎます。実行は 2 段階に分かれます。最初のセットアップ段階では、ネットワークにアクセスして指定の依存関係をインストールできます。続くエージェント段階は、環境のインターネットアクセスを有効にしない限り、デフォルトでオフラインで動作します。クラウド環境に設定したシークレットはセットアップ中のみ利用でき、エージェント段階の開始前に削除されます。
• 現行の Codex Cloud：セットアップ時とタスク実行時の認証情報の取り扱いについては、環境変数とネットワークシークレットを参照してください。
• Codex CLI / IDE 拡張機能：OS レベルの仕組みによってサンドボックスポリシーを強制します。デフォルトではネットワークアクセスは無効で、書き込み権限は現在のワークスペースに限定されます。許容できるリスクに応じて、サンドボックス、承認ポリシー、ネットワークを設定できます。

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

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

シェルコマンドやファイル変更を伴わない操作でも、アプリ（コネクタ）のツールが副作用のある操作だと宣言している場合、Codex は呼び出し前に承認を求めることがあります。アプリや MCP のツールがアノテーションで破壊的な操作だと宣言している場合、その呼び出しには常に承認が必要です。ただし、読み取り操作を示すアノテーションもある場合は、そちらが優先されます。

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

Codex と ChatGPT Work で使用する GPT-6 Astra には、安全性の監視機能があります。監視は非同期で実行され、モデルに安全上の問題が疑われる挙動を検出すると、タスクを一時停止することがあります。原因となった操作の後にタスクが一時停止する場合もあります。監視を利用する場合も、サンドボックス、権限管理、実行結果のレビューが必要です。

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

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

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

現行の Codex Cloud のネットワーク設定については、サービスへの接続を参照してください。Codex Cloud（従来版）でインターネットへのフルアクセスを有効にする方法や、ドメインの許可リストを使用する方法については、エージェントのインターネットアクセスを参照してください。

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

[sandbox_workspace_write]
network_access = true

ネットワークの分離

管理対象の Codex Cloud では、対応する実行経路において、Agent Security の要件がコマンドのネットワーク通信を制限します。Codex Cloud 環境のインターネット設定は別途適用されます。Agent Security でドメインを許可しても、クラウド環境のインターネット設定による制限は解除されません。コマンドのネットワーク制御だけで、ホスト型のウェブ検索、アプリ、MCP が無効になることはありません。ChatGPT Work Cloud では機能ごとに独自の権限を使用し、これらの Agent Security 要件は継承しません。

管理者が設定したコマンド通信用の許可リストは、管理対象プロキシを使用するコマンドに適用されます。サンドボックスの制限を全面的に解除した実行がポリシーで許可され、承認も得られた場合、その実行ではコマンド用プロキシを経由しないことがあります。限定的なネットワークアクセスの許可と、サンドボックスの制限の全面解除は別の操作です。意図した保護範囲に合わせて、強制する承認要件とサンドボックス要件を設定し、通常のコマンドと権限を昇格して実行するコマンドの両方をテストしてください。詳しくは管理対象の設定を参照してください。

ネットワークアクセスは、コマンドが起動するスクリプト、プログラム、サブプロセスの接続先に適用されるルールで制御します。コマンドのネットワークアクセスがすでに有効な場合は、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'

この機能は、すでに有効なネットワークアクセスに制限を適用する方法を変更します。機能自体がネットワークアクセスを許可するわけではありません。コマンドにネットワークアクセスを許可するかどうかは、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 では、ループバック、リンクローカル、プライベートネットワークの接続先をブロックします。

• 個別の例外：コマンドが特定のローカル接続先を必要とする場合は、ローカル 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 のクラウドタスク、クライアントからのモデルリクエストや認証リクエストは対象外です。これらの機能では、それぞれ別のサービス接続、機能設定、ワークスペースポリシー、環境側の制御を使用します。

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

管理対象ユーザーには、コマンドのネットワークポリシーと、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
• 環境によっては、作業ディレクトリを明示的に信頼するまで、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 がディレクトリとして存在する場合は、読み取り専用として保護されます。
• <writable_root>/.aws がディレクトリとして存在する場合は、読み取り専用として保護されます。
• 保護は再帰的に適用されるため、これらのパス以下はすべて読み取り専用になります。

承認プロンプトなしでの実行

--ask-for-approval never または短縮形の -a never で、承認プロンプトを無効にできます。

このオプションはすべての --sandbox モードで使用できるため、Codex が自律的に操作できる範囲は引き続き制御できます。Codex は設定された制約の範囲内で可能な限りタスクを実行します。

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

承認の種類ごとに対応を分けたい場合は、approval_policy = { granular = { ... } } を使うと、指定した種類の承認プロンプトのみ対話形式で表示し、その他のリクエストを自動的に拒否できます。個別設定の対象は、サンドボックスの承認、実行ポリシーのルールによるプロンプト、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 のツール呼び出しです。サンドボックス内で実行する場合でも、コマンドルールによってレビューが必要になることがあります。

レビューポリシーでは、データの持ち出し、認証情報の探索、セキュリティを継続的に弱める変更、破壊的な操作の有無を確認します。低リスクおよび中リスクの操作は、ポリシーで許可されていれば実行できます。リスクが極めて高い操作は拒否されます。高リスクの操作には、ユーザーから十分な許可を得ていることと、該当する拒否ルールがないことの両方が必要です。プロンプトの構築、レビューセッション、解析のいずれかに失敗した場合、操作は許可されません。タイムアウトは別の状態として表示されますが、この場合も操作は実行されません。

ローカル環境または組織全体でルールを追加したり、ポリシーを置き換えたりする方法については、自動レビューの設定を参照してください。

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

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

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

非対話実行には codex exec --sandbox workspace-write を使用してください。

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-exec を使い、プロファイル（-p）には選択した --sandbox モードに対応するものを指定します。読み取りアクセスを制限した状態でプラットフォームのデフォルト設定が有効になる場合、Codex は /System へのアクセスを広く許可する代わりに、必要なアクセスに絞った macOS 用ポリシーを追加し、一般的なツールとの互換性を保ちます。
• Linux ではデフォルトで bwrap と seccomp を併用します。
• Windows は MXC に対応しており、従来の elevated と unelevated をフォールバックとして利用できます。Windows Subsystem for Linux 2（WSL2） では、Codex は Linux 版のサンドボックスを使用します。Codex 0.114 までは WSL1 にも対応していましたが、0.115 から Linux 版サンドボックスが bwrap に移行したため、WSL1 はサポート対象外です。

Windows 版の Codex IDE 拡張機能は WSL2 を直接サポートしています。WSL2 が利用可能な場合に常にエージェントを WSL2 内で実行するには、VS Code の設定に次の項目を追加します。

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

これにより、ホスト OS が Windows でも、IDE 拡張機能のコマンド実行、承認、ファイルシステムへのアクセスに Linux サンドボックスと同じ制限が適用されます。詳しくは WSL ガイドを参照してください。

Windows で実行する場合、デバイスとポリシーが対応していれば MXC を優先します。config.toml に次の設定を追加してください。

[features]
prefer_mxc = true

フォールバック用に、windows.sandbox にはポリシーで許可されている従来の実装を指定しておいてください。設定と互換性の制約については、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 とその互換ツールで使用できます。

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

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

バージョン管理

Codex を利用する際は、バージョン管理を取り入れた次のような手順が適しています。

• 機能ブランチで作業し、Codex に作業を任せる前に git status で未コミットの変更がないことを確認します。こうすると、Codex による変更を切り分けて取り消しやすくなります。
• 追跡対象のファイルを直接編集するよりも、パッチを使う手順（例：git diff / git apply）を優先してください。こまめにコミットすると、小さな単位で変更を取り消せます。
• Codex の提案も他の PR と同様に扱います。変更に合わせて検証を行い、差分をレビューし、監査に備えて判断内容をコミットメッセージに記録してください。

監視とテレメトリ

Codex では、必要に応じて OpenTelemetry（OTel）による監視を有効にできます。チームはローカルのセキュリティのデフォルト設定を維持したまま、利用状況の監査、問題の調査、コンプライアンス要件への対応を行えます。テレメトリはデフォルトでは無効です。使用する場合は設定で明示的に有効にしてください。

概要

• ローカルでの実行をその環境内で完結させるため、Codex はデフォルトで OTel のエクスポートを無効にしています。
• 有効にすると、チャット、API リクエスト、SSE/WebSocket ストリームの動作、ユーザープロンプト（本文はデフォルトで伏せられます）、ツールの承認判断、ツールの実行結果について、Codex が構造化ログイベントを出力します。
• エクスポートされるイベントには、service.name（発行元）、CLI のバージョン、環境ラベルが付与されます。環境ラベルを使って、開発、ステージング、本番の通信を区別できます。

OTel の有効化（任意）

[otel] ブロックを Codex の設定ファイル（通常は ~/.codex/config.toml）に追加し、エクスポーターと、プロンプト本文を記録するかどうかを指定します。

[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 で機密部分をマスキングしてください。
• ローカルのデータ保持設定（例：history.persistence / history.max_bytes）を確認すると、Codex が CODEX_HOME 以下にセッションの記録を保存しないように設定できます。詳しくは詳細設定と設定リファレンスを参照してください。
• ネットワークアクセスを無効にして CLI を実行すると、OTel はコレクターにデータを送信できません。エクスポートするには、workspace-write モードで OTel エンドポイントへのネットワークアクセスを許可するか、コレクターのドメインを許可リストに追加して Codex Cloud からエクスポートしてください。
• イベントを定期的に確認し、承認やサンドボックスの設定変更、予期しないツール実行がないかを調べてください。

OTel は任意の機能です。前述のサンドボックスと承認による保護を補完するもので、これらの保護に代わるものではありません。

管理対象の設定

Enterprise の管理者は、管理対象の設定でワークスペースの Codex セキュリティ設定を管理できます。設定手順とポリシーの詳細は、リンク先を参照してください。