管理対象の構成

管理対象の構成を使うと、企業の管理者は ChatGPT Work と Codex がサポートする要件とデフォルトを設定できます。要件は、ユーザーやタスクが実行できる操作を制限します。デフォルトは設定の初期値です。利用できる設定は、製品、クライアントのバージョン、実行環境によって異なります。

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

企業の管理者は、次の方法でローカルクライアントの動作を制御できます。利用できる項目はクライアントによって異なります。

• 要件：管理者が適用する制限です。ユーザーは上書きできません。

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

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

グローバルの基本設定、環境別の上書き設定、オーケストレーターとエグゼキューターのフィールド一覧については、エージェントセキュリティを参照してください。

ユーザーが ChatGPT を使って Codex にサインインしない場合は、自社で運用する HTTPS エンドポイントから Codex CLI とデスクトップアプリにデフォルトと要件を配布できます。詳しくは、チーム向け Codex 構成のセルフホスティングを参照してください。

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

エージェントセキュリティが有効なワークスペースでは、ワークスペースのオーナーと管理者、および 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 の設定例を参照してください。

「ブラウザ」では、エージェントによるブラウザ内の操作を制御します。「コンピューターの使用」では、エージェントによるネイティブデスクトップアプリの操作を制御します。組み込みのブラウザペインは、「ブラウザ」とは別に設定します。ブラウザへのアクセス方法による違いについては、ブラウザセッションと既存のサインインを参照してください。

事前準備

エージェントセキュリティのポリシーを管理する権限を持つアカウントを使います。ポリシーの対象者と、サポートが必要なクライアントのバージョンおよび OS を確認してください。ポリシーの割り当て、グローバル設定、環境ごとに上書きできる項目については、エージェントセキュリティを参照してください。

ユーザーが上書きできない制限は要件で設定します。デフォルトでは、その制限の範囲内で初期値を設定します。サイトやアプリを許可しても、プラグインのインストール、OS の権限の付与、ユーザーのサインイン、レビューが必要な操作の承認は行われません。

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

これらのデスクトップ用の設定は、Work Cloud がホストするブラウザには適用されません。クラウドブラウザの使用とクラウドネットワークアクセスは、管理コンソール > 権限とロール > ワークスペースの機能 > クラウドコンピューターの機能で別途管理します。Work Cloud へのエージェントセキュリティの適用を参照してください。

ブラウザアクセスの設定

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

サイトルールを追加

サイトルールで「デフォルト」のままにした権限には、「デフォルト」行の設定が適用されます。複数のルールが一致する場合は、権限ごとに「ブロック」が優先されます。

サイトまたはパターン 

サイトアクセスデフォルトのルールを使用

ダウンロードデフォルトのルールを使用

アップロードデフォルトのルールを使用

デバッグ/CDPデフォルトのルールを使用

自動レビューデフォルトのルールを使用

常に許可デフォルトのルールを使用

承認の有効期間デフォルトのルールを使用

ブラウザ操作の「自動レビュー」を無効にすると、対象の操作についてユーザーに承認を求めるようになります。モデルの安全性モニタリングは引き続き有効です。

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

「コンピューターの使用」では、ブラウザをネイティブアプリとして操作することもできます。この方法で操作する場合、「ブラウザ」のサイト別ルールや機能別ルールは適用されません。ネイティブアプリへのアクセスは別途確認してください。詳しくは、ブラウザのセキュリティ境界を参照してください。

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

1. 要件で、デスクトップアプリの制御 > アプリルールに移動します。
2. デフォルト行の操作メニューで、どのルールにも一致しないアプリへのアクセスを設定します。「コンピューターの使用」で操作できるアプリを承認済みのものに限定するには、デフォルトでアクセスをブロックし、承認済みのアプリに対する許可ルールを追加します。
3. アプリルールを追加を選択します。ルールを編集ダイアログで、macOS バンドル ID、Windows AUMID、Windows 実行ファイルのいずれかを App から選択します。バンドル ID またはアプリケーションユーザーモデル ID（AUMID）の場合は、アプリ識別子にその ID を正確に入力します。Windows 実行ファイルの場合は、発行元名と製品名を入力します。バイナリ名は任意です。アプリの識別には、表示名やファイルパスではなく、確認済みの識別情報を使用してください。
4. ルールのアプリアクセスを設定し、ルールを追加を選択します。アプリの承認を保存の設定をデスクトップアプリの制御で確認します。検証メッセージを確認してから、変更を保存を選択します。承認の保存を無効にしても、ユーザーは現在のセッションに限ってアプリを承認できます。承認の保存を許可しただけでは、アプリは承認されません。
5. 導入環境で使用する各対応 OS で、許可したアプリとブロックしたアプリをそれぞれテストします。OS の権限が引き続き適用されることと、承認が必要な操作では引き続きユーザーの承認が必要であることを確認します。

ルールを編集

アプリアクセスのデフォルトを設定し、ルールに一致するアプリについてはその設定を上書きします。

AppmacOS バンドル ID

アプリ識別子 

アプリアクセスアクセス設定を選択

Windows アプリの識別情報の要件については、「コンピューターの使用」のポリシーフィールドを参照してください。管理対象の Mac については、ロック中の使用制限を参照してください。

実効ポリシーの確認

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

設定が反映されない場合は、クライアント、OS、ポリシーの配布経路がいずれもその設定に対応しているか確認してください。特に、Work Cloud からローカルコンピューターにアクセスする場合は、一部のフィールドで対応が限定的な場合や、検証が必要な場合があります。構成リファレンスの Work の互換性に関する説明を参照してください。

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

TOML 構成リファレンス

以下の例では、これまでに説明したポリシーを requirements.toml で設定する方法を示します。ファイルまたは TOML エディターでポリシーを管理する際に参照してください。エージェントセキュリティの画面で設定する場合は、ローカルファイルを編集する必要はありません。

次のブラウザ設定例では、アクセスをデフォルトで拒否し、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" を設定します。

対象の管理プランでは、browser_use.allow_webmcp を未設定のままにするか true に設定すると、ワークスペースポリシーを通じて、デスクトップアプリの組み込みブラウザでサイトツールの使用を許可できます。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 リファレンスを参照してください。サイトやアプリを個別に制限する代わりに機能自体を無効にする場合は、機能フラグの固定を参照してください。

その他のデスクトップ設定

デスクトップでは、機能の利用可否、ロック中の使用、Appshots、デバイスのリモート制御を設定できます。機能の利用可否とロック中の使用には、それぞれ専用の設定を使います。Appshots とデバイスのリモート制御は、TOML として編集で設定します。デスクトップアプリの通信先を制限する方法については、デスクトップアプリのネットワーク接続先の制御を参照してください。

機能フラグの固定

エージェントセキュリティでデスクトップ機能の利用可否を設定するには、グローバル > 要件 > デスクトップ機能の利用可否を開きます。アプリ内ブラウザ、ブラウザ、外部ブラウザの使用、コンピューターの使用のうち、無効にする機能を強制的にオフに設定し、変更を保存を選択します。フル CDP アクセスでユーザーによる有効化をブロックを選択すると、ユーザーがフル 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_full_cdp_access = false は、ブラウザ開発者モードを含むローカルランタイムのフル CDP アクセスを無効にします。ChatGPT デスクトップアプリも、対応する設定を有効にできなくなります。
• browser_use_external = false は、エージェントが対応するブラウザ拡張機能を介してブラウザを操作する機能を無効にします。
• computer_use = false は、コンピューターの使用によるネイティブアプリの操作を無効にします。これには、ブラウザをネイティブアプリとして操作する場合も含まれます。記録と再生、および関連するインストールやセットアップの手順も無効になります。

ブラウザ機能を無効にしても、ブラウザを操作できる経路は残ります。 コンピューターの使用とブラウザアプリへのアクセスがどちらも許可されている場合は、引き続きブラウザをネイティブアプリとして操作できます。この経路には、ブラウザ機能のサイトルールや機能ルールは適用されません。この経路をブロックするには、コンピューターの使用を強制的にオフ（computer_use = false）に設定します。他のネイティブアプリを引き続き利用できるようにする場合は、代わりにアプリルールでブラウザアプリへのアクセスを拒否します。外部ブラウザの使用とアプリ内ブラウザの設定は個別に確認してください。各経路に適用される設定については、ブラウザセッションと既存のサインインを参照してください。

これらのキーを省略すると、ポリシー上は各機能の使用が許可されます。実際に利用できるかどうかは、通常どおり、クライアントとプラットフォームの対応状況、およびロールアウトの状況によって決まります。

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

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

TOML エディターまたはデバイス管理による配布で同じ要件を指定するには、次のように設定します。

[computer_use]
allow_locked_computer_use = false

この要件を設定すると、ロック中の使用を有効にするための設定項目が表示されなくなります。すでに有効な場合は、有効なままです。この要件を省略すると、通常どおり、製品での提供状況とユーザーのローカル設定によって利用可否が決まります。

Appshots の無効化

Appshots を使うと、対応クライアントはアプリのスナップショットを含めることができます。クラウド管理の対象ユーザーに対して Appshots を無効にするには、エージェントセキュリティで TOML として編集を開き、allow_appshots フィールドをグローバルの requirements.toml のトップレベルに設定します。デバイス管理によるデプロイでは、該当するローカルの要件設定元で次のように指定します。

allow_appshots = false

Appshots が利用可能な環境では、allow_appshots = false を設定すると Appshots が無効になります。キーを省略すると、要件による Appshots の制限はなく、製品側で通常どおり利用可否が判定されます。configRequirements/read で実効要件を読み取る App Server クライアントは、同じ制限を allowAppshots として受け取ります。値が省略されているか null の場合、allowAppshots によって Appshots が無効になることはありません。

デバイスのリモート制御の無効化

クラウド管理の対象ユーザーに対してデバイスのリモート制御を無効にするには、エージェントセキュリティで TOML として編集を開き、allow_remote_control フィールドをグローバルの requirements.toml のトップレベルに設定します。対応するローカルの要件設定元でも allow_remote_control を設定できます。

allow_remote_control = false

デバイスのリモート制御に対応する環境では、allow_remote_control = false を設定するとリモート制御が無効になります。キーを省略すると、要件によるデバイスのリモート制御の制限はなく、製品側で通常どおり利用可否が判定されます。この要件を設定しても、SSH リモート接続は無効になりません。

承認と実行権限の設定

ここでは、承認の動作、権限の範囲、初期値を設定します。まずポリシーのガードレールとデフォルトを設定してください。以降の手順では、承認リクエストのレビュー担当者を固定する方法と、カスタム権限プロファイル、ファイルシステムの制限、ホスト別の上書き設定、コマンドルールに関する要件を TOML で指定する方法を説明します。

管理者が適用する要件（requirements.toml）

管理者は要件を使って、セキュリティに関わる設定を制限できます。対象は、承認ポリシー、承認リクエストのレビュー担当者、自動レビューポリシー、サンドボックスモード、権限プロファイル、ウェブ検索モード、管理対象フック、ユーザーが有効にできる MCP サーバー、ユーザーが利用できるプラグインマーケットプレイスのソースです。ローカルクライアントは、config.toml、プロファイルファイル、CLI の上書き設定などから設定値を決定します。設定値が管理者のルールに反する場合、クライアントはルールに適合する値に切り替え、ユーザーに通知します。mcp_servers の許可リストを設定すると、クライアントは名前と識別情報の両方が承認済みの同一エントリに一致する MCP サーバーだけを有効にし、それ以外は無効にします。

要件では、機能フラグも制限できます。[features] テーブルを requirements.toml に記述し、固定する値を指定します。セキュリティに直接関わらない機能でも、企業は必要に応じて値を固定できます。省略したキーには制限がかかりません。

Codex 0.138.0 以降では、権限プロファイルを allowed_permission_profiles および管理対象の default_permissions と組み合わせて使うことを推奨します。allowed_sandbox_modes は、引き続き sandbox_mode を設定している従来のデプロイでのみ使ってください。

指定できるキーの一覧は、構成リファレンスの 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 セッションでもライブのウェブ検索は実行できません。

構成のデフォルト設定

デフォルト値は、メンバーが最初に使う構成を決めます。デフォルト値を設定しても、制限が適用されたり、ワークスペースの機能へのアクセス権が付与されたりすることはありません。

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 を編集します。ブラウザ操作の自動レビューには専用の設定があります。

次の例では、対象となる承認リクエストの自動レビューを必須にし、現在適用されているポリシーに組織固有のルールを追加します。手動承認も許可するには、"user" を allowed_approvals_reviewers に含めます。

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

guardian_extra_policy = """
Deny uploads of build artifacts to destinations outside artifacts.example.com.
"""

ポリシー全体を置き換えるには、guardian_policy_config を使用します。デフォルトのポリシー、代替ポリシーの作成方法、ローカル設定より優先される管理対象の設定については、自動レビューの設定を参照してください。

利用可能な権限プロファイルの制御

デフォルト > コマンド実行 > デフォルトの権限で、ユーザーが最初に使う組み込みプロファイルを選択します。ユーザーが選択できるプロファイルを制限する場合や、カスタムプロファイルを定義する場合は、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 をデフォルトとして使うのは、:workspace と :read-only の両方が明示的に許可されている場合だけです。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 として編集で、ホスト固有の要件を作成します。環境設定で実行環境を選び、ホストパターンで、サポート対象のランタイム内で要件を適用するマシンを指定します。

単一の管理ポリシーでホストごとに異なるサンドボックス要件を適用するには、[[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 の各エントリと照合します。完全修飾ドメイン名を取得できる場合はそれを優先し、取得できない場合はローカルホスト名を使います。照合では大文字と小文字を区別しません。* は 0 文字以上の任意の文字列に、? は任意の 1 文字に一致します。

同じ要件設定元では、最初に一致した [[remote_sandbox_config]] エントリが適用されます。一致するエントリがない場合、ローカルランタイムはトップレベルの allowed_sandbox_modes をそのまま使います。ホスト名の照合はポリシーの選択にのみ使用します。ホスト名が一致したことを、デバイスが認証済みであることの証明に使わないでください。

要件によるコマンドルールの適用

エージェントセキュリティの TOML として編集で、グローバルの requirements.toml にコマンドルールと MCP サーバーの制限を追加します。コマンドルールでは、一致するコマンドに対して承認を求めるか、実行を拒否するかを指定します。MCP サーバーの制限では、サーバーの識別情報に基づいて、クライアントが有効にできるサーバーを限定します。承認ポリシーでは、どちらのルールも作成できません。

管理者は requirements.toml の [rules] テーブルでも、コマンドの実行を制限するルールを適用できます。これらのルールは通常の .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 サーバーを制限するには、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 サーバーでは、plugins.<plugin>.mcp_servers.<server> の下に同じ形式で識別情報を指定します。

mcp_servers を指定してもエントリが 1 つもない場合、ローカルクライアントはすべての MCP サーバーを無効にします。

ネットワークアクセスの設定

コマンドの通信とデスクトップアプリの通信は、それぞれ別の設定で制御します。まず、対象となるコマンドの通信をネットワーク利用の制御で設定し、環境とランタイムの制限を確認してください。そのうえで、必要に応じてデスクトップアプリ専用の要件を適用してください。ブラウザのサイトルールについては、ブラウザとコンピューターの使用の制御を参照してください。

ネイティブクライアントのリクエストに対するシステムプロキシの設定

実験的な設定 features.respect_system_proxy を有効にすると、ChatGPT デスクトップアプリと Codex が利用するネイティブ Codex ランタイムは、自身が送信するネットワークリクエストに OS のプロキシ設定を使用できます。システムプロキシまたはプロキシ自動設定（proxy auto-configuration、PAC）が必要なデバイスで有効にしてください。デフォルトは false です。

デフォルト設定の指定に対応している config.toml または managed_config.toml に、次の設定を追加してください。

[features]
respect_system_proxy = true

プロジェクト単位のローカル設定では、この設定を有効にできません。macOS MDM では、同じ TOML を config_toml_base64 に含めてください。ローカル設定を変更したら、クライアントを再起動してください。この設定を無効にするには、有効にした設定元で値を false にします。

サインインとクラウドのデフォルト設定

別の機能である system_proxy_fallback は、デフォルトで有効です。接続に失敗した場合、この機能は、対象となるサインインやクラウド設定の取得リクエストをシステムプロキシ経由で再試行できます。これは respect_system_proxy が false の場合も同様です。このフォールバックにより、対応するクライアントでは、ローカルでシステムプロキシの使用を明示的に有効にしなくても、サインインしてクラウドのデフォルト設定を取得できる場合があります。respect_system_proxy を無効にしただけでは、フォールバックは無効になりません。

直接接続できず、フォールバックが利用できないか、無効になっているか、再試行しても接続できない場合は、サインイン前に respect_system_proxy を有効にする設定を対象のデバイスに配布してください。

適用範囲と制限

利用予定のネットワークとクライアントのバージョンで、サインインと認証済みリクエストがそれぞれ成功することを確認してください。検証の際は、次の点に留意してください。

• 対象リクエスト：この設定は、Codex ランタイムが管理するネットワーククライアントに適用されます。ChatGPT デスクトップアプリやブラウザからのリクエスト、プラグインプロセス、シェルコマンドのすべてに適用されるわけではありません。この設定では接続先の許可リストは強制されず、直接接続が必ずブロックされるわけでもありません。対象の通信については、コマンドのネットワーク要件とデスクトップアプリのネットワーク要件を参照してください。
• 対応プラットフォーム：macOS と Windows では、ランタイムは OS の機能を使ってシステムプロキシを検出できます。OS の機能でプロキシを特定できない場合は、環境変数で明示されたプロキシ設定があればそれを使い、なければ直接接続します。他のプラットフォームでは OS による検出を行わず、環境変数で指定されたプロキシ設定を使い、設定がなければ直接接続します。
• PAC によるルーティング：ランタイムは PAC の結果から 1 つの経路を選択します。その経路で接続に失敗しても、結果に続けて記載されたプロキシや DIRECT エントリを使って再試行することはありません。
• Windows 認証：対応ビルドでは、トンネルの確立時に HTTP 407 のプロキシ認証要求を受けると、サインイン中の Windows ユーザーの資格情報を使って Negotiate または NTLM で応答できます。プロキシへの TLS 接続に紐付けられた認証トークンを必要とする HTTPS プロキシには対応していません。

ネットワークアクセス要件の設定

エージェントセキュリティの要件 > ネットワーク利用の制御で、コマンド実行時の通信のうち、制御対象となるものを管理します。各環境に共通する設定はグローバルで指定します。環境ごとに実行設定を指定する場合は、ローカル環境または Codex Cloud 環境のうち、該当するタブが利用可能であれば、そのタブを使います。

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

管理対象ネットワークをオフにすると、そのスコープで設定したネットワークルールが削除され、「オフ」が明示的な設定値として保存されます。この操作でインターネットアクセスが無効になることはありません。未設定にすると、そのスコープで指定したネットワーク設定が削除され、該当するポリシーやランタイムのデフォルト設定が適用されるようになります。環境固有の設定を削除すると、グローバルスコープから継承したルールが有効になる場合があります。ネットワークの詳細項目を設定する場合や、ビジュアルエディターで扱えない既存の旧形式のドメインリストを編集する場合は、TOML として編集を使ってください。

Codex 0.166.0 では、[network_proxy] が、管理対象のコマンド通信を設定する requirements.toml の正式なテーブル名です。Codex は従来の名前 [experimental_network] にも対応しています。各レイヤーでは、どちらか一方のテーブル名を使ってください。レイヤー間で名前が異なる場合も、Codex は通常の要件の優先順位に従います。

管理対象のテーブルで enabled = true を設定すると、ユーザー設定 features.network_proxy の値にかかわらずプロキシが起動します。コマンドがネットワークにアクセスするには、使用中のサンドボックスでもその通信が許可されている必要があります。次の例では、古いクライアントやポリシー検証レイヤーでも認識できるテーブル名を使います。

[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 は、管理者が "allow" エントリを [experimental_network.domains] に定義し、接続先をそのルールで許可したドメインに限定する場合にのみ使ってください。管理対象の許可ルールがない状態で true にすると、ユーザーが追加したドメイン許可ルールは無効になります。正式な domains マップを、従来の allowed_domains または denied_domains リストと併用しないでください。

*.example.com はサブドメインのみに一致します。**.example.com はドメイン自体とそのサブドメインに一致します。同じドメインが拒否ルールと許可ルールの両方に一致する場合は、拒否ルールが優先されます。

ドメインの指定方法、ローカルおよびプライベートな接続先に適用されるルール、許可より拒否を優先する動作、DNS リバインディングに関する制限は、エージェントの承認とセキュリティで説明しているサンドボックスのネットワーク仕様と同じです。

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

• ウェブ検索を制限するには、allowed_web_search_modes を使います。
• アプリやコネクタとの連携を無効にするには、features.apps = false を使います。対応環境でプラグインを無効にするには、features.plugins = false を使います。
• 利用できる MCP サーバーを制限するには、管理対象の mcp_servers 許可リストを使います。
• ブラウザやコンピューターの使用を制限するには、browser_use、in_app_browser、computer_use などの機能要件を使います。
• この制御に対応する Codex Cloud の管理対象コマンドについては、エージェントセキュリティに加えて、環境のインターネット設定も確認してください。エージェントセキュリティで許可したドメインでも、環境側の設定でブロックされる場合があります。

通常のコマンド実行と、ポリシーで許可されているサンドボックスの全面的な権限昇格を伴う実行は、個別にテストしてください。全面的な権限昇格が承認されると、コマンドが管理対象のコマンド用プロキシを経由せずに通信できる場合があります。ネットワークの分離を参照してください。

許可される接続先がない場合：管理対象ネットワークと管理者が追加したドメインのみ許可がどちらも有効な場合、通常の管理対象コマンドが接続するには、明示的に設定した許可エントリまたは継承した許可エントリが必要です。保存する前に、実際に許可される接続先を確認してください。

Codex Cloud のローカルおよびプライベート接続：クラウドで実行するコマンドが許可済みのドメインに接続できない場合は、allow_local_binding の実効値を確認してください。「オフ」を継承していると、上流プロキシへの接続がブロックされる場合があります。クラウド固有のデフォルト値と上書き設定については、Codex Cloud のローカルおよびプライベート接続を参照してください。

環境別の要件が空の場合は、グローバルの要件が適用されます。管理対象ネットワークをオフにする設定は、クラウド環境のインターネットアクセス設定とは別です。実行範囲の詳細は、エージェントセキュリティの実行制御を参照してください。

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

同じポリシー内での優先順位は、高い順に「OS 固有の環境別上書き設定 → 全 OS 共通の環境別上書き設定 → グローバル設定」です。ポリシー間では、優先順位の低いポリシーの方が具体的であっても、優先順位の高いポリシーが優先されます。一部の要件には、フィールド固有の統合ルールがあります。ランタイムは、こうして確定した要件を適用します。以下のネットワーク設定では、フィールドごとの動作とポリシーの優先順位を分けて考えてください。

以下の例では、同じポリシー内の環境別設定とグローバル設定を比較し、フィールドごとの統合ルールと実行時の動作を示します。管理対象ネットワークは設定済みで、優先順位の高い他のポリシーによる値の変更はないものとします。

環境別のドメインアクセス設定

管理者は、同じポリシー内で同じドメインのルールを環境別に上書きできます。グローバル設定で拒否したドメインを特定の環境で許可することも、グローバル設定で許可したドメインを特定の環境で拒否することもできます。環境別の上書き設定がなければ、その環境はグローバルルールを継承します。他の有効な拒否ルールやアクセス制御によってリクエストがブロックされる場合もあります。

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

この表は、同じポリシー内で同じドメインキーに設定したルールを比較したものです。優先順位の高い他のポリシーが結果を変更しない場合を想定しています。同じキーの値は優先順位の高い値に置き換わります。継承した他のキーはそのまま残ります。許可ルールに一致しても、継承したワイルドカードの拒否ルールなど、別の拒否ルールにも一致するリクエストはブロックされます。環境別のマップが空でも、継承したルールは消去されません。

例：packages.example.com をグローバル設定で拒否し、開発環境で許可します。開発環境では、上記の条件を満たせばこのドメインへのアクセスを許可できます。本番環境では、上書きしない限りグローバルの拒否ルールを継承します。

デプロイしたエグゼキューターがこれらの統合ルールに対応していることを確認してください。通常の管理対象エグゼキューターがどこまで対応しているかは、引き続き検証が必要です。

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

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

以下のフィールドはすべて、管理対象の network_proxy テーブルに属します。テーブル名には experimental_network も使用できます。どちらの名前でも、設定先は requirements.toml です。矢印の左側はグローバル設定の値、右側は同じポリシー内の環境別設定の値です。これらはローカル実行の例であり、オーケストレーターでも同じ設定がサポートされることを示すものではありません。

プロキシの有効化、接続先の許可リストへの限定、上流プロキシの動作、Unix ソケットのルールは、いずれもエグゼキューターによって扱いが異なります。ドメインキーの統合方法をこれらの設定に当てはめないでください。実効値を確認し、デプロイしたランタイムでテストしてください。Codex Cloud からローカルネットワークやプライベートネットワークへの接続については、ネットワークアクセス要件の設定を参照してください。

ロールアウト前の動作検証

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

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

エージェントセキュリティの TOML として編集を使い、デスクトップアプリ固有の要件をグローバル設定に指定してください。ネットワーク利用の制御画面では、コマンドのネットワーク通信を管理します。この通信には別のポリシーが適用されます。

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

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

プラグインと管理対象フックの設定

これらの設定には、エージェントセキュリティの TOML として編集または対応するローカルの設定元を使います。マーケットプレイスのデフォルト設定、プラグインに強制適用する制限、管理対象フックは、それぞれ目的が異なります。必要なポリシーに合った手順を選んでください。

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

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

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

プラグインの利用制御

プラグイン機能の設定を強制するには、エージェントセキュリティの TOML として編集を使い、グローバル設定の requirements.toml に要件を記述します。デバイス管理下のクライアントには、これらの設定をローカルの要件として配布することもできます。デフォルト > アプリとツール > アプリ/コネクタでは、アプリが提供するツールのデフォルト設定を指定します。プラグインの利用可否を強制する features.plugins とは別の設定です。ワークスペースのプラグイン権限については、アプリとコネクタを参照してください。

対応するローカルクライアントでプラグインを無効にするには、features.plugins の値を false に設定する行を requirements.toml に記述します。

features.plugins = false

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

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

TOML として編集を使ってグローバル設定の 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 キー用のカタログを含め、OpenAI が選定した Git マーケットプレイスのソースも、許可リストのいずれかのルールに一致する必要があります。これらのマーケットプレイスを許可するには、ref を指定せずに次の Git ソースを追加します。

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

OpenAI が選定したカタログを除外するには、このソースを許可リストに含めず、より広い範囲を対象とするホストルールでもこのソースが許可されていないことを確認します。同梱のプラグインと、リモートでインストールされたワークスペースのプラグインは、この Git ソースに対するポリシーの対象外です。

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

要件による管理対象フックの強制適用

エージェントセキュリティでグローバル > 要件 > TOML として編集を開きます。ローカルコンピューターにアクセスする Work と dot 向けに、サポートされている mcp_tool ハンドラーをグローバルの requirements.toml に設定します。ロールアウト前に、コールバックの接続先に到達できることと、コールバックがタイムアウトした場合の動作をテストしてください。対応するイベントと失敗時の動作については、クラウドオーケストレーションでのフックを参照してください。

ローカルの Codex には、デバイス管理ツールでフックのスクリプトを配布します。ユーザーがフックを無効にしても管理対象フックを強制適用するには、[features].hooks = true を requirements.toml に指定して値を固定します。スクリプトのパスと、管理対象フックだけを許可する方法については、管理対象フックの設定例を参照してください。

ポリシーの適用範囲と優先順位

ここでは、ポリシーの適用先、複数の要件を組み合わせる仕組み、クライアントがクラウドで管理される設定を受け取る仕組み、適用結果の確認方法を説明します。

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

エージェントセキュリティと Work Cloud からのローカルコンピューターへのアクセス

ポリシーと構成の管理には、管理コンソールのエージェントセキュリティを使います。これは従来の「ポリシーと構成」に代わる機能です。Work Cloud からのローカルコンピューターへのアクセスを有効にしているかどうかにかかわらず、管理コンソールでエージェントセキュリティを利用できます。既存のポリシー、割り当て、適用順序は維持されます。エージェントセキュリティで既存のポリシーを確認してください。Work Cloud からローカルコンピューターにアクセスするには、別途アクセスを有効にする必要があります。移行手順については、エージェントセキュリティを参照してください。

ポリシー管理の自動化をエージェントセキュリティに移行する前に、次の手順を実施してください。

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

2. グローバル設定の管理にはポリシー API を使います。ローカル設定や Codex Cloud 設定の管理には、エージェントセキュリティの画面を使います。移行後も、グローバル設定を管理する既存の API ワークフローを利用できます。スクリプトと Terraform 連携をテストし、ポリシーの割り当てと適用順序が変わっていないことを確認してください。

3. 必要な変更を加え、自動化をテストします。エージェントセキュリティで対象のポリシーに意図した更新が反映され、更新後の制御が実際に適用されることを確認してください。

ポリシーを移行しても、Work や dot にローカルコンピューターへのアクセス権は付与されません。ロールアウト前にポリシーを確認または作成することを推奨しますが、アクセスを有効にする際の確認手順では、ポリシーの作成は任意です。ローカルコンピューターへのアクセスを許可を有効にする前に、移行済みのベースラインを確認してください。現在 MDM 経由でのみポリシーを配布している場合は、代わりにクラウドのベースラインを作成してください。いずれかのクラウドポリシーで enforce_residency が有効な場合、Work と dot の両方でローカルコンピューターへのアクセスを許可が無効になります。この保護措置によってワークスペースのデータレジデンシーが設定されることはなく、この措置だけで Work Cloud や dot が無効になることもありません。

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

フックを使うワークフローでローカルアクセスを有効にする前に、クラウドオーケストレーションで実行されるフックを確認してください。

設定場所と優先順位

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

1. システムの requirements.toml（Linux や macOS を含む Unix システムでは /etc/codex/requirements.toml、Windows では %ProgramData%\OpenAI\Codex\requirements.toml）
2. クラウド構成バンドルで配布されるエージェントセキュリティの要件
3. ローカルクライアントが要件として解釈する従来の managed_config.toml のフィールド
4. com.openai.codex:requirements_toml_base64 を通じて配布される macOS の管理対象環境設定（MDM）

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

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

Work Cloud からローカルコンピューターにアクセスする場合の優先順位

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

ローカル実行では、MDM の要件と従来の管理対象デバイスの要件がエージェントセキュリティより優先されます。デバイスのシステム要件ファイルよりも、エージェントセキュリティが優先されます。各ポリシー内では、OS 固有の環境別上書き設定、全 OS 共通の環境別上書き設定、グローバルの順に優先されます。異なるポリシー間では、設定の具体性にかかわらず、ポリシーの優先順位に従います。

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

承認やウェブ検索など、オーケストレーターの設定はグローバルで管理してください。「許可する承認ポリシー」と「許可するウェブ検索モード」の専用コントロールが利用できる場合は、それらを使ってください。それ以外の対応フィールドは TOML で設定します。フィールドの一覧と、各フィールドがどの実行環境に適用されるかについては、構成リファレンスを参照してください。

クラウドで管理する要件

対応プランのユーザーが ChatGPT でサインインすると、対応するローカルクライアントは、そのワークスペースに対して管理者が適用する要件を受け取ることができます。この仕組みは requirements.toml と互換性のあるポリシーの配布に使われます。ワークスペースへのアクセス権を付与するものでも、ワークスペースの RBAC に代わるものでもありません。認証要件はローカルで管理する必要があります。

一般的な要件は、エージェントセキュリティのコントロールで設定します。承認ポリシーを on-request に限定し、サンドボックスモードを読み取り専用または workspace-write に限定するには、承認ポリシーとサンドボックスモードをポリシーのガードレールで設定します。対応するシェルのエントリポイントを実行する前にも承認を求めるには、TOML として編集を使い、[rules] テーブルをグローバルの 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" },
]

管理対象クライアントのすべてのバージョンが、選択したキーに対応していることを確認してください。対象のユーザーまたはグループにポリシーを割り当て、対象ユーザーが使う対応クライアントでポリシーが有効になっていることを確認します。現在のスキーマは構成リファレンスで、ポリシーの割り当てが現在どのように機能するかは管理画面で確認してください。

サービスは、サインインしたユーザーの識別情報に基づいて、そのユーザーに適用する企業管理の要件レイヤーを選択します。ローカルクライアントは、選択されたレイヤーと、設定場所と優先順位で説明した他の設定元の要件を合わせて評価します。ワークスペース側でポリシーを作成して割り当てるには、現在の管理画面を使ってください。グループの照合には、コピーしたアルゴリズムを使わないでください。照合方法は管理サービスが決定し、ローカルの要件の形式とは独立して変更することがあります。

対応するキーと例については、requirements.toml の設定例と requirements.toml リファレンスを参照してください。

ローカルクライアントによるクラウド管理要件の適用

以下では、対応するローカルクライアントが要件を読み込み、キャッシュする仕組みを説明します。Work Cloud でローカルコンピューターへのアクセスを使用している実行中のタスクに、クラウドポリシーの変更がいつ反映されるかは、この仕組みだけでは判断できません。変更した制限を前提に運用する前に、実際に適用されているポリシーを確認してください。

対応プランのユーザーが対応するローカルクライアントを起動し、ChatGPT でサインインすると、クライアントはまず、そのユーザーの識別情報に一致する有効なキャッシュエントリがあるかどうかを確認します。有効なエントリがない場合は、必要に応じて再試行しながら該当するバンドルを取得し、成功すると署名付きのキャッシュエントリを書き込みます。リクエストが失敗するかタイムアウトし、有効なキャッシュもない場合、クラウド構成バンドルの読み込みはエラーを返します。クラウドで管理する要件レイヤーを省いてそのまま起動することはありません。

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

管理者と従業員の利用環境の確認

管理ポリシーごとに責任者を決め、適用対象のユーザーまたはグループを記録します。ファイルシステム、ネットワーク、承認、権限プロファイルに制限を設ける場合は、制限ごとに業務上の理由を文書化してください。

想定した権限を持つユーザーで、許可されるワークフローとブロックされるワークフローをそれぞれテストします。対応するクライアントで、実際に有効な設定を確認してください。ワークスペースのロールやグループだけでは、ローカルでの実行時の制限を強制できません。

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

デバイス管理による構成の配布

認証の制限とデバイス管理ポリシーの設定には、ローカルシステムの要件または MDM を使います。従来の managed_config.toml とエージェントセキュリティのデフォルトでは、起動時の優先順位が異なります。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 の設定については、要件リファレンスを参照してください。

OpenTelemetry 設定の強制

Codex CLI 0.166.0 では、[otel] を requirements.toml に記述すると、ログ、トレース、メトリクスのエクスポーターを個別に設定し、環境にラベルを付け、Codex がエクスポートする内容を指定できます。次の例では、ログを OTLP/HTTP コレクターに送信します。各ツールの実行結果について、ログに記録するテキストの上限は UTF-8 で 256 バイトです。プロンプトの本文、最終応答の本文、承認リクエストの自動レビューによる評価は記録しません。

macOS デスクトップアプリ 26.1027.30824 には、CLI 0.166.0-alpha.5.1 が同梱されています。このビルドでは [otel] を requirements.toml で指定できないため、このポリシーで log_user_prompt = false を強制することはできません。

[otel]
environment = "prod"
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false
log_agent_responses = false
log_guardian_assessments = false
tool_result = { max_bytes = 256 }
span_attributes = { team = "platform" }
tracestate = { acme = { region = "eu" } }

管理対象の値はローカル設定を上書きします。exporter、trace_exporter、metrics_exporter のそれぞれについて、そのエクスポーターを指定した要件のうち、最も優先順位の高い要件の定義が、ヘッダーや TLS 設定も含めて丸ごと適用されます。各スカラー設定と tool_result テーブルについても、それぞれを指定した要件のうち、最も優先順位の高い要件の値が適用されます。省略した項目は、他の要件レイヤーで指定されていない限り、ローカルで設定できます。

スパン属性は属性名ごとに統合されます。tracestate のフィールドは、メンバー名とフィールド名の組み合わせで統合されます。一致するエントリには優先順位の高い値が適用されます。他のエントリは引き続き利用でき、空のメタデータテーブルを指定しても消去されません。エクスポーターのオプションとログの内容については、オブザーバビリティとテレメトリを参照してください。

NFS 上の SQLite データベースの移行

Linux では、Codex は NFS 上に新しい SQLite データベースを作成する際、DELETE ジャーナルモードを使います。先行書き込みログ（WAL）を使う既存のデータベースをこのモードに移行するには、unsafe_enforce_sqlite_journal_mode = true を requirements.toml のトップレベルに設定します。この設定はデフォルトでは無効です。有効にすると、Codex はデータベースを書き込み用に開く前に移行します。

NFS マウントは、ホスト間での POSIX ロックに対応している必要があります。nolock や local_lock=all などのマウントオプションを指定すると、ホスト間でロックが機能しません。すべてのホストで、対象のデータベースを使うすべての SQLite クライアント（Codex を含む）を停止してください。その後、Codex のインスタンスを 1 つだけ起動し、移行が成功するまで他のクライアントはすべて停止したままにしてください。このインスタンスを実行するユーザーには、データベースのディレクトリと移行用ロックへの書き込み権限が必要です。移行後のファイルは元の Unix パーミッションビットを引き継ぎ、このユーザーが所有します。元の所有者、グループ、拡張アクセス制御リストは引き継がれません。Codex は元のファイルを非公開のバックアップディレクトリに保存します。

管理対象のデフォルト（managed_config.toml）

クラウド管理に対応している設定の初期値は、エージェントセキュリティのデフォルトで指定してください。ここでは、デバイス側の managed_config.toml で初期値を管理する従来の仕組みと、クラウド管理とは異なる起動時の優先順位について説明します。エージェントセキュリティでデフォルトを編集しても、メンバーのデバイスに managed_config.toml ファイルは配布されません。

管理対象のデフォルトは、対応するローカルクライアントが起動時に使う設定を決めます。起動時には、ユーザーのローカルの config.toml や CLI の --config で指定した値よりも、管理対象のデフォルトが優先されます。ユーザーは実行中にこれらの設定を変更できますが、次にクライアントを起動すると、管理対象のデフォルトが再び適用されます。

ChatGPT でサインインして Codex を利用する場合、GPT-5.5 の提供は 2026 年 10 月 14 日正午（PDT、19:00 UTC）に終了します。管理対象のデフォルト、macOS MDM プロファイル、または保存済みの構成で、対象ユーザーが使うモデルを gpt-5.5 に固定している場合は、利用可能なモデルに切り替えてください。gpt-6.1-sol は、管理者が対象ユーザー向けに有効にしてから選択してください。OpenAI API と、API キーで認証する 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 = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false            # keep prompts redacted

推奨ガードレール

• ほとんどのユーザーには、workspace-write と承認を組み合わせた設定を推奨します。フルアクセスは管理されたコンテナに限定してください。
• セキュリティレビューでコレクターまたはワークフローに必要なドメインへのアクセスが許可されている場合を除き、network_access = false のままにしてください。
• テレメトリ設定を強制するには、OpenTelemetry の要件を使います。ポリシーでプロンプトの内容を保存することが許可されている場合を除き、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 設定と同様に変更管理の対象としてください。