管理対象の設定

管理対象の設定では、ChatGPT デスクトップアプリ、Codex CLI、IDE 拡張機能の対象機能について、対応するローカルランタイムの動作を制御します。対応する要件は、クライアントやバージョンによって異なる場合があります。管理対象の設定によって、ChatGPT ワークスペースへのアクセス権が付与されたり、シートが割り当てられたり、ワークスペースのロールベースのアクセス制御（RBAC）が置き換えられたりすることはありません。ワークスペースの機能へのアクセスについてはロールとワークスペースの権限を、ローカルランタイムのポリシーについてはこのページを参照してください。

エンタープライズ管理者は、対応するローカルクライアントの動作を次の 2 つの方法で制御できます：

• 要件：管理者が強制適用する、ユーザーが上書きできない制約
• 管理対象のデフォルト値：対応するクライアントの起動時に適用される初期値です。ユーザーは実行中に設定を変更できますが、クライアントは次回の起動時に管理対象のデフォルト値を再適用します。

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

要件は、セキュリティ上重要な設定を制限します。対象となるのは、承認ポリシー、承認リクエストのレビュアー、自動レビューポリシー、サンドボックスモード、権限プロファイル、ウェブ検索モード、管理対象のフック、ユーザーが有効化できる MCP サーバー、およびユーザー設定のプラグインマーケットプレイスソースのうち、追加、インストール元としての使用、更新を許可するものです。設定の解決時に、たとえば config.toml、プロファイルファイル、CLI による設定の上書きから取得した値が強制適用されるルールと競合すると、ローカルクライアントは適合する値にフォールバックし、ユーザーに通知します。mcp_servers の許可リストを設定した場合、クライアントは名前と識別情報の両方が承認済みエントリと一致するときにのみ MCP サーバーを有効化し、それ以外の場合は無効化します。

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

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

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

配置場所と優先順位

対応する各ローカルクライアントは、優先順位の低いものから高いものへと、次の順序で要件を統合します：

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 を使用してください。

クラウド管理の要件

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

管理対象の設定を開き、 クラウド管理の要件を作成して割り当てます。たとえば、次のポリシーは承認とサンドボックスの選択肢を制限し、 対応するシェルのエントリーポイントを実行する前に 確認を求めます：

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 リファレンスを参照してください。

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

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

キャッシュの解決後、クライアントはクラウドの要件を、前述のほかの要件レイヤーと統合します。バックグラウンドでの更新により、次回以降の起動に使用するキャッシュが更新されることがありますが、現在のプロセスに読み込み済みの要件は置き換えられません。

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

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

展開範囲を広げる前に、代表的なユーザーとともに、承認済みのワークフローと、意図的に禁止したワークフローをテストしてください。ワークスペースのロールやグループだけでローカルの制限が強制適用されると想定せず、対応するクライアントで実際に適用されている設定を確認してください。

ローカルでの認証管理

ローカルシステムの requirements.toml または macOS MDM の要件に、 allowed_login_methods、allowed_chatgpt_workspaces、 cli_auth_credentials_store、chatgpt_base_url を設定してください。 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 の設定については、 要件リファレンスを参照してください。

requirements.toml の例

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

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

Appshots の無効化

管理対象ユーザーの Appshots を無効にするには、トップレベルの allow_appshots 要件を設定します：

allow_appshots = false

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

デバイスのリモート操作の無効化

管理対象ユーザーのデバイスのリモート操作を無効にするには、 トップレベルの allow_remote_control 要件を設定します：

allow_remote_control = false

デバイスのリモート操作に対応している環境では、allow_remote_control = false によって無効化されます。 このキーを省略すると、要件によるデバイスのリモート操作の制限はなく、 通常の製品の利用可否チェックが適用されます。 この要件によって SSH リモート接続が無効化されることはありません。

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

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 がない場合、管理対象の要件は、ユーザーが選択できるプロファイル名を制限しません。 各エントリには、組み込みプロファイルか、読み込み済みの設定または要件ソースで定義された カスタムプロファイルの名前を指定する必要があります。 カスタムプロファイルの動作を一元管理するには、管理対象の要件内で定義してください。

ホスト別のサンドボックス要件の上書き

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 を維持します。 ホスト名の照合はポリシーの選択にのみ使用します。 デバイスが認証済みであることの証明として扱わないでください。

ウェブ検索モードも制限できます。

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

allowed_web_search_modes = [] は "disabled" のみを許可します。 たとえば、allowed_web_search_modes = ["cached"] を設定すると、danger-full-access セッションでもライブウェブ検索を実行できなくなります。

ネットワークアクセス要件の構成

管理者がネットワークアクセス要件を一元的に定義するには、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 サーバー、ネイティブアプリの通信、Codex サービスへのリクエスト、Codex Cloud の通信をフィルタリングしません。それぞれに対応する制御を使用してください。

• ウェブ検索を制限するには、allowed_web_search_modes を使用します。
• アプリとコネクタの連携を無効にするには features.apps = false を、 対応環境でプラグインを無効にするには features.plugins = false を使用します。
• MCP サーバーを制限するには、管理者が設定する mcp_servers の承認済みリストを使用します。
• ブラウザやコンピューターの使用機能を制限するには、browser_use、in_app_browser、 computer_use などの機能要件を使用します。
• Codex Cloud のネットワークアクセスは、そのクラウド環境の設定で構成します。

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

ブラウザとコンピューターの使用の制御

対応するデスクトップクライアントを制限するには、requirements.toml の [browser_use] テーブルと [computer_use] テーブルを使用します。 導入環境のクライアントバージョンと オペレーティングシステムでポリシーを検証してください。許可ルールを設定しても、 プラグインのインストール、オペレーティングシステムの権限付与、 引き続きレビューが必要な操作の承認は行われません。

ブラウザアクセスには、オリジンポリシーを構成します。 オリジンは https://example.com や https://*.example.com:8443 のように、スキーム、ホスト、任意のポートで構成されます。 パス、クエリ、フラグメントは含めないでください。 コマンドのネットワーク通信に対するドメインルールとは異なり、ブラウザのオリジンルールは HTTP と HTTPS を区別し、 ポートも照合します。

次の例では、ブラウザアクセスを承認済みサイトに制限し、そのサイトでのアップロードと Chrome DevTools Protocol（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" を設定します。 これは承認の処理方法を制御する設定であり、 モデルの安全性監視を無効にするものではありません。

ネイティブアプリについては、デフォルトのアクセスポリシーを設定し、許可するアプリを指定します。たとえば、次の 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 は任意です。 表示名だけでなく、検証済みのアプリ識別情報を使用してください。

すべてのフィールドについては構成リファレンスを、 管理対象の macOS デバイスについてはロック中の使用の制限を 参照してください。

機能フラグの固定

管理者が設定した requirements.toml を受け取るユーザーに対して、 機能フラグを固定することもできます。

[features]
personality = 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 またはプロファイルファイルの機能設定に対する、 固定値と矛盾する書き込みを拒否します。

• 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 は、コンピューターの使用、記録と再生、 関連するインストールやセットアップのフローを無効にします。

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

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

管理対象の Mac でユーザーがロック中の使用を有効にできないようにするには、 次の要件を追加します。

[computer_use]
allow_locked_computer_use = false

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

自動レビューポリシーの構成

自動レビューを必須にする、または許可するには、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.
"""

読み取り拒否要件の適用

管理者は [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 は直接ファイルを操作するツールに適用されます。 シェルのサブプロセスによる読み取りには、このサンドボックスルールは使用されません。

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

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

ローカルでフックを無効にしたユーザーにも管理対象フックを強制適用するには、 [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 や その他の管理対象構成レイヤーからのフックは引き続き読み込みます。

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

管理者は、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 が存在していても空の場合、ローカルクライアントはすべての MCP サーバーを無効にします。

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

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

features.plugins = false

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

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

ユーザーが設定したマーケットプレイスのソースに対する操作を制限するには、 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 マーケットプレイスの更新のうち、ルールに一致しない操作が拒否されます。Codex が管理する OpenAI マーケットプレイスは、ソースと予約名が一致していれば引き続き利用できます。これらの要件は、設定済みのユーザーマーケットプレイスやそのプラグインを実行時にフィルタリングするものではありません。

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

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

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

管理対象のデフォルト設定、macOS MDM プロファイル、または保存済みの設定で、ChatGPT にサインインしているユーザーのモデルを gpt-5.4 または gpt-5.4-mini に固定している場合は、 2026 年 8 月 31 日より前に更新してください。gpt-5.4 を gpt-5.6-terra に、gpt-5.4-mini を gpt-5.6-luna に置き換えます。 OpenAI API と、ご自身の API キーで認証した Codex は影響を受けません。 ワークスペースでの モデルの提供状況を参照してください。

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

優先順位とレイヤー構成

ローカルランタイムは、次の優先順位で実効設定を組み立てます（上位の設定が下位の設定を上書きします）。

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

CLI の --config key=value による上書きは基本設定に適用されますが、管理対象のレイヤーがそれをさらに上書きします。そのため、ローカルでフラグを指定しても、実行のたびに管理対象のデフォルト設定で起動します。

クラウド管理の要件は、管理対象のデフォルト設定ではなく、要件レイヤーに作用します。優先順位については、上記の「管理者が強制する要件」セクションを参照してください。

保存場所

• Linux/macOS（Unix）：/etc/codex/managed_config.toml
• Windows／非 Unix：~/.codex/managed_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 設定と同様に変更管理の対象として扱ってください。

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 と管理対象のポリシーの差分を定期的に監査し、設定のずれを検出してください。管理対象のレイヤーが、ローカルのフラグやファイルよりも優先される必要があります。