For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション

おすすめ

はじめに

ChatGPT Work

ID と認証

ワークスペースのアクセス、ポリシー、モデル

プラグインとコネクタの制御

利用状況、ガバナンス、コンプライアンス

展開とモデルプロバイダー

API Dashboard
ChatGPT を試す

管理対象の設定

対応するローカルクライアント全体にデフォルト設定を配布し、要件を適用

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

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

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

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

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

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

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

廃止された untrusted 承認ポリシーからの移行

Codex と ChatGPT Work は、approval_policy = "untrusted" をサポートしなくなりました。 管理対象のデフォルト設定、従来の managed_config.toml、およびこの値を設定しているユーザー、 プロジェクト、プロファイル、起動時の各構成から削除してください。

対話形式で読み取り専用の操作を行う場合は、approval_policy = "on-request" を選択し、 管理対象の要件で許可された読み取り専用のサンドボックスまたは権限プロファイルと組み合わせてください。 そのサンドボックスで許可されるコマンドは、承認なしで実行できます。

コマンドに対するより厳格な承認動作を維持するには、approval_policy を明示的に指定せず、 ユーザーレベルの ~/.codex/config.toml にあるプロジェクトのエントリに trust_level = "untrusted" を設定し、 allowed_approval_policies に untrusted を残してください。 これにより、プロジェクトローカルの設定も無効になります。on-request を明示的に設定すると、 そのポリシーは上書きされます。例とセキュリティ上のトレードオフについては、 廃止された untrusted 承認ポリシーからの移行を 参照してください。

保存場所と優先順位

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

  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 アカウントでサインインすると、クライアントはまず、ユーザーの識別情報と一致する有効なキャッシュエントリがあるかを確認します。有効なエントリがない場合は、必要に応じて再試行しながら該当するバンドルを取得し、成功すると署名付きのキャッシュエントリを書き込みます。リクエストが失敗またはタイムアウトし、有効なキャッシュもない場合、クラウド構成バンドルの読み込みはエラーを返します。クラウドで管理される要件レイヤーを適用せずに、通知なく起動することはありません。

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

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

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

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

ローカルでの認証管理

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 にするのは、:workspace と :read-only の両方が明示的に許可されている場合だけです。allowed_permission_profiles がない場合、 管理対象の要件によってユーザーが選択できるプロファイル名が制限されることはありません。 各エントリには、組み込みプロファイル、または読み込まれた構成や要件のソースで定義されているカスタムプロファイルの名前を指定する必要があります。 動作を一元管理するには、 管理対象の要件でカスタムプロファイルを定義します。

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

単一の管理対象ポリシーでホストごとに異なるサンドボックス要件を適用するには、[[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] は実験的な機能であり、変更される可能性があります。 これらの要件を企業の環境で広く有効にする前に、 ユーザーが利用するローカルクライアントのバージョンとオペレーティングシステムで検証してください。 Windows のサポートはまだ限定的です。 利用環境でテストを済ませるまでは、Windows ユーザーへの適用を避けてください。

管理者がネットワークアクセス要件を一元的に定義するには、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 は apex ドメインとそのサブドメインに一致します。 拒否ルールに一致した場合は、許可ルールより拒否ルールが優先されます。

ドメインの構文、ローカルおよびプライベートな宛先のルール、許可より拒否を優先する動作、 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 マーケットプレイスの更新操作を拒否します。また、実行時に、設定済みのマーケットプレイスとそのプラグインをフィルタリングします。

API キー用カタログを含め、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 による上書き設定よりも優先されます。 ユーザーは現在の実行中にこれらの設定を変更できますが、 次回クライアントを起動すると、デフォルト値が再び適用されます。

ChatGPT でサインインしている Codex ユーザーに対して、管理対象のデフォルト値、macOS MDM プロファイル、または保存済みの設定で 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 キーで認証した 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 と管理対象のポリシーの差分を定期的に監査してください。管理対象のレイヤーは、ローカルのフラグやファイルよりも優先される必要があります。