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

管理対象の構成

管理対象の構成

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

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

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

  • 要件: 管理者が強制する制約で、ユーザーは上書きできません。
  • デフォルト設定: システムまたはクラウドで管理される config.toml の設定で、ユーザーは上書きできます。
  • 従来のマネージドデフォルト設定: サポート対象のクライアントの起動時に適用される managed_config.toml の初期値です。ユーザーは実行中も設定を変更できますが、次回の起動時にクライアントがこれらのデフォルト値を再適用します。

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

ローカルまたは Git のマーケットプレイスとプラグインのデフォルト設定は、システムの config.toml またはマネージド設定の config.toml セクションで定義します。 これらの設定はデフォルト値であり、強制されるポリシーではありません。

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

管理者によって適用される要件（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 セクションを参照してください。

廃止された 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承認ポリシーからの移行 を参照してください。

場所と優先順位

サポート対象の各ローカルクライアントは、低いものから高いものへ、次の優先順位で要件を合成します。

  1. システムの requirements.toml（Linux と macOS を含む Unix システムでは /etc/codex/requirements.toml、Windows では %ProgramData%\OpenAI\Codex\requirements.toml）。
  2. クラウド構成バンドルで配信される、Enterprise 管理対象の要件。
  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" },
]

管理対象のすべてのクライアントバージョンが、選択したキーをサポートしていることを確認し、組織全体に割り当てる前に少人数のグループでポリシーをテストしてください。現在のスキーマについては構成リファレンスを、現在の割り当て動作については管理画面を参照してください。

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

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

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

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

キャッシュを解決した後、クライアントはクラウド要件を、上記で説明した他の要件レイヤーと合成します。バックグラウンド更新では、後の起動に備えてキャッシュを更新できますが、現在のプロセスにすでに読み込まれた要件が置き換えられることはありません。

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

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

ロールアウトを拡大する前に、代表的なユーザーを使って、承認済みのワークフローと意図的に許可しないワークフローをテストしてください。ワークスペースのロールやグループだけでローカルの制限が適用されると想定せず、サポート対象のクライアントで有効な設定を確認してください。

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

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の設定については、要件リファレンス を参照してください。

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"が 明示的な設定としてサポートされるようになるわけではありません。

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

Web 検索モードを制約することもできます。

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

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

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

管理者がネットワークアクセス要件を一元的に定義する必要がある場合は、 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 リバインディングの制限は、エージェントの承認とセキュリティで説明されているサンドボックスのネットワーク動作と同じです。

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

  • Web 検索を制限するには、allowed_web_search_modes を使用します。
  • アプリとコネクターの連携を無効化するには features.apps = false を使用し、サポートされている環境でプラグインを無効化するには features.plugins = false を使用します。
  • MCP serverを制限するには、管理対象の mcp_servers 承認済みリストを使用します。
  • ブラウザと Computer Use の機能を制限するには、browser_use、in_app_browser、 computer_use などの機能要件を使用します。
  • Codex クラウドのネットワークアクセスは、クラウド環境設定で構成します。

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

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

サポート対象のデスクトップクライアントを制限するには、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 ポリシーでは Calculator を許可し、保存済みの承認を禁止します。

[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 は任意です。表示名だけでなく、アプリの検証済み ID を使用してください。

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

機能フラグを固定する

管理対象の 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 は、ブラウザでの Computer Use と Browser Agent の利用を無効化します。
  • browser_use_full_cdp_access = false は、Browser Developer モードを含む、ローカルランタイムでの完全な CDP アクセスを無効化し、ChatGPT デスクトップアプリで対応する設定を有効化できないようにします。
  • browser_use_external = false は、外部の Browser Use を無効化します。
  • computer_use = false は、Computer Use、Record & Replay、および関連するインストールまたはセットアップフローを無効化します。

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

ロックされたコンピューター使用を制限する

管理対象の Mac でユーザーが Locked Use を有効化できないようにするには、次の要件を追加します。

[computer_use]
allow_locked_computer_use = false

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

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

自動レビューを必須または許可するには、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] を使用し、参照先のスクリプトを 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 および他の管理対象構成レイヤーからのフックは引き続き読み込みます。

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

管理者は、[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を無効化します。

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

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

features.plugins = false

この設定は、ユーザーが API key で 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マーケットプレイスの更新操作を拒否します。また、実行時には設定済みの マーケットプレイスとそのプラグインもフィルタリングします。

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 拡張機能にプラグインを追加するものでもありません。

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

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

管理対象のデフォルト設定、macOS MDM プロファイル、または保存済みの設定で、 ChatGPT にサインインしている Codex ユーザーのモデルが gpt-5.5 に固定されている場合は、 2026 年 10 月 14 日までに gpt-5.6-sol に置き換えてください。GPT-5.5 はその日に ChatGPT、 ChatGPT Work、Codex のすべてのプランで提供を終了します。OpenAI API には 影響しません。ワークスペースでのモデルの提供状況を参照してください。

ChatGPT でサインインしているユーザーについて、管理対象のデフォルト、macOS MDM プロファイル、または保存済み構成で 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 key で認証された Codex は影響を受けません。ワークスペースでのモデルの利用可否を参照してください。

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

優先順位とレイヤー

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

  • 管理対象環境設定（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

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

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