管理対象の設定

管理対象の設定では、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. macOS の管理対象環境設定（MDM）： com.openai.codex:requirements_toml_base64 を通じて配信

優先順位の高いレイヤーは、 低いレイヤーの通常のスカラー値とリスト値を上書きします。テーブルはキーごとにマージされますが、 ルール、フック、ファイルシステムの制限などの要件は、フィールドごとに合成動作が異なります。 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 の例

この例では、--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 が無効化されます。 このキーを省略すると、要件による Appshots の制限はなく、 通常の製品の利用可否チェックが適用されます。 configRequirements/read を通じて適用中の要件を読み取る App Server クライアントは、 allowAppshots として同じ制限を受け取ります。値が null の場合や allowAppshots が省略されている場合は、 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 になるのは、:workspace と :read-only の両方が明示的に許可されている場合に限られます。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 セッションでもライブウェブ検索は実行できません。

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

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

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

experimental_network.managed_allowed_domains_only = true は、 管理者が管理する allowed_domains も定義し、 その許可リストだけを適用する場合にのみ使用してください。管理対象の許可ルールがない状態で true に設定すると、 ユーザーが追加したドメイン許可ルールは無効になります。

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

これらの要件は、サンドボックス内で実行されるローカルコマンドにのみ適用されます。ウェブ検索、アプリとコネクタ、MCP サーバー、ブラウザやコンピューターの使用に関するアクティビティ、Codex サービスへのリクエスト、Codex Cloud のトラフィックをルーティングしたりフィルタリングしたりすることはありません。対象ごとに次の制御を使用してください：

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

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

機能フラグの固定

機能フラグは、 管理対象の 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

この要件によってコンピューターの使用が有効になることはありません。macOS でのロック中の使用を禁止するだけです。この要件を省略した場合、ロック中の使用に対する要件上の制限はなく、製品の通常の提供状況とユーザーのローカル設定が引き続き適用されます。

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

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 またはエンドポイント管理ツールによって、 参照先のスクリプトがインストールされるディレクトリを指定します。

ローカルでフックを無効にしたユーザーにも管理対象フックを強制適用するには、 [features].hooks = true を [hooks] とあわせて固定します。ユーザー、プロジェクト、セッション、 プラグインの各フックをスキップしつつ、管理対象フックは引き続き許可するには、 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 を照合し、 streamable 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 サーバーを無効にします。

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

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

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 やモバイル版 ChatGPT でのプラグインの使用を制御するものではなく、IDE 拡張機能にプラグインを追加するものでもありません。

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

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

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 キーで認証した 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 と管理対象のポリシーの差分を定期的に監査してください。管理対象レイヤーがローカルのフラグやファイルより優先されるようにしてください。