ChatGPT ドキュメント
日本語
お問い合わせ goolvyouyou@gmail.com

管理対象の構成

サポート対象のローカルクライアント全体にデフォルト設定を配布し、要件を強制します

管理対象設定を使用すると、企業の管理者は ChatGPT Work と Codex に対して、サポートされている要件とデフォルト設定を指定できます。要件は、ユーザーとタスクが実行できる内容を制限します。デフォルト設定は初期値を提供します。サポート状況は、製品、クライアントのバージョン、実行環境によって異なります。

クラウド管理に対応した設定は、管理コンソールの エージェントセキュリティ から設定します。一般的な操作には設定コントロールを使い、設定テキストの確認、コピー、編集には TOML として編集 を選択します。どちらの表示でも同じポリシーを編集します。 TOML では、専用のコントロールがない対応フィールドも設定できます。クラウド管理の設定を使うためにローカルファイルを配布する必要はありません。認証の制限とデバイス管理によるデプロイには、別途ローカル設定が必要です。

Enterprise 管理者は、次の方法でサポート対象のローカルクライアントの動作を制御できます。

  • 要件: 管理者が強制的に適用する制約で、ユーザーは上書きできません。

  • デフォルト設定: システムまたはクラウドで管理される config.toml の設定で、ユーザーが上書きできます。

  • 従来の管理対象デフォルト設定: サポートされているクライアントの起動時に適用される managed_config.toml の初期値です。ユーザーは実行中も設定を変更できます。クライアントは次回の起動時にこれらのデフォルト設定を再適用します。

Global のベースライン、環境別の上書き設定、オーケストレーターとエグゼキューターのフィールド一覧については、Agent Security を参照してください。

エージェントセキュリティでポリシーを設定する

エージェントセキュリティが有効な場合、ワークスペースのオーナー、ワークスペースの管理者、および Codex の管理者権限を持つメンバーがポリシーを管理できます。ポリシーエディターへのアクセス権があっても、そのポリシーで制御する機能へのアクセス権がメンバーに付与されるわけではありません。

ワークスペースの基本設定には ワークスペースのデフォルト を使います。特定のユーザー、グループ、ロールに異なる設定が必要な場合は、オーバーライド を使います。対象者のオーバーライドではポリシーを適用する相手を選択し、環境設定では、対応する実行制御を適用する場所を選択します。

  1. 管理コンソール > エージェントセキュリティ を開き、ワークスペースのデフォルト、または オーバーライド 内の編集するポリシーを選択します。
  2. 強制する制限を設定するには 要件 を開き、メンバーがその制限内で変更できる初期値を設定するには デフォルト を開きます。
  3. 承認、ウェブ検索など、エージェント全体の設定は グローバル に保持します。利用可能な場合は、該当するカードの 環境設定を追加 を使い、対応する実行設定用に ローカル環境 または Codex Cloud 環境 を追加します。空の環境ドキュメントはグローバルの設定を継承します。現在の基本設定をコピーしたり、固定したりするものではありません。
  4. このガイドで説明するコントロールを使います。詳細なフィールドを設定するには、 TOML として編集 を選択し、適切なスコープの requirements.toml または config.toml を編集します。ビジュアルエディターに戻るには 設定コントロールを使用 を選択します。
  5. 検証メッセージを確認し、変更を保存 を選択します。ルールエディターでルールを適用すると下書きが更新されますが、その操作だけではポリシーは保存されません。
  6. 管理者と従業員の操作を確認するの説明に従って、ポリシーの選択と対応クライアントの動作を確認します。

環境エディターと対応フィールドは、ワークスペースとポリシーによって異なります。グローバルの設定を環境に移動する前に、設定の適用範囲を確認してください。グローバルの設定が、すべての製品や実行経路に適用されるとは限りません。

設定をコピーまたは再利用する

ビジュアルエディターが TOML に取って代わるわけではありません。設定のコピー、参照用コピーの保存、別のポリシーでの設定の再利用には、TOML として編集 を選択します。ビジュアルエディターに戻るには、設定コントロールを使用 を選択します。

  1. コピー元のポリシーを開き、TOML として編集 を選択します。
  2. コピーするスコープとして、グローバル または利用可能な環境タブを選択します。再利用する内容に応じて、要件（requirements.toml）、デフォルト （config.toml）、またはその両方からテキストをコピーします。
  3. コピー先のポリシーを開き、TOML として編集 を選択して、一致するスコープを選択します。要件を requirements.toml に、デフォルトを config.toml に貼り付けます。テキストを置き換える前に、コピー先の既存の設定を確認し、引き続き適用すべき無関係の設定は保持してください。
  4. 検証メッセージとコピー先ポリシーの対象および優先順位を確認し、 変更を保存 を選択します。コピーしたポリシーを運用に使う前に、クライアントの実際の動作を確認してください。

コピーしたテキストには、そのポリシーとスコープで記述された設定が含まれます。割り当て、ポリシーの順序、他の環境ドキュメント、または他のポリシーやデバイス設定を組み合わせた実効設定は含まれません。必要に応じて環境設定を個別にコピーしてください。表示の切り替えやテキストのコピーでは、ポリシーの変更は保存されません。

以下の例をお試しください。設定を変更してから TOML として編集 を選択すると、その設定を確認できます。設定コントロールを使用 で元の表示に戻り、引き続き試すことができます。

ポリシーの例

サンプルの設定を変更してから表示を切り替えると、同じ設定を TOML で確認できます。

要件 · グローバル

これはサンプルです。変更はこのページ内にのみ保持され、ワークスペースは更新されません。最後に変更したフィールドは TOML 表示で強調表示されます。

適切なコントロールを選ぶ

タスク 設定場所 変更内容
ブラウザーとネイティブアプリへのアクセスを制限する 要件 > デスクトップ機能の利用可否、サイトルール、アプリルール 対応するデスクトップ機能の利用可否と、それらがアクセスできるサイトやアプリを制御します。
承認、サンドボックス、ウェブ検索の選択肢を制限する 要件 > ポリシーのガードレール 対応クライアントで利用できる選択肢を制限します。
承認、権限、検索、ツール動作の初期値を設定する デフォルト 強制される要件の範囲内でメンバーが変更できる値を設定します。
コマンドのネットワーク接続先を制限する 要件 > ネットワーク利用の制御 対応するコマンドの通信に、管理されたネットワークルールを適用します。ワークスペース全体のインターネット接続を切り替えるものではありません。
プラグインと管理対象フックを設定する TOML として編集 専用のビジュアルコントロールがない、対応ポリシーフィールドを設定できます。
サインイン前にログイン方法やワークスペースを制限する ローカルのシステム要件または macOS MDM クラウドポリシーが読み込まれる前に認証の制限を適用します。

ブラウザーと Computer Use を制御する

管理コンソールの エージェントセキュリティ を使って、対応するデスクトップクライアントのブラウザーとネイティブアプリへのアクセスを管理します。まず UI のコントロールを使ってください。以下の TOML の例は、ファイルによるポリシーの配布や、TOML エディターが必要な設定のリファレンスとして利用できます。

Browser Use は、ブラウザー内でのエージェントの操作を制御します。Computer Use は、ネイティブデスクトップアプリ内でのエージェントの操作を制御します。組み込みブラウザーペインの設定は Browser Use とは別です。ブラウザーの利用経路による違いについては、ブラウザーセッションと既存のサインインをご覧ください。

始める前に

Agent Security ポリシーを管理する権限を持つアカウントを使ってください。ポリシーを適用する対象者と、サポートする必要があるクライアントのバージョンおよびオペレーティングシステムを確認してください。ポリシーの割り当て、グローバル設定、対応する環境のオーバーライドについては、Agent Securityをご覧ください。

ユーザーが上書きできない制限には 要件 を使います。デフォルト では、その制限内での初期値を設定します。サイトやアプリを許可しても、プラグインのインストール、オペレーティングシステムの権限の付与、ユーザーのサインイン、または引き続き確認が必要な操作の承認は行われません。

デスクトップ機能の利用可否 で、ブラウザーの使用、外部ブラウザーの使用、コンピューターの使用 を確認します。強制的にオフ にすると、対応する機能が無効になります。サイトやアプリの許可ルールで、この設定を上書きすることはできません。完全な CDP アクセス は個別に確認してください。ユーザーによるオプトインをブロック すると、ユーザーはこの機能を有効にできなくなります。

これらのデスクトップ向けの制御では、ホストされた Work Cloud ブラウザーは設定されません。 クラウドブラウザーの使用 とクラウドネットワークアクセス は、 管理コンソール > 権限とロール > ワークスペースの機能 > クラウドコンピューターの機能 で個別に管理します。 Agent Security が Work Cloud に適用される仕組みを参照してください。

ブラウザーアクセスを設定する

  1. 管理コンソール > Agent Security を開きます。ワークスペースの基準には ワークスペースのデフォルト を使用するか、上書き設定 で該当するポリシーを開きます。 要件 で、デスクトップブラウザーの制御 に移動します。
  2. サイトルール で、デフォルト 行のアクションを開き、デフォルトを編集 を選択します。承認済みのサイトのみにアクセスを制限するには、サイトアクセス をブロック に設定してから、 ルールを適用 を選択します。一致するサイトルールでデフォルトルールを使用 のままになっている設定には、 デフォルト 行の値が適用されます。
  3. サイトルールを追加 を選択します。サイトまたはパターン に、スキーム、ホスト名、任意のポートからなるオリジンを入力します。たとえば、https://example.comは有効ですが、 https://example.com/filesは無効です。パス、クエリ、フラグメントを含めないでください。 HTTP と HTTPS は異なるオリジンです。ポートがスキームのデフォルトと異なる場合は、ポートを指定してください。
  4. サイトアクセス を設定し、ダウンロード、アップロード、デバッグ/CDP を確認します。必要に応じて許可 またはブロック を選択するか、設定をデフォルトルールを使用 のままにします。デバッグ/CDP は、ブラウザーのデバッグに使用する Chrome DevTools Protocol への完全なアクセスを制御します。許可 を選択すると、通常のポリシーと承認のチェックが引き続き行われます。
  5. サイトの自動レビュー、常に許可、承認の有効期間 を確認します。 承認の有効期間 では、このターン とこのスレッド を選択できます。デスクトップブラウザーの制御 にあるブラウザー履歴、サイトの承認を保存、リクエストを自動承認 も確認してください。
  6. ルールを追加 を選択し、検証メッセージを確認して、変更を保存 を選択します。ポリシーを受信する対応クライアントで、許可されたサイトとブロックされたサイトをテストします。アップロード、ダウンロード、その他の制限対象の操作は個別にテストしてください。

ブラウザー操作の自動レビューを無効にすると、代わりにそれらの操作についてユーザーに承認を求めます。モデルの安全性監視は無効になりません。

複数のオリジンパターンが一致する場合は、設定ごとに最も制限の厳しい値が優先されます。ローカル設定で管理対象の拒否設定を緩和することはできません。管理対象のネットワーク拒否設定と許可リストに限定する制限は、ブラウザーツールにも適用されます。オリジンパターンと承認の動作については、ブラウザーポリシーのフィールドを参照してください。

Computer Use は、ブラウザーをネイティブアプリとして操作することもできます。この操作経路には、Browser Use のサイトルールと機能ルールは適用されません。ネイティブアプリへのアクセスは個別に確認してください。 ブラウザーのセキュリティ境界を参照してください。

ネイティブアプリへのアクセスを設定する

  1. 要件 で、デスクトップアプリの制御 > アプリルール に移動します。
  2. デフォルト 行のアクションを使用して、一致するルールがないアプリへのアクセスを設定します。Computer Use を承認済みのアプリのみに制限するには、デフォルトでアクセスをブロックし、それらのアプリの許可ルールを追加します。
  3. アプリルールを追加 を選択します。ルールを編集 ダイアログのアプリ から、macOS バンドル ID、 Windows AUMID、またはWindows 実行可能ファイル を選択します。バンドル ID または Application User Model ID (AUMID) の正確なアプリ識別子 を入力します。Windows 実行可能ファイル の場合は、発行元名 と製品名 を入力します。バイナリ名 は任意です。表示名やファイルパスではなく、検証済みのアプリ識別情報を使用してください。
  4. ルールのアプリアクセス を設定し、ルールを追加 を選択します。デスクトップアプリの制御 にあるアプリの承認を保存 を確認し、検証メッセージを確認して、 変更を保存 を選択します。承認の保存を無効にしても、現在のセッションでの承認は可能です。承認の保存を許可しても、アプリが承認されるわけではありません。
  5. デプロイ環境内のサポート対象の各オペレーティングシステムで、許可されたアプリとブロックされたアプリをテストします。オペレーティングシステムの権限が引き続き適用され、ユーザーが必要な承認を行う必要があることを確認してください。

Windows の識別情報の要件については、Computer Use ポリシーのフィールドを参照し、管理対象の Mac についてはロック中の使用制限を参照してください。

実際に適用されるポリシーを確認する

許可されたサイトやアプリが引き続きブロックされる場合は、ほかの一致するルール、ポリシーの割り当てと優先順位、デバイス要件、ユーザー設定を確認してください。ある設定元の許可ルールで、適用対象となる別の拒否設定を回避することはできません。要件の配置場所と優先順位を参照してください。

設定が反映されない場合は、クライアント、オペレーティングシステム、ポリシーの配信経路がその設定に対応していることを確認してください。ローカルコンピューターへのアクセスを使用する Work Cloud には特に注意してください。一部のフィールドは部分的な対応にとどまるか、検証が必要です。 設定リファレンスの Work 互換性を参照してください。

ユーザーが機能や必要なプラグインにアクセスできない場合は、ワークスペースの権限と プラグインの制御を個別に確認してください。

TOML 設定リファレンス

以下の例は、requirements.toml で同じポリシーの意図を表現する方法を示しています。ファイルまたは TOML エディターでポリシーを管理する場合に使用してください。Agent Security のコントロールを使用するために、ローカルファイルを編集する必要はありません。

このブラウザーの例では、デフォルトでアクセスを拒否し、https://example.com へのアクセスを許可します。また、そのサイトでのアップロードと完全な CDP アクセスをブロックし、サイトへのアクセス承認の有効期間を現在のターンに限定します。

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

ブラウザー操作の自動レビューを無効にするには、 browser_use.disable_auto_review = true を設定します。または、オリジンポリシーに auto_review = "deny" を設定して、そのオリジンでの自動レビューを制限します。

対象となる Enterprise ワークスペースで Site tools を有効にするには、 browser_use.allow_webmcp = true を設定します。この管理対象のオプトインは、デスクトップアプリの組み込みブラウザに適用されます。false に設定するか省略すると、通常の機能提供状況のチェックが引き続き適用されます。false はブロックを強制しません。ユーザー設定とサイト権限も引き続き適用されます。

このネイティブアプリの例では、macOS の電卓を許可し、他のアプリをデフォルトで拒否します。また、アプリの承認がセッションをまたいで保持されないようにします。

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Windows ポリシーでは、computer_use.windows.aumids でパッケージアプリを、 computer_use.windows.exes で実行可能ファイルを識別できます。実行可能ファイルのルールには、 publisher_name、product_name、access が必須です。binary_name は省略可能です。

サポートされているすべてのフィールドと値については、 requirements.toml リファレンスを参照してください。個々のサイトやアプリを制限するのではなく、機能自体を無効にするには、 機能フラグを固定するを参照してください。

その他のデスクトップコントロール

以下のデスクトップコントロールでは、機能の利用可否、Locked Use、Appshots、デバイスのリモートコントロールを管理します。機能の利用可否と Locked Use には専用の設定を使用し、Appshots とデバイスのリモートコントロールは TOML として編集 で設定します。デスクトップアプリの通信先の制限については、デスクトップアプリのネットワーク接続先を制御するを参照してください。

機能フラグを固定する

Agent security で公開されているデスクトップ機能については、グローバル > 要件 > デスクトップ機能の利用可否 を開きます。アプリ内ブラウザー、ブラウザーの使用、 外部ブラウザーの使用、またはコンピューターの使用 を強制的にオフ に設定して、該当する機能を無効にしてから、変更を保存 を選択します。完全な CDP アクセス については、 ユーザーのオプトインをブロック を選択して、ユーザーが有効にできないようにします。機能を許可しても、製品、プラットフォーム、ロールアウトによる利用可否は変わりません。

その他のサポートされている機能フラグについては、 TOML として編集 とグローバルの requirements.toml ドキュメント、またはサポートされているローカルの要件ソースを使用します。以下の例には、ランタイムとデスクトップ固有の機能フラグの固定設定が含まれています。

[features]
hooks = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

実行時機能には、config.toml の [features] テーブルにある正規の機能キーを使用してください。ローカルランタイムは、認識された機能をこれらの固定値に合わせて正規化し、 config.toml またはプロファイルファイルの機能設定への競合する書き込みを拒否します。

管理対象の unified_exec = false は、コマンドの実行を引き続き可能にしながら、再開可能なプロセスと write_stdin ツールを無効にします。ユーザー設定ではこの機能を無効にできません。

  • in_app_browser = false は、組み込みブラウザーペインを無効にします。
  • in_app_updates = false は、サポートされている環境で、ChatGPT デスクトップアプリ自体のアップデーターを再起動時に無効にします。外部パッケージのデプロイには影響せず、古いアプリバージョンのサポートを延長するものでもありません。セットアップとロールアウトのガイダンスについては、 アプリの更新を管理するを参照してください。
  • browser_use = false は、サポートされている Browser Use 機能を無効にします。外部の Browser Use とネイティブアプリの Computer Use には、それぞれ別のコントロールがあります。
  • browser_use_full_cdp_access = false は、Browser Developer モードを含むローカルランタイムの完全な CDP アクセスを無効にし、ChatGPT デスクトップアプリが対応する設定を有効にできないようにします。
  • browser_use_external = false は、サポートされているブラウザー拡張機能を介した、エージェントによる Browser Use を無効にします。
  • computer_use = false は、ブラウザーをネイティブアプリとして操作することも含め、ネイティブアプリの Computer Use を無効にします。また、Record & Replay と、関連するインストールやセットアップのフローも無効にします。

Browser Use を無効にするだけでは、ブラウザーを操作するすべての経路をブロックできません。 ネイティブアプリの Computer Use は、その機能とアプリへのアクセスが許可されていれば、引き続きブラウザーを操作できます。この経路には Browser Use のサイトルールと機能ルールは適用されません。ブロックするには、コンピューターの使用 を強制的にオフ (computer_use = false) に設定するか、他のネイティブアプリを引き続き利用可能にする必要がある場合は、アプリルールでブラウザーアプリを拒否します。 外部ブラウザーの使用 とアプリ内ブラウザー は個別に確認してください。各経路に適用されるコントロールについては、ブラウザーセッションと既存のサインイン を参照してください。

これらのキーを省略した場合、通常のクライアント、プラットフォーム、ロールアウトでの提供状況を条件として、ポリシーは各機能を許可します。

ロック中のコンピューターの使用を制限する

管理対象の Mac でユーザーが Locked Use を有効にできないようにするには、 グローバル > 要件 > デスクトップアプリのコントロール を開き、 ロック中の使用を許可 を無効 に設定して、変更を保存 を選択します。この設定は、すでに Locked Use が有効になっている Mac で Locked Use をオフにするものではありません。

TOML エディターまたはデバイス管理による配信での同等の要件は、次のとおりです。

[computer_use]
allow_locked_computer_use = false

この要件により、Locked Use を有効化するためのコントロールが削除されます。すでに有効になっている場合、 Locked Use が無効になることはありません。この要件を省略した場合、通常の製品提供状況とユーザーのローカル設定が引き続き適用されます。

Appshots を無効にする

Appshots を使用すると、対応するクライアントにアプリケーションのスナップショットを含められます。クラウド管理対象のユーザーに対して無効にするには、Agent security で TOML として編集 を開き、グローバルの requirements.toml の最上位の allow_appshots フィールドを設定します。デバイス管理によるデプロイでは、該当するローカルの要件ソースを使用します。

allow_appshots = false

Appshots を利用できる環境では、allow_appshots = false によって無効化されます。キーを省略した場合、要件は Appshots を制約せず、通常の製品提供状況の確認が適用されます。configRequirements/read を介して有効な要件を読み取る App-server クライアントには、 allowAppshots と同じ制限が適用されます。allowAppshots の値が省略されているか null の場合、 Appshots は無効化されません。

デバイスのリモートコントロールを無効にする

クラウド管理対象のユーザーに対してデバイスのリモートコントロールを無効にするには、 Agent security の TOML として編集 を使用し、グローバルの requirements.toml の最上位の allow_remote_control フィールドを設定します。サポートされているローカルの要件ソースで allow_remote_control を設定することもできます。

allow_remote_control = false

デバイスのリモート制御がサポートされている環境では、allow_remote_control = false によって無効化されます。キーを省略した場合、要件はデバイスのリモート制御を制約せず、通常の製品提供状況の確認が適用されます。この要件によって SSH リモート接続が無効化されることはありません。

承認と実行権限を設定する

このセクションでは、承認の動作、権限の境界、初期のデフォルト値を設定します。まず、ポリシーのガードレールとデフォルトを確認してください。後続のタスクでは、レビュアーの強制適用、カスタム権限プロファイル、ファイルシステムの制限、ホストのオーバーライド、コマンドルールに関する TOML 要件を説明します。

管理者が強制適用する要件 (requirements.toml)

要件は、セキュリティに関わる設定（承認ポリシー、承認レビュー担当、自動レビューポリシー、サンドボックスモード、権限プロファイル、Web 検索モード、マネージドフック、ユーザーが有効にできる MCP server、利用できるプラグインマーケットプレイスのソース）を制限します。設定を解決する際（たとえば、config.toml、プロファイルファイル、CLI による設定の上書きなどから）、値が強制ルールと競合すると、ローカルクライアントはルールに適合する値にフォールバックし、ユーザーに通知します。mcp_servers の許可リストを設定した場合、クライアントは MCP serverの名前と識別情報の両方が承認済みのエントリと一致する場合にのみ、そのサーバーを有効にします。一致しない場合は無効にします。

要件では、requirements.toml の [features] テーブルを介して機能フラグを制約することもできます。機能は必ずしもセキュリティ上重要とは限りませんが、企業は必要に応じて値を固定できます。省略したキーは制約されません。

Codex 0.138.0 以降では、allowed_permission_profiles と管理対象の default_permissions を使用する権限プロファイルを推奨します。引き続き sandbox_mode を構成している従来のデプロイでのみ、 allowed_sandbox_modes を使用してください。

正確なキーの一覧については、構成リファレンスの requirements.toml セクションを参照してください。

承認、サンドボックス、ウェブ検索のガードレールを設定する

要件 > ポリシーのガードレール を使用して、サポートされているクライアントの選択肢を制限します。これらのコントロールは設定を制約するもので、初期値を選択するものではありません。初期値は、デフォルト で別途設定してください。

  1. グローバル で承認ポリシー を開き、許可する承認方式を選択します。たとえば、必要に応じて確認 では、エージェントがサンドボックスの権限昇格などの操作について承認をリクエストできます。確認しない では承認リクエストが禁止されますが、無制限の実行が許可されるわけではありません。
  2. サンドボックスモード を開き、従来のサンドボックスの選択肢を制限します。読み取り専用 は書き込みを制限し、ワークスペースへの書き込み はワークスペースと設定済みの書き込み可能なルート内での書き込みを許可します。フルアクセス はファイルシステムのサンドボックスを解除します。 sandbox_modeの代わりに権限プロファイルを使用するデプロイでは、権限プロファイルの要件を使用してください。
  3. グローバル でウェブ検索モード を開き、ウェブ検索を制限します。キャッシュ を選択すると、ライブ検索を許可せずにキャッシュ検索を許可できます。無効 を選択すると、ウェブ検索を無効にできます。ウェブ検索の制限は、コマンドのネットワークルールとは別です。
  4. 許可する選択肢と対応するデフォルト値を確認し、 変更を保存 を選択します。

要件を未設定のままにすると、そのポリシーによる制限は課されません。ほかの適用対象のポリシーは引き続き適用されます。信頼されていないコマンドで確認 オプションは、要件の許可リスト内のuntrustedに対応します。廃止された approval_policy = "untrusted"の明示的な設定を復活させるものではありません。その場合は、以下の移行ガイダンスに従ってください。

ウェブ検索を制限するには、グローバル > 要件 > ポリシーのガードレール > ウェブ検索モード を使用します。対応するTOMLは次のとおりです。

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] では "disabled" のみが許可されます。たとえば、allowed_web_search_modes = ["cached"] は danger-full-access セッションでもライブ Web 検索を防止します。

設定のデフォルト値を指定する

デフォルト値は、メンバーに初期設定を提供します。制限を強制したり、ワークスペースの機能へのアクセスを付与したりするものではありません。

  1. ポリシーのデフォルト カードを開きます。エージェント全体のデフォルト値はグローバル に設定し、サポートされている実行設定のデフォルト値には、利用可能な環境タブを使用します。
  2. コマンド実行 で、初期値となる承認ポリシー と 承認レビュアー、および適用するサンドボックスモード またはデフォルトの権限 を選択します。レビュアーは、デフォルトで誰が承認リクエストをレビューするかを決定します。承認ポリシーは、リクエストが発生し得るタイミングを決定します。
  3. ウェブ検索 で、初期値となるウェブ検索 モードとウェブ検索コンテキスト を選択します。アプリとツール で、サポートされているアプリツールのアプリ/コネクター、オープンワールドツール、破壊的ツール を確認します。
  4. デフォルト値が要件 を満たしていることを確認し、変更を保存 を選択します。

プラグインマーケットプレイスの設定など、画面上に設定項目がない、サポート対象のデフォルト値には、TOML として編集 を使用します。これらのクラウドのデフォルト値には、通常の設定の優先順位が適用されます。これは、起動時に管理対象のデフォルト値をローカル設定より優先する従来のmanaged_config.tomlの優先順位とは、異なります。

requirements.toml の例

次の例では、--ask-for-approval never と --sandbox danger-full-access（--yolo を含む）をブロックします。

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

ここで、untrustedは、より厳格な承認動作を維持します。この動作は trust_level = "untrusted"から導かれるものであり、approval_policy = "untrusted"が明示的な設定としてサポートされるようになるわけではありません。

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

Codex と ChatGPT Work は、approval_policy = "untrusted" をサポートしなくなりました。マネージドデフォルト設定、従来の managed_config.toml、およびこの値が設定されているすべてのユーザー設定、プロジェクト設定、プロファイル設定、起動設定から削除してください。

対話型の読み取り専用の用途では、approval_policy = "on-request"と、管理要件で許可された読み取り専用のサンドボックスまたは権限プロファイルを選択します。そのサンドボックスで許可されたコマンドは、承認なしで実行できます。

より厳格なコマンド承認を維持するには、approval_policyを明示的に指定せず、 trust_level = "untrusted"をユーザーレベルの設定にあるプロジェクトのエントリで設定します。設定先は~/.codex/config.tomlで、untrustedはallowed_approval_policiesに残します。これにより、プロジェクトローカルの設定も無効になります。on-requestを明示的に設定すると、このポリシーが上書きされます。具体例とセキュリティ上のトレードオフについては、 廃止されたuntrusted承認ポリシーからの移行 を参照してください。

自動レビューポリシーを構成する

自動レビューをデフォルトにするには、グローバル > デフォルト > コマンド実行 > 承認レビュアー を使用します。デフォルトの設定では、ユーザーは許可されている別のレビュアーを選択できます。自動レビューを必須にする場合や、組織のレビュー指示を指定する場合は、TOML として編集 を使用し、グローバルの requirements.tomlを編集してください。これらの要件は、ブラウザーの自動レビューの制御とは別です。

自動レビューを必須または許可するには、allowed_approvals_reviewers を使用します。自動レビューを必須にするには ["auto_review"] に設定し、ユーザーが手動承認を選択できるようにするには "user" を含めます。

自動レビューポリシーのテナント固有セクションを置き換えるには、 guardian_policy_config を設定します。ローカルランタイムは引き続き、組み込みのレビュー担当テンプレートと出力規約を使用します。管理対象の guardian_policy_config は、ローカルの [auto_review].policy より優先されます。

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

利用可能な権限プロファイルを制御する

デフォルト > コマンド実行 > デフォルトの権限 で、ユーザーが最初に使用する組み込みプロファイルを選択します。ユーザーが選択できるプロファイルを制限する場合や、カスタムプロファイルを定義する場合は、TOML として編集 を使用し、requirements.tomlを該当するグローバルまたはサポート対象の実行環境のスコープで設定します。デフォルトを選択するだけでは、利用可能なプロファイルは制限されません。

ユーザーが選択できる組み込みおよびカスタムの権限プロファイルを制御するには、allowed_permission_profiles を使用します。これは allowed_sandbox_modes に対応する権限プロファイル用の設定です。ユーザーが権限を選択する方法に合った許可リストを使用してください。

権限プロファイルの許可リストには Codex 0.138.0 以降が必要です。Codex 0.137.0 以前では、allowed_permission_profiles と管理対象の default_permissions は無視されます。

以下の権限プロファイルの例は、管理対象のすべてのクライアントが対応リリースを実行している場合にのみ使用してください。全体のアップグレードが完了するまで、管理対象のカスタムプロファイルをデプロイしないでください。

このテーブルが存在する場合、それが許可されるプロファイルの完全な一覧になります。 true に設定されたプロファイルを許可し、省略されたプロファイルまたは false に設定されたプロファイルを拒否します。これには、将来の Codex バージョンで追加される組み込みプロファイルも含まれます。

標準プロファイルを許可する

次のポリシーでは、読み取り専用アクセスとワークスペースアクセスは許可しますが、フルアクセスは許可しません。

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

管理対象の最小権限デフォルトを追加する

管理者は、同じ要件ソース内にカスタムプロファイルを定義できます。ユーザーが読み込んだ構成内の名前と競合しない、組織固有のプロファイル名を使用してください。カスタム名の先頭に : を付けることや、予約済みの filesystem という名前を使用することはできません。

Codex 0.137.0 以前を実行しているクライアントには、管理対象のカスタムプロファイルをデプロイしないでください。これらのクライアントはプロファイルテーブルを認識しますが、それを選択する管理対象のデフォルトは認識しません。

例：

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

企業が定義したプロファイルのみを許可する

ユーザーが管理者定義のプロファイルのみを選択すべき場合は、すべての組み込みプロファイルを省略します。

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

ユーザーが組み込みの :workspace プロファイルを直接選択できない場合でも、カスタムプロファイルは :workspace を拡張できます。

別のソースで許可されたプロファイルを無効化する

権限の許可リストは、プロファイル名ごとに結合されます。クラウド要件はシステム要件より優先順位が高いため、クラウド要件では false を使用して、システムファイルで許可されているプロファイルを無効化できます。

クラウド要件：

default_permissions = ":read-only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = false

システム要件：

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

default_permissions には、許可されるプロファイルを明示的に設定してください。省略した場合、ローカルランタイムは :workspace と :read-only の両方が明示的に許可されているときにのみ、デフォルトで :workspace を使用します。allowed_permission_profiles が存在しない場合、管理対象の要件は、ユーザーが選択できるプロファイル名を制限しません。各エントリには、組み込みプロファイル、または読み込まれた構成や要件ソースで定義されているカスタムプロファイルを指定する必要があります。動作を一元的に制御するには、管理対象の要件でカスタムプロファイルを定義してください。

読み取り拒否要件を適用する

TOML として編集 を使用し、該当するグローバルまたはサポート対象の実行環境のrequirements.tomlにファイルシステムの制限を追加します。これらの制限は、機密性の高いパスの読み取りをブロックします。デフォルトを読み取り専用にするだけでは、ファイルは非表示になりません。

管理者は、[permissions.filesystem] を使用して、完全一致のパスまたは glob パターンに対する読み取りを拒否できます。ユーザーがローカル構成でこれらの要件を緩和することはできません。

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

読み取り拒否要件が存在する場合、ローカルランタイムはフルアクセス権限を拒否し、要件を適用できるように、ローカル実行を読み取り専用またはワークスペースのサンドボックス内に維持します。ネイティブ Windows では、管理対象の deny_read は直接ファイルを扱うツールに適用されます。シェルのサブプロセスによる読み取りには、このサンドボックスルールは適用されません。

ホストごとにサンドボックス要件を上書きする

エージェントのセキュリティでTOML として編集 を使用し、ホスト固有の要件を作成します。環境の制御では実行環境を選択し、ホストパターンではサポート対象のランタイム内で一致するマシンを選択します。

1 つの管理対象ポリシーでホストごとに異なるサンドボックス要件を適用する場合は、 [[remote_sandbox_config]] を使用します。たとえば、ノート PC にはより厳格なデフォルトを維持しつつ、一致する開発用マシンや CI ランナーではワークスペースへの書き込みを許可できます。現在、ホスト固有のエントリで上書きされるのは allowed_sandbox_modes のみです。

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

ローカルランタイムは、各 hostname_patterns エントリを、ベストエフォートで解決されたホスト名と比較します。利用可能な場合は完全修飾ドメイン名を優先し、利用できない場合はローカルホスト名にフォールバックします。照合では大文字と小文字を区別しません。 * は任意の文字列に一致し、? は 1 文字に一致します。

同じ要件ソース内では、最初に一致した [[remote_sandbox_config]] エントリが優先されます。一致するエントリがない場合、ローカルランタイムはトップレベルの allowed_sandbox_modes を維持します。ホスト名の照合はポリシー選択のみを目的としています。認証済みデバイスの証明として扱わないでください。

要件からコマンドルールを適用する

エージェントのセキュリティでTOML として編集 を使用し、コマンドルールとMCP serverの制限をグローバルのrequirements.tomlに追加します。コマンドルールは、一致するコマンドに対する承認または拒否の判断を指定します。MCPの制限は、クライアントが有効にできるサーバーの識別情報を制限します。承認ポリシー の設定では、これらのルールセットのいずれも作成できません。

管理者は、[rules] テーブルを使用して、requirements.toml から制限的なコマンドルールを適用することもできます。これらのルールは通常の .rules ファイルとマージされ、最も制限の厳しい決定が引き続き優先されます。

.rules とは異なり、要件のルールでは decision を指定する必要があり、その決定は "prompt" または "forbidden"（"allow" ではありません）である必要があります。

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

ローカルクライアントが有効化できる MCP serverを制限するには、mcp_servers 承認済みリストを追加します。stdio サーバーでは command を照合し、ストリーム対応 HTTP サーバーでは url を照合します。

[mcp_servers.docs]
identity = { command = "codex-mcp" }

[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

identity.command の文字列形式は、構成済みの command のみに一致します。 args、cwd、env、env_vars は検査しません。

stdio 呼び出し全体を制約するには、実行可能ファイルと各位置引数を照合します。

[mcp_servers.internal.identity]
command = { executable = "/usr/local/bin/codex-mcp", args = [
  { match = "exact", value = "serve" },
  { match = "prefix", value = "--workspace=" },
] }

実行可能ファイル、引数の数、引数の順序が一致する必要があります。引数と URL のルールは、exact、prefix、値全体に対する regex の照合をサポートします。構造化されたコマンドルールでも、cwd、env、env_vars は検査されません。プラグインに同梱された MCP serverは、plugins.<plugin>.mcp_servers.<server> の下で同じ ID 形式を使用します。

mcp_servers が存在していて空の場合、ローカルクライアントはすべての MCP serverを無効化します。

ネットワークアクセスを設定する

コマンドのネットワーク通信とデスクトップアプリのネットワーク通信では、異なる制御を使用します。まずネットワーク使用の制御 でサポート対象のコマンド通信を設定し、環境とランタイムの制限を確認してから、必要に応じてデスクトップアプリ専用の要件を使用してください。ブラウザーのサイトルールは、引き続きブラウザーとComputer Useを制御するで設定します。

ネットワークアクセス要件を構成する

エージェントのセキュリティで要件 > ネットワーク使用の制御 を使用し、サポート対象のコマンドのネットワーク通信を管理します。共通の基本設定はグローバル で、環境固有の実行設定は、利用可能なローカル環境 またはCodex Cloud環境 タブで設定します。

  1. マネージドネットワーク をオン にすると、管理対象のコマンドの通信にドメインルールが適用されます。ドメインルールを追加するだけでは、マネージドプロキシは有効になりません。
  2. ネットワークルール でネットワークルールを追加 を選択します。ドメイン には、 api.openai.comや**.example.comなどを、URL スキームやパスを含めずに入力します。 アクセス で許可 または拒否 を選択し、ルールを保存 を選択して下書きを更新します。他の接続先についても同じ操作を繰り返します。
  3. ユーザー設定やドメインごとの承認によって管理対象の許可リストを拡張できないようにするには、 管理者が追加したドメインのみを許可 をオン にします。必要な許可エントリを含めてください。拒否のみのリストでは、他の接続先は許可されません。
  4. ローカルリスナーやプライベートな接続先を必要とするワークフローでは、ローカルネットワークアクセスを許可 を確認します。ローカルへの直接接続は、プロキシのドメインルールを迂回する場合があります。この設定を変更する前に、以下の Codex Cloud の接続制限を確認してください。
  5. 継承されたルールと検証メッセージを確認し、変更を保存 を選択します。影響を受けるすべての実行環境で、成功するはずのリクエストとブロックされるはずのリクエストをテストしてください。

マネージドネットワーク をオフ にすると、そのスコープで作成されたネットワークルールが消去され、明示的なオフの値が保存されます。インターネットアクセスが無効になるわけではありません。 未設定 にすると、そのスコープで作成されたネットワーク設定が削除され、該当するポリシーまたはランタイムのデフォルトを適用できるようになります。環境設定を削除すると、継承された Global のルールが適用される場合があります。高度なネットワークフィールドや、ビジュアルエディターで表現できない既存のレガシードメインリストには、TOML として編集 を使用してください。

管理者がネットワークアクセス要件を一元的に定義する必要がある場合は、 requirements.toml で [experimental_network] を使用します。これらの要件は、ユーザーの features.network_proxy 切り替えとは別のものです。その機能フラグがなくてもサンドボックスのネットワーク設定を構成できますが、アクティブなサンドボックスでネットワークが無効になっている場合、コマンドにネットワークアクセス権を付与することはありません。管理対象プロキシを有効にするには、 experimental_network.enabled = true を設定してください。ドメインルールだけではプロキシは有効になりません。

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

experimental_network.managed_allowed_domains_only = true は、[experimental_network.domains] に管理者が管理する "allow" エントリも定義し、それらのルールを排他的にする場合にのみ使用してください。管理対象の許可ルールがない状態で true にすると、ユーザーが追加したドメイン許可ルールは有効なままになりません。正規の domains マップを、従来の allowed_domains または denied_domains リストと組み合わせないでください。

*.example.com はサブドメインのみに一致します。**.example.com はルートドメインとそのサブドメインに一致します。一致する拒否ルールは、許可ルールより優先されます。

ドメインの構文、ローカル／プライベート宛先のルール、拒否が許可より優先される動作、 DNS リバインディングの制限は、エージェントの承認とセキュリティで説明されているサンドボックスのネットワーク動作と同じです。

プロキシは、サンドボックス内で実行されるローカルコマンドの通信をルーティングします。ブラウザーツールもオリジンにアクセスする前に、管理対象ネットワークの拒否ルールと、アクセス先を限定する許可リストを確認します。これは独立したポリシーチェックであり、ブラウザーのトラフィックをコマンドプロキシ経由でルーティングするものではありません。このプロキシは、ウェブ検索、アプリとコネクター、MCP server、ネイティブアプリのトラフィック、Codex サービスへのリクエスト、その他の機能固有のトラフィックをフィルタリングしません。それぞれに対応する制御を使用してください。

  • allowed_web_search_modes を使用してウェブ検索を制限します。
  • features.apps = false を使用してアプリとコネクターの連携を無効にし、 features.plugins = false を使用して、サポートされる環境でプラグインを無効にします。
  • 管理対象の mcp_servers 承認済みリストを使用して MCP serverを制限します。
  • browser_use、in_app_browser、 computer_use などの機能要件を使用して、ブラウザーとコンピューター操作の機能を制限します。
  • サポートされる管理対象の Codex Cloud コマンドでは、Agent Security の要件と Cloud 環境のインターネット設定を個別に設定してください。

コマンドドメインの許可リストは、これらの機能固有の制御に代わるものではありません。

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

管理対象のコマンド許可リストは、管理対象プロキシを使用するコマンドに適用されます。ポリシーがサンドボックスの制限を全面的に解除する権限昇格を許可し、それが承認された場合、その実行はコマンドプロキシを迂回できます。限定的なネットワークアクセスの許可は、サンドボックスの制限を全面的に解除する権限昇格とは異なります。意図した境界に合わせて、強制適用する承認とサンドボックスの要件を設定し、通常のコマンドと権限昇格したコマンドの両方をテストしてください。

有効な許可先がない場合： マネージドネットワーク と管理者が追加したドメインのみを許可 がオンの場合、通常の管理対象コマンドには有効な許可先が必要です。許可エントリが設定も継承もされていない場合、それらのコマンドに許可される接続先はありません。拒否のみのポリシーでは、それ以外のインターネット接続先が暗黙的に許可されることはありません。保存する前に、必要な許可エントリを追加し、継承されたルールを確認してください。この制限は管理対象コマンドのプロキシに適用されるもので、すべてのツールや、承認済みのサンドボックス全体の権限昇格に適用されるものではありません。

Codex Cloud のローカル／プライベート接続: ローカル／プライベート接続を明示的に Off にすると、接続先ドメインが許可されていても、Codex Cloud が上流プロキシに接続できなくなることがあります。最終的な allow_local_binding の値を確認し、その値の設定元となるポリシーや設定を特定してください。サポート対象の Cloud プロキシ経路では、適用される要件、選択されたネットワークプロファイル、プロキシ機能の設定のいずれにも値が指定されていない場合に限り、デフォルト値が true になります。継承された false も明示的な設定として扱われます。サポートされている場合は、優先順位の高い Cloud オーバーライドを設定することで、Local が使用する Global の値を変更せずに、Codex Cloud のこの値を変更できます。この操作でドメインの Allow エントリが追加されることはありません。オーバーライドを利用する前に、実行環境が対応していることを確認してください。この Cloud のデフォルト値を Local に適用しないでください。

環境の要件が空の場合、Global の要件が適用されます。マネージドネットワーク の オフ 設定は、Cloud 環境のインターネットアクセス設定とは別です。実行スコープの詳細については、Agent Security の実行制御を参照してください。

ネットワークポリシーの優先順位とランタイムの制限

同一ポリシー内の優先順位は、高い順に OS 固有の環境オーバーライド → 全 OS 共通の環境オーバーライド → Global です。優先順位の低いポリシーのほうが具体的な場合でも、優先順位の高いポリシーが優先されます。一部の要件には、フィールド固有のマージ規則があります。その結果として確定した要件をランタイムが適用します。以下のフィールド固有のネットワークのケースは、ポリシーの優先順位とは分けて考えてください。

以下の例では、管理対象ネットワークがすでに設定されており、より優先順位の高いポリシーによって値が変更されないことを前提に、同一ポリシー内の環境設定と Global 設定を比較します。フィールド固有のマージとランタイムの動作を説明します。

環境ごとに異なるドメインアクセスを設定する

ポリシー内の同じドメインルールについて、管理者による環境オーバーライドを使用すると、Global で拒否されているドメインを許可したり、Global で許可されているドメインを拒否したりできます。環境オーバーライドがない場合は、Global のルールを継承します。ただし、ほかの有効な Deny ルールやアクセス制御によって、リクエストがブロックされる場合があります。

ドメインルールの組み合わせ方

Global のルール 環境のルール ドメインポリシーの適用結果
Deny Allow 以下の条件に従い、環境オーバーライドによって許可されます。
Allow Deny その環境ではブロックされます。
Allow Allow これらのドメインルールによって許可されます。
Deny Deny これらのドメインルールによってブロックされます。
Allow または Deny オーバーライドなし Global のルールを継承します。

これらの結果は、より優先順位の高いポリシーによって結果が変更されないことを前提に、1 つのポリシー内で同じドメインキーを比較したものです。優先順位の高い値が同じキーの値を置き換えます。継承したほかのキーは残ります。Allow は、継承したワイルドカードなど、別の一致する Deny を回避しません。空の環境マップを指定しても、継承したルールは消去されません。

例: Global で packages.example.com を拒否し、Development で許可します。Development では、上記の条件のもとでアクセスを許可できます。Production は、オーバーライドされない限り Global の Deny を継承します。

デプロイした実行環境がこれらのマージ規則をサポートしていることを確認してください。通常の管理対象実行環境での対応範囲については、引き続き検証が必要です。

オーケストレーターの制限。クラウドランタイムは、管理対象の HTTP/SOCKS リスナーポートと非ループバックのプロキシリスナーをサポートしていません。ソケットルールのサポートは実行経路によって異なります。以下の表にあるローカル実行用の設定は、オーケストレーターでサポートされる構成ではありません。

その他のネットワークランタイムの制限

以下のフィールド名はすべて、experimental_network 配下にあり、requirements.toml 内で指定します。矢印の前後は、同一ポリシー内の Global の値と環境の値を順に示します。これらのローカル実行のケースは、オーケストレーターが同じ設定をサポートしていることを示すものではありません。

設定と試みるオーバーライド ランタイムの動作 管理者の対応
domains: deny → allow サポートされる経路では、環境の Allow が Global の同じドメインキーの値を置き換えます。ほかの一致する Deny ルールは引き続き適用されます。 デプロイした実行環境で、許可されるリクエストとブロックされるリクエストの両方をテストしてください。
managed_allowed_domains_only: true → false ドメインキーの組み合わせ方から、許可先を限定する動作を推測しないでください。enabled = true と managed_allowed_domains_only = true が実効設定の場合、通常のコマンドには有効な Allow エントリが必要です。 実効設定と継承した Allow エントリを確認してください。拒否のみのポリシーでは、それ以外のインターネットへのアクセスは許可されません。
allow_local_binding: false → true サポートされる Codex Cloud のプロキシ経路では、明示的な false によって上流プロキシへのアクセスが妨げられる場合があります。サポートされる、より優先順位の高い Cloud オーバーライドで変更できます。 実効値の設定元と実行環境のサポート状況を確認してください。Cloud のデフォルト値を Local に適用しないでください。

プロキシの有効化、許可先の限定、上流プロキシの動作、Unix ソケットのルールは、実行環境ごとに動作が異なります。ドメインキーの組み合わせ方をこれらの設定に一般化しないでください。実効値を確認し、デプロイしたランタイムでテストしてください。Codex Cloud のローカル／プライベート接続については、ネットワークアクセス要件の設定を参照してください。

ロールアウト前に動作を検証する

ワークフローで使用する実際の接続先、ローカルリスナー、プロキシの動作、ソケットパスをテストしてください。影響を受ける各環境で、成功するはずの操作とブロックされるはずの操作を確認してください。デプロイしたランタイムのバージョンが、使用する各設定をサポートしていることを確認してください。

デスクトップアプリのネットワーク接続先を制御する

Agent security のTOML として編集 を使用して、これらのデスクトップ固有の要件を Global で設定します。ネットワーク使用制御 の UI はコマンドのネットワーク通信を管理します。これは別のポリシーです。

[application.network] を requirements.toml 内で使用して、デスクトップアプリのネットワーク接続先を制限します。enabled = true の場合、外部リクエストでは HTTPS または WSS を使用し、値が "allow" に設定されたドメインと完全に一致する必要があります。このドメインは [application.network.domains] で指定します。サブドメインは暗黙的には許可されません。ドメインマップが空の場合、外部の接続先は一切許可されません。サポートされるキーについては、構成リファレンスを参照してください。

このポリシーは、コマンドのネットワーク設定やブラウザーのオリジンルールとは別のものです。ネイティブモジュールや起動されたプロセスの接続先は制限せず、 Work Cloud の実行も制御しません。

プラグインと管理対象フックを設定する

これらのタスクには、Agent security のTOML として編集、またはサポートされているローカルの設定ソースを使用します。マーケットプレイスのデフォルト、強制適用されるプラグイン制限、管理対象フックは、それぞれ目的が異なります。必要なポリシーに合ったタスクを選択してください。

プラグインマーケットプレイスとデフォルトを設定する

エージェントのセキュリティ > TOML として編集 を使用して、ローカルまたは Git のマーケットプレイスとプラグインのデフォルトを、Global の config.toml ドキュメントで定義します。また、これらの設定をシステムの config.toml で配布することもできます。これらはマーケットプレイスとプラグインの初期設定を提供するもので、強制適用されるポリシーではありません。メンバーが使用できるソースを制限するには、マーケットプレイスソースの要件を設定してください。

設定キーについては設定リファレンスを、上書きについては設定の優先順位を、プロジェクト単位の設定についてはリポジトリのプラグイン設定を参照してください。ワークスペースの GitHub インポートと同期は別の機能です。

プラグインの利用可否を制御する

Agent security のTOML として編集 を使用して、Global の requirements.toml で強制適用するプラグイン機能の設定を行うか、デバイス管理対象のクライアント向けにローカル要件を通じて配布します。 デフォルト > アプリとツール > アプリ/コネクター は、アプリツールのデフォルトを設定するもので、強制適用される features.plugins スイッチではありません。ワークスペースのプラグイン権限については、アプリとコネクターを参照してください。

サポート対象のローカルクライアントでプラグインを無効化するには、requirements.toml で features.plugins を false に設定します。

features.plugins = false

この設定は、ユーザーが API key で Codex にサインインする場合にも適用されます。サポートされる構成については、features.plugins リファレンスを参照してください。

プラグインマーケットプレイスのソースを制限する

TOML として編集 を使用して、Global の requirements.tomlでマーケットプレイスのソース要件を設定するか、ローカル要件として配信します。これらのルールは、ユーザーが追加して使用できるローカルソースや Git ソースを制限します。これらは マーケットプレイスのデフォルト設定とは別のものです。

プラグインマーケットプレイスのソースを制限するには、 restrict_to_allowed_sources = trueを設定し、1つ以上のソースルールを定義します。

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Git ルールは、正規化されたリポジトリ URL と、存在する場合は完全一致する ref を照合します。ホストパターンは、小文字化された Git ホストに対して照合される正規表現です。ホスト全体との照合には ^ と $ を使用します。ローカルルールには、絶対パスとして正規化されたパスが必要です。完全なスキーマとマージ動作については、requirements.toml リファレンスを参照してください。

これらの要件は、ルールに一致しないマーケットプレイスの追加、プラグインのインストール、設定済みGitマーケットプレイスの更新操作を拒否します。また、実行時には設定済みのマーケットプレイスとそのプラグインもフィルタリングします。

API keyカタログを含むOpenAIが厳選したGitマーケットプレイスも、ソース許可リストに一致する必要があります。これらを許可するには、次のGitソースを refの制約なしで含めます。

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

厳選されたカタログを除外するには、そのソースを省略し、より広範なホストルールでも許可されていないことを確認します。同梱プラグインとリモートでインストールされたワークスペースのプラグインは、この厳選されたGitソースに関するポリシーとは別に扱われます。

これらのソース制限は、ローカルクライアントがプラグインマーケットプレイス操作をサポートする環境、つまりデスクトップアプリの ChatGPT と Codex、および Codex CLI にのみ適用されます。 Web 版やモバイル版の ChatGPT でのプラグイン利用を制御するものではなく、 IDE 拡張機能にプラグインを追加するものでもありません。

要件から管理対象フックを適用する

管理対象フックは、対応するタスクイベントやツールイベントで、管理者が定義したアクションを実行します。Agent Security の TOML として編集 を使用して、Global の requirements.tomlで設定します。設定画面には専用のフックエディターはありません。実行できるフックの種類は、以下の実行経路によって決まります。

管理対象ポリシーとリモートフックが有効な場合、ローカルアクセスを備えた Work Cloud と dots は、クラウドオーケストレーター上で管理者が管理するリモート MCP フックを使用します。Global の requirements.toml に mcp_tool ハンドラーを設定してください。ローカルアクセスのない Work Cloud と個人アカウントでは、これらの Enterprise フックは使用されません。コマンド／シェル、プロンプト、エージェントの各ハンドラー、ローカル設定・プラグイン・ローカルディレクトリのフック、環境単位のフック、および SessionEnd MCP フックは、ツールがローカルで実行される場合でも、クラウドオーケストレーションではサポートされません。オーケストレーションと実行がどちらもローカルで行われる場合、既存のサポート対象フックは、ローカルのみの Work および Codex スレッドで引き続き動作します。管理者は、これらのワークフローに対応する管理対象フックを Agent Security で引き続き設定できます。

これらのフックを利用する前に、コールバックの接続性、必要なイベント、失敗時の動作をテストしてください。サポートされている明示的な拒否によってアクションをブロックできますが、PreToolUse コールバックのエラー、タイムアウト、不正な形式のレスポンスでは、ツールをブロックせずにフックだけが失敗する場合があります。MCP フックでは、完全な Compliance API 監査証跡は得られません。以下のスクリプトとディレクトリの例は、引き続き Codex を対象としています。

管理者は、requirements.toml で管理対象のライフサイクルフックを直接定義することもできます。フック構成自体には [hooks] を使用し、参照先のスクリプトを MDM またはエンドポイント管理ツールがインストールするディレクトリを managed_dir に指定します。

ローカルでフックを無効にしているユーザーにも管理対象フックを適用するには、 [hooks] とともに [features].hooks = true を固定します。管理対象フックは引き続き許可しながら、ユーザー、プロジェクト、セッション、プラグインのフックをスキップするには、allow_managed_hooks_only = true を設定します。

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

注意事項：

  • ローカルランタイムは requirements.toml のフック構成を適用しますが、 managed_dir 内のスクリプトは配布しません。
  • これらのスクリプトは、MDM またはデバイス管理ソリューションで配布してください。
  • 管理対象フックのコマンドでは、構成済みの管理対象ディレクトリ配下にあるスクリプトの絶対パスを参照してください。
  • allow_managed_hooks_only = true は、ユーザー、プロジェクト、セッション、プラグインの各ソースからのフックをスキップしますが、requirements.toml および他の管理対象構成レイヤーからのフックは引き続き読み込みます。

ポリシーの適用範囲と優先順位を理解する

このセクションでは、ポリシーの適用先、要件の組み合わせ方、クライアントがクラウド管理設定を受け取る仕組み、および結果の検証方法を確認できます。

ローカルアクセスを使用する Work と dots では、管理対象ポリシーが有効な場合、サポートされている Global ポリシーが共有クラウドオーケストレーターを制御し、適用対象のローカル実行要件が接続されたコンピューターを制御します。Work のクラウドコンテナーでは既存の Work Cloud ポリシーが維持され、サポートされているデバイス制御も引き続きローカル実行に適用されます。Codex の設定動作は従来どおりです。管理対象設定では、ワークスペースのシートや機能へのアクセス権は付与されません。これらの制御については、ロールとワークスペースの権限を参照してください。

Agent Security と Work Cloud のローカルコンピューターアクセス

Admin Console の Agent Security を使用して、ポリシーと設定を管理します。これは Policies & Configuration に代わるものです。Agent Security は、Work Cloud のローカルコンピューターアクセスとは独立して、Admin Console で利用できます。既存のポリシー、割り当て、順序は維持されます。Agent Security で既存のポリシーを確認してください。Work Cloud のローカルコンピューターアクセスは、別途有効化するオプトイン機能です。移行のガイダンスについては、Agent Securityを参照してください。

ポリシーの自動化を Agent Security に移行する前に、次の手順を実施してください。

  1. 影響を受ける連携を特定します。ポリシーを更新する Terraform の設定とスクリプトを洗い出し、それぞれが管理するポリシーを記録してください。

  2. Global の設定はポリシー API で管理します。Local または Codex Cloud の設定を管理するには、Agent Security の UI を使用してください。既存の Global API ワークフローは、移行後も引き続き利用できます。スクリプトと Terraform の連携をテストし、ポリシーの割り当てと順序が変わっていないことを確認してください。

  3. 必要な変更を加え、自動化をテストします。意図した更新が正しい Agent Security ポリシーに反映され、更新後の制御が強制的に適用されることを確認してください。

ポリシーを移行しても、Work や dots にローカルコンピューターへのアクセス権は付与されません。展開前にポリシーを確認または作成することをお勧めしますが、アクセスを有効にする確認フローではポリシーの作成は必須ではありません。ローカルコンピューターへのアクセスを許可 を有効にする前に、移行されたベースラインを確認してください。現在ポリシーを MDM 経由でのみ配信している場合は、クラウドのベースラインを作成してください。いずれかのクラウドポリシーで enforce_residency が有効になっている場合、Work と dots の両方でローカルコンピューターへのアクセスを許可 が無効になります。この保護措置は、ワークスペースのデータレジデンシーを設定するものではなく、それ自体で Work Cloud や dots を無効にするものでもありません。

環境別の上書き設定を使用すると、ポリシー内のサポート対象の設定を環境ごとに変更できます。同じポリシー内での優先順位は、高い順に OS 固有の環境別上書き設定 → 全 OS 共通の環境別上書き設定 → Global です。優先順位の低いポリシーのほうが具体的であっても、優先順位の高いポリシーが優先されます。一部の要件には、フィールド固有のマージルールがあります。ワークスペースで利用できる上書き設定エディターとフィールドを確認してください。

管理対象ポリシーとリモートフックが有効な場合、ローカルアクセスを使用する Work Cloud と dots は、クラウドオーケストレーター上で管理者が管理するリモート MCP フックを使用します。mcp_tool ハンドラーを Global の requirements.toml で設定してください。ローカルアクセスを使用しない Work Cloud と個人アカウントは、これらの企業向けフックを使用しません。クラウドオーケストレーションでは、ツールがローカルで実行される場合でも、コマンド/シェル、プロンプト、エージェントの各ハンドラー、ローカル設定・プラグイン・ローカルディレクトリ由来のフック、環境をスコープとするフック、SessionEnd MCP フックはサポートされません。オーケストレーションと実行の両方がローカルで行われる場合、ローカルのみで動作する Work と Codex のスレッドでは、既存のサポート対象フックが引き続き動作します。管理者は、これらのワークフローに対して、サポートされている管理対象フックを引き続き Agent Security で設定できます。これらのフックを運用で利用する前に、コールバックの接続性、必要なイベント、失敗時の動作をテストしてください。サポートされている明示的な拒否によってアクションをブロックできますが、PreToolUse コールバックのエラー、タイムアウト、不正な形式の応答では、ツールをブロックせずにフックだけが失敗する場合があります。MCP フックは、完全な Compliance API の監査証跡を提供するものではありません。設定リファレンスを参照してください。

場所と優先順位

ローカル実行では、要件は次の優先順位の低いものから高いものへと順に適用されます。この順序は、Work Cloud によるローカルコンピューターへのアクセスで実行されるローカルのステップにも適用されます。

  1. システムの requirements.toml（Unix システムでは /etc/codex/requirements.toml、 Linux と macOS もこれに含まれます。または %ProgramData%\OpenAI\Codex\requirements.toml （Windows の場合））。
  2. クラウド設定バンドルで配信される Agent Security の要件。
  3. ローカルクライアントが要件として再解釈する、従来の managed_config.toml のフィールド。
  4. 次のキーを通じて配信される macOS の管理対象環境設定（MDM）: com.openai.codex:requirements_toml_base64。

優先順位の高いレイヤーは、優先順位の低いレイヤーにある通常のスカラー値とリスト値を上書きします。テーブルはキーごとにマージされますが、ルール、フック、ファイルシステム制限などの要件には、フィールド固有の合成動作があります。すべてのフィールドが同じ方法でマージされると想定せず、現在のスキーマについてはrequirements.toml リファレンスを参照してください。

下位互換性を維持するため、サポート対象のローカルクライアントは、従来の approval_policy、approvals_reviewer、sandbox_mode フィールドを要件として再解釈します。この変換では、必要に応じて互換性を保つための選択肢が追加されます。明示的な許可リストには requirements.toml を使用してください。

Work Cloud によるローカルコンピューターへのアクセスの優先順位

ローカルアクセスを使用する Work と dots では、Global のオーケストレーターポリシーと実行ポリシーを区別してください。適用対象のローカル要件が、接続されたコンピューターを制御します。Work のクラウドコンテナーと dots のクラウドコンピューターは、他のエグゼキューターが使用する管理対象環境バンドルではなく、独自の実行設定と要件を使用します。

ローカル実行では、MDM と従来の管理対象デバイスの要件が Agent Security より優先されます。デバイスのシステム要件ファイルの優先順位は、Agent Security より低くなります。各ポリシー内では、OS 固有の環境別上書き設定、全 OS 共通の環境別上書き設定、Global の順に優先して適用内容を決定します。ポリシー間では、設定の具体性よりもポリシーの優先順位が優先されます。

制御 同期を使用しないローカルの Work とローカルの Codex Work Cloud によるローカルコンピューターへのアクセス
企業の要件 上記のローカル要件の順序に従います。 ローカルエグゼキューターに適用されます。Work のクラウドコンテナーでは既存の Work Cloud ポリシーが維持されます。
デバイスの実行制限 サポートされているローカル制御によって強制適用されます。 上記のローカル要件の順序に従い、MDM と従来の要件は Agent Security より優先されます。
環境別の上書き設定 対象製品の設定モデルを使用します。 同じポリシー内では、OS 固有の環境別上書き設定、全 OS 共通の環境別上書き設定、Global の順に優先されます。優先順位の低いポリシーが、具体性によって優先されることはありません。

要件は制約を課し、デフォルト設定は初期値を提供します。ローカルアクセスを使用する Work と dots では、管理対象ポリシーが有効な場合、サポートされている Global ポリシーが共有クラウドオーケストレーターを通じて適用されます。適用対象のローカルの requirements.toml の要件が、接続されたコンピューターでの実行を制御します。Work のクラウドコンテナーと dots のクラウドコンピューターは、他の種類のエグゼキューターが使用する管理対象環境バンドルではなく、独自の実行設定と要件を使用します。ローカル実行の制限は、これらのクラウドコンピューターには自動的に適用されません。クラウド機能の権限を確認し、ローカル実行とクラウド実行を個別にテストしてください。

承認やウェブ検索を含むオーケストレーターの制御は、Global に設定してください。専用の「許可する承認ポリシー」と「許可するウェブ検索モード」の設定が利用できる場合はそれらを使用し、その他のサポート対象フィールドには TOML を使用します。フィールドの一覧と実行時の適用範囲については、設定リファレンスを参照してください。

クラウド管理の要件

対応プランのユーザーがChatGPTでサインインすると、対応するローカルクライアントは、ワークスペースに関連付けられた管理者が適用する要件を受信できます。これは、 requirements.toml互換のポリシーを配信する経路です。ワークスペースへのアクセスを付与したり、ワークスペースのRBACを置き換えたりするものではありません。認証要件は、 ローカルで管理する必要があります。

共通の要件は Agent security のコントロールで設定します。 on-request 承認と read-only または workspace-write サンドボックスのみを許可するポリシーには、承認ポリシー と ポリシーのガードレール 配下のサンドボックスモード を使用します。さらに、サポート対象のシェルエントリーポイントの実行前にも確認を求めるには、TOML として編集 を使用して [rules] テーブルを Global の requirements.toml に追加します。

同等の完全な TOML は次のとおりです。

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

管理対象のすべてのクライアントのバージョンが、選択したキーをサポートしていることを確認してください。対象のユーザーまたはグループにポリシーを割り当て、サポートされるクライアントで有効になることを検証してください。現在のスキーマについては設定リファレンスを、現在の割り当て動作については管理画面を参照してください。

サービスは、サインイン中の ID に適用される Enterprise 管理対象の要件レイヤーを選択します。ローカルクライアントは、場所と優先順位で説明した他の要件ソースとともに、それらのレイヤーを評価します。ワークスペース側での作成と割り当てには、現在の管理画面を使用してください。コピーしたグループ照合アルゴリズムに依存しないでください。管理サービスがその動作を管理しており、ローカル要件の形式とは独立して変更される可能性があります。

サポートされるキーと例については、requirements.toml の例とrequirements.toml リファレンスを参照してください。

ローカルクライアントがクラウド管理の要件を適用する仕組み

以下のローカルでの読み込みとキャッシュの動作は、サポートされるローカルクライアントについて説明しています。Work Cloud で Local computer access を使用する実行中のタスクに、変更後のクラウドポリシーがいつ適用されるかを示すものではありません。変更した制限を前提にする前に、実効ポリシーを確認してください。

ユーザーがサポート対象のローカルクライアントを起動し、サポート対象プランの ChatGPT でサインインすると、クライアントはまず、有効で ID が一致するキャッシュエントリがあるか確認します。有効なエントリがない場合、クライアントは再試行を行いながら該当するバンドルを取得し、成功すると署名付きキャッシュエントリを書き込みます。リクエストが失敗またはタイムアウトし、有効なキャッシュもない場合、クラウド構成バンドルの読み込みは、クラウド管理の要件レイヤーなしで何も通知せず起動するのではなく、エラーを返します。

キャッシュの解決後、クライアントはクラウドの要件を上記のその他の要件レイヤーと組み合わせます。バックグラウンドでの更新により、キャッシュされたバンドルが更新され、以降の構成読み込みで利用できるようになります。これは、すでに実行中のタスクが変更されたポリシーを直ちに使用することを保証するものではありません。一部のデスクトップ設定にはアプリの再起動が必要です。再起動を求められた場合はその指示に従い、変更に依存する前に、実際に適用されている設定を確認してください。

管理者と従業員の利用体験を確認する

各管理対象ポリシーの担当者を割り当て、そのポリシーを受け取るユーザーまたはグループを記録し、ファイルシステム、ネットワーク、承認、権限プロファイルに関する各制限の業務上の理由を文書化してください。

意図した権限を持つユーザーで、許可されるワークフローとブロックされるワークフローをテストしてください。サポートされるクライアントで実効設定を確認してください。ワークスペースのロールやグループだけでは、ローカルランタイムの制限は強制されません。

Agent security のポリシーをテスト を使用して、選択したメンバー、グループ、ロールに一致するポリシーを確認します。編集可能なセッションでは、現在のドラフトを保存せずに確認できます。結果に表示されるのは選択されるポリシーであり、最終的にマージされた構成や、クライアントが制限を強制するかどうかではありません。保存後、関連する各クライアントと実行経路で、許可されるワークフローとブロックされるワークフローをテストしてください。

デバイス管理の構成をデプロイする

認証制限とデバイス管理のポリシーには、ローカルのシステム要件または MDM を使用してください。従来の managed_config.toml の仕組みは、Agent security のデフォルト値 とは起動時の優先順位が異なります。MDM のワークフローは、要件と従来のデフォルト値の両方に対応します。

認証をローカルで管理する

allowed_login_methods、allowed_chatgpt_workspaces、 cli_auth_credentials_store、chatgpt_base_urlをローカルシステムの requirements.tomlまたはmacOS MDMの要件で設定します。Codexは、この4つのフィールドをクラウド管理の要件では無視します。ローカルの認証要件は、認証情報の読み込み前、およびCodexによるクラウドポリシーの取得前に適用されます。

承認済みワークスペースへのChatGPTログインを必須とし、認証情報を OSの認証情報ストアに保存するには、次の設定を使用します。

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methodsには、chatgpt、api、またはその両方を指定できます。省略すると、ログイン方法は制限されません。設定する場合、リストには少なくとも1つの方法を含める必要があります。 apiは、Amazon Bedrockを含むAPI認証を許可します。ワークスペースの制限は、 Codexアクセストークンにも適用されます。

ユーザーが設定するforced_login_methodとforced_chatgpt_workspace_idは、要件に従う必要があります。ユーザーが選択するワークスペースも、管理対象のワークスペース許可リストに含まれている必要があります。一致するワークスペースがなければ、ChatGPTログインは利用できません。API認証は、許可されていれば引き続き利用できます。利用可能なログイン方法がない場合、Codexは起動を拒否します。

認証情報の保存モードとサービスURLの設定については、要件リファレンス を参照してください。

管理対象のデフォルト値 (managed_config.toml)

サポートされているクラウド管理の初期値には、Agent security のデフォルト値を使用してください。このセクションでは、従来のデバイス管理の managed_config.toml の仕組みと、その異なる起動時の優先順位について説明します。 Agent security のデフォルト値 を編集しても、managed_config.toml ファイルがメンバーのデバイスにデプロイされることはありません。

管理対象のデフォルトは、サポート対象のローカルクライアントが起動時に使用する構成を設定します。起動時には、ユーザーのローカルな config.toml と CLI の --config 上書きを置き換えます。ユーザーは現在の実行中にこれらの設定を変更できますが、次回クライアントを起動すると、デフォルトが再び適用されます。

ChatGPT でサインインする Codex では、2026 年 10 月 14 日正午（PDT、 19:00 UTC）に GPT-5.5 の提供が終了します。管理対象のデフォルト、macOS MDM プロファイル、または保存済みの設定で、これらのユーザーに gpt-5.5 が固定されている場合は、利用可能なモデルに置き換えてください。管理者が対象ユーザーに対して有効にした後、 gpt-6.1-sol を選択します。OpenAI API、および API key で認証された Codex セッションには影響しません。ワークスペースで利用可能なモデルを参照してください。

gpt-5.4 または gpt-5.4-mini が引き続き固定されている構成については、 GPT-5.4 の移行ガイダンスに従ってください。

管理対象のデフォルトが要件を満たしていることを確認してください。ローカルランタイムは、許可されていない値を拒否します。

優先順位とレイヤー構成

ローカルランタイムは、次の順序で有効な構成を組み立てます（上の項目が下の項目を上書きします）。

  • 管理対象環境設定（macOS MDM、最優先）
  • managed_config.toml（システム／管理対象ファイル）
  • config.toml（ユーザーの基本構成）

CLI の --config key=value 上書きは基本構成に適用されますが、管理対象レイヤーによって上書きされます。つまり、ローカルフラグを指定しても、各実行は管理対象のデフォルトから開始されます。

クラウドのconfig.tomlには通常の設定の優先順位が適用され、上記の従来の順序は適用されません。クラウドのrequirements.tomlには、 要件の優先順位が適用されます。

保存場所

  • Linux/macOS（Unix）：/etc/codex/managed_config.toml
  • Windows／Unix 以外：~/.codex/managed_config.toml

ファイルがない場合、ローカルランタイムは管理対象レイヤーをスキップします。

managed_config.toml の例

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

推奨されるガードレール

  • ほとんどのユーザーには、承認を伴う workspace-write を推奨します。フルアクセスは制御されたコンテナに限定してください。
  • セキュリティレビューで、ワークフローに必要なコレクターまたはドメインが許可されていない限り、network_access = false を維持してください。
  • 管理対象の構成を使用して OTel 設定（エクスポーター、環境）を固定できますが、プロンプト内容の保存をポリシーで明示的に許可していない限り、log_user_prompt = false を維持してください。
  • ローカルの config.toml と管理対象ポリシーの差分を定期的に監査して、構成のずれを検出してください。管理対象レイヤーは、ローカルのフラグやファイルより優先される必要があります。

macOS の管理対象環境設定（MDM）

macOS では、管理者は次の場所に base64 エンコードされた TOML ペイロードを提供するデバイスプロファイルをプッシュできます。

  • 環境設定ドメイン：com.openai.codex
  • キー：
    • config_toml_base64（管理対象のデフォルト）
    • requirements_toml_base64（要件）

ローカルランタイムは、これらの「管理対象環境設定」ペイロードを TOML として解析します。管理対象のデフォルト設定（config_toml_base64）では、管理対象環境設定が最も高い優先順位を持ちます。要件（requirements_toml_base64）の優先順位は、 要件の優先順位に従います。同じ要件側の [features] テーブルは requirements_toml_base64 でも機能します。そこでも正規の機能キーを使用してください。

MDM の設定手順

ローカルランタイムは標準の macOS MDM ペイロードに対応しているため、 Jamf Pro、Fleet、Kandji などのツールを使用して設定を配布できます。簡易的なデプロイ手順は次のとおりです。

  1. 管理対象ペイロードの TOML を作成し、base64 でエンコードします（折り返しなし）。
  2. その文字列を、MDM プロファイルの com.openai.codex ドメインにある config_toml_base64（管理対象のデフォルト）または requirements_toml_base64（要件）へ配置します。
  3. プロファイルをプッシュした後、サポート対象のローカルクライアントを再起動するようユーザーに依頼し、起動時の構成概要に管理対象の値が反映されていることを確認します。
  4. ポリシーを取り消したり変更したりする場合は、管理対象ペイロードを更新します。クライアントは次回起動時に更新された環境設定を読み込みます。

ペイロードにシークレットや変更頻度の高い動的な値を埋め込まないでください。管理対象の TOML は、他の MDM 設定と同様に変更管理の対象として扱ってください。