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

マネージド構成

対応するローカルクライアント全体にランタイム要件を適用し、管理されたデフォルト値を配布します

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

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

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

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

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

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

Codex 0.138.0以降では、allowed_permission_profilesとマネージドdefault_permissionsを備えた 権限プロファイルを推奨します。 sandbox_modeを引き続き設定しているレガシーデプロイに限り、 allowed_sandbox_modesを使用してください。

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

場所と優先順位

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

  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を置き換えたりするものではありません。

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

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

対応するキーと例については、 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を通じて有効な要件を読み取る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"

Enterprise定義のプロファイルのみを許可する

ユーザーが管理者定義のプロファイルのみを選択できるようにする場合は、すべての組み込みプロファイルを省略します。

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

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.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リバインディングの制限は、エージェントの承認とセキュリティで説明されている サンドボックスネットワークの動作と同じです。

機能フラグを固定する

マネージド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がロックされた後に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]を使用し、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およびほかの マネージド構成レイヤーのフックは引き続き読み込みます。

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

管理者は、[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サーバーを制限するには、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>配下で同じID形式を使用します。

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

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

対応するローカルクライアントでプラグインを無効にするには、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マーケットプレイスの更新操作を拒否します。 Codexが管理するOpenAIマーケットプレイスは、そのソースと 予約名が一致する場合、引き続き利用できます。これらの要件は、すでに設定済みのユーザー マーケットプレイスやそのプラグインを実行時にフィルタリングしません。

これらのソース制限は、ローカルクライアントがプラグイン マーケットプレイスの操作に対応する環境（ChatGPT Work、デスクトップアプリ内のCodex、 Codex CLI）にのみ適用されます。Chat、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 keyで認証された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. その文字列を、com.openai.codexドメイン配下のconfig_toml_base64（マネージドデフォルト）またはrequirements_toml_base64（要件）にあるMDMプロファイルへ設定します。
  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とマネージドポリシーの差分を定期的に監査し、ドリフトを検出します。マネージドレイヤーはローカルのフラグやファイルより優先される必要があります。