管理対象構成¶

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

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

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

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

要件は、セキュリティに関わる設定（承認ポリシー、承認レビュアー、自動レビューポリシー、サンドボックスモード、権限プロファイル、Web 検索モード、管理対象フック、ユーザーが有効化できる MCP サーバー、ユーザーが構成したプラグインマーケットプレイスのソースのうち、追加、インストール、更新を許可するもの）を制約します。構成を解決するとき（たとえば config.toml、プロファイルファイル、または CLI 構成の上書きから解決する場合）、値が強制ルールと競合すると、ローカルクライアントは互換性のある値にフォールバックし、ユーザーに通知します。mcp_servers の許可リストを構成した場合、クライアントは名前と ID の両方が承認済みエントリと一致する場合にのみ MCP サーバーを有効化します。それ以外の場合、クライアントは無効化します。

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

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

キーの完全な一覧については、Configuration Reference の requirements.toml セクションを参照してください。

場所と優先順位¶

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

システム requirements.toml（Unix システムでは /etc/codex/requirements.toml、Linux と macOS を含む、Windows では %ProgramData%\OpenAI\Codex\requirements.toml）。
クラウド構成バンドルで配信される、エンタープライズ管理の要件。
ローカルクライアントが要件として再解釈するレガシー managed_config.toml フィールド。
com.openai.codex:requirements_toml_base64 を介して配信される macOS の管理対象環境設定（MDM）。

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

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

クラウド管理の要件¶

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

管理対象構成を開いて、クラウド管理の要件を作成し、割り当てます。たとえば、このポリシーでは、サポートされるクライアントに米国のデータレジデンシーの使用を要求し、承認とサンドボックスの選択肢を制限し、サポートされるシェルのエントリポイントが実行される前に確認を求めます。

enforce_residency = "us"
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 に適用されるエンタープライズ管理要件のレイヤーを選択します。ローカルクライアントは、場所と優先順位で説明されている他の要件ソースとともに、これらのレイヤーを評価します。ワークスペース側での作成と割り当てには、現在の管理画面を使用してください。コピーしたグループ一致アルゴリズムに依存しないでください。管理サービスがその動作を管理しており、ローカル要件の形式とは独立して変更される可能性があります。

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

ローカルクライアントがクラウド管理の要件を適用する方法¶

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

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

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 を介して有効な要件を読み取るアプリサーバークライアントには、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 と :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 検索が実行されなくなります。

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

[experimental_network] は試験的なものであり、変更される可能性があります。ローカルクライアントのバージョンと、ユーザーが実行するオペレーティングシステムで検証せずに、エンタープライズデプロイメント全体でこれらの要件を広く有効にしないでください。Windows のサポートはまだ限定的です。環境でテストしていない限り、このポリシーを Windows ユーザーに適用しないでください。

管理者がネットワークアクセス要件を中央で定義する場合は、requirements.toml の [experimental_network] を使用します。これらの要件は、ユーザーの features.network_proxy トグルとは別です。機能フラグがなくてもサンドボックスネットワークを構成できますが、アクティブなサンドボックスでネットワークが無効になっている場合に、コマンドのネットワークアクセスを付与することはありません。

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

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

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

機能フラグを固定する¶

管理対象の 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
computer_use = false

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

in_app_browser = false は組み込みブラウザペインを無効にします。
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 がロックされた後に Computer Useが動作するのを防ぐには、次の要件を追加します。

[computer_use]
allow_locked_computer_use = false

この要件によって Computer Use が有効になることはありません。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] を使用し、参照されるスクリプトを 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 およびその他の管理対象構成レイヤーからフックを読み込みます。

要件からコマンドルールを強制する¶

管理者は、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> の下で同じ ID 形式が使用されます。

mcp_servers が存在するものの空の場合、ローカルクライアントはすべての MCP サーバーを無効にします。

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

ユーザーが構成したマーケットプレイスソースに対する操作を制限するには、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 デスクトップアプリの Work モードと Codex、および Codex CLI です。Chat、IDE 拡張機能、モバイルにはプラグインを追加しません。

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

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

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

優先順位とレイヤー¶

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

管理対象環境設定（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 などのツールで設定を配布できます。簡単なデプロイメントは次のようになります。

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

ペイロードにシークレットや頻繁に変化する動的な値を埋め込まないでください。管理対象 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 と管理対象ポリシーの差分を定期的に監査し、ドリフトを検出してください。管理対象レイヤーはローカルのフラグやファイルより優先されます。