Codex セキュリティクックブック

従業員に会社の ChatGPT ワークスペースを通じて Codex にサインインさせ、管理対象のエンドポイントでは個人の ChatGPT アカウントと API key による認証を禁止する場合に、このレシピを使用します。

目指す結果

会社が管理するデバイスでは、Codex は会社の ChatGPT ワークスペースへの ChatGPT サインインのみを受け付けます。

前提条件

• 承認済みの ChatGPT Enterprise ワークスペースの UUID。

• Codex の管理対象の設定をエンドポイントに配布する手段。

• 管理対象のエンドポイントで API key による認証を禁止するという方針。

設定

1. 承認済みワークスペースの UUID を社内の設定リポジトリに記録します。

2. ローカルの requirements.toml に、強制適用する認証要件を追加します。

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

最初のキーは ChatGPT 認証のみを許可し、2 番目のキーはサインイン先を承認済みワークスペースに限定します。例の UUID を自分のワークスペースの UUID に置き換えてください。要件リファレンスを参照してください。

3. 設定の配置先に記載されたパスを使用し、ローカルの requirements.toml または macOS MDM の要件として展開します。これらの認証要件は、認証情報の読み込み前、およびクラウドポリシーの取得前に適用されます。クラウド管理の要件に含まれていても、Codex は無視します。ファイルとその親ディレクトリをユーザーによる変更から保護してください。従来の managed_config.toml のデフォルト設定では、この制限は強制適用されません。

4. 試験導入中は、ユーザーをサインアウトさせるか、保存済みの個人用 Codex セッションを削除します。新しいポリシーが既存のセッションを遡って無効にするとは考えないでください。

5. ログイン制限を、ワークスペースのロールやグループアクセスと組み合わせます。認証はサインインする ID を制御し、RBAC はその ID が使用できる Codex の機能を制御します。認証を参照してください。

検証

• Codex からサインアウトします。

• 個人の ChatGPT アカウントでサインインを試みます。期待される結果：個人用ワークスペースへのサインインが拒否されます。

• Codex で API key によるログインを試みます。期待される結果：API key によるログインが拒否されます。

• 会社のアカウントで承認済みワークスペースにサインインします。期待される結果：サインインが成功します。

• デスクトップアプリ、CLI、IDE 拡張機能を再起動して、同じ確認を繰り返します。

ロールバック

以前のローカル認証要件を復元し、レビュー済みのバンドルを再展開します。

制御の範囲と限界

この設定は、管理対象のエンドポイント上にある管理対象の Codex クライアントを制御します。「会社の資産から個人用の Codex を使用させない」ことが要件である場合は、エンドポイントのアプリケーション制御やネットワークポリシーと組み合わせてください。

開発者に読み取り専用またはワークスペース内に限定したアクセスが必要であり、Full Access の選択や、--yolo による承認とサンドボックスの回避を防ぎたい場合に、このレシピを使用します。

目指す結果

ユーザーは、承認済みの読み取り専用またはワークスペース内に限定したプロファイルのみを選択できます。danger-full-access、approval_policy = "never"、--yolo は選択できません。

設定

1. 承認済みのワークスペースプロファイルを定義します。

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. 許可するプロファイルと承認ポリシーを強制適用します。

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

この許可リストは網羅的に適用されます。リストに含まれないプロファイルや false に設定されたプロファイルは、今後のバージョンで追加されるものも含めて拒否されます。設定リファレンスを参照してください。

3. sandbox_mode を引き続き使用する従来のクライアントでは、次を使用します。

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. ユーザーが編集できる設定ファイルではなく、管理者が強制適用する要件として配信します。

5. 後で自動レビューを許可する場合は、テストしたうえで明示的に追加します。自動レビューは、境界を越える操作を誰がレビューするかを変えるものであり、取り除かれた境界を復元するものではありません。自動レビューを参照してください。

検証

• 権限の選択メニューを開きます。期待される結果：Full Access が選択不可になるか、拒否されます。

• --dangerously-bypass-approvals-and-sandbox を指定して起動します。期待される結果：Codex が起動を拒否するか、互換性のあるプロファイルを強制します。

• --sandbox danger-full-access --ask-for-approval never を指定して起動します。期待される結果：起動が拒否されます。

• 通常のワークスペース内のタスクを実行します。期待される結果：タスクは成功し、境界を越える操作には引き続き承認が必要です。

ロールバック

以前の要件バンドルを復元します。別途承認された例外がない限り、無制限のアクセスは引き続きブロックしてください。

制御の範囲と限界

この設定は Codex の実行時の権限を制御します。特権を持つ OS アカウントを非特権アカウントに変えるものではありません。

Codex が使用できる MCP serverを組織で決定し、承認済みリストを強制適用する必要がある場合に、このレシピを使用します。

サーバーの許可と設定は別々の手順です。許可リストのエントリは、一致するサーバーの利用を許可しますが、サーバー設定を作成するものではありません。一致する名前と識別情報、および必要な認証を使って、サーバーを別途設定してください。

目指す結果

Codex は、設定された名前と識別情報が企業の承認済みリストに一致する MCP serverのみを有効にします。

設定

1. 承認済みサーバーごとに、所有者、目的、トランスポート、正確な実行ファイルまたは URL、認証、データ分類、書き込み機能を持つツールを洗い出します。

2. すべて拒否する設定から始めます。空の管理対象テーブルは、すべての MCP serverを無効にします。

   [mcp_servers]

3. 正確な URL を指定して、承認済みの HTTP サーバーを追加します。

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. 実行ファイルと位置引数を指定して、承認済みの stdio サーバーを追加します。

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

構造化マッチャーは、実行ファイル、引数の数、引数の順序を確認します。cwd、env、env_vars は制約しません。stdio サーバーを承認する前提条件として、起動コンテキスト全体を制御してください。実行ファイルとその依存関係を保護し、信頼できないユーザー設定やプロジェクト設定から、動作を変えうる作業ディレクトリや環境が指定されるのを防ぎます。その境界を独立して強制できない場合は、stdio サーバーを未承認のままにして、レビュー済みの HTTP サーバーを代わりに使用してください。

5. プラグインに同梱された MCP の識別情報は、plugins.<plugin>.mcp_servers.<server> の下に別途追加します。

6. 承認済みリストをレビュー済みの設定リポジトリに保管し、管理者が強制適用する要件として展開します。

クライアントは、名前と識別情報の両方が承認済みエントリに一致する場合にのみ、サーバーを有効にします。管理対象の設定を参照してください。

検証

• 承認済みサーバーを正確に設定します。期待される結果：サーバーが起動します。

• URL の 1 文字を変更します。期待される結果：サーバーが無効になります。

• stdio の引数の数や順序を変更するか、設定された引数ルールに合わない引数を指定します。期待される結果：サーバーが無効になります。許可されたプレフィックスに引き続き一致する値は、許可されたままです。

• 使い捨ての信頼できるプロジェクトで、実行ファイルと引数の一致を維持しながら、無害な cwd、env、env_vars の上書きを試します。識別情報の照合だけでは、これらの上書きは拒否されません。独立した起動コンテキストの制御が危険な上書きを拒否すること、または stdio サーバーが未承認のままであることを確認してください。実際のインジェクション用ペイロードは使用しないでください。

• 未承認の名前を追加します。期待される結果：サーバーが無効になります。

• プラグインに同梱されたサーバーをテストします。期待される結果：承認済みの識別情報でのみサーバーが動作します。

ロールバック

新しく追加したエントリを削除します。すべての MCP 利用を直ちに停止するには、空の mcp_servers テーブルを展開します。

制御の範囲と限界

識別情報の許可リストは、サーバーのツール、上流のデータ、認証情報、起動環境の安全性を証明するものではありません。ローカルの stdio MCP プロセスは、ローカルコマンドのサンドボックスの外部で実行されます。実行ファイルと引数が一致していても、サーバーのアクセスを制限したり、環境に基づくコードの読み込みを防いだりすることはできません。起動コンテキスト全体とサーバーの権限を独立してレビューしてください。MCP の識別情報に関する要件を参照してください。

セキュリティチームが、エンドポイントやネットワーク内で Codex が何をしているかを把握する必要がある場合に、このレシピを使用します。実行イベントとツールイベント、承認判断、ワークスペースの監査記録、ネットワークログを調査のために集約します。

目指す結果

セキュリティチームは、モデル自身の説明に頼らずに、Codex の実行、ツールに関する判断、承認、ワークスペースの監査記録、実際の外向きネットワーク通信を関連付けられます。

4 つの証拠ソースを使用する

1. Codex OpenTelemetry：実行、API、モデル、サンドボックス、承認、ツールのイベント。

2. 管理対象のライフサイクルフック：ツールの使用と権限リクエストに関するエンドポイント側の記録。

3. ネットワークプロキシまたはゲートウェイのログ：実際の DNS/HTTP 接続先と接続結果。

4. Compliance API：ワークスペースレベルの監査記録と調査記録。

単一のソースだけでは、ネットワークを完全には監視できません。

設定

1. 生のプロンプトを秘匿した状態で、Codex OpenTelemetry ログをコレクターに送信します。

   [otel]
   environment = "enterprise"
   log_user_prompt = false

   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

クライアントを起動する前に、承認済みのシークレットマネージャーまたはプロセス環境を通じて、Codex プロセスに OTLP_TOKEN を渡します。トークンを、展開する TOML ファイルやソース管理に含めないでください。

Codex は、会話の開始、API リクエスト、ストリーミングイベント、プロンプトのメタデータ、ツールに関する判断、ツールの結果を出力できます。高度な設定を参照してください。

2. OTel をプロジェクトローカルの設定の外部に配置します。プロジェクトの .codex/config.toml ファイルは、テレメトリの送信先を上書きできません。

3. SessionStart、PreToolUse、PermissionRequest、PostToolUse、Stop、SessionEnd 用の管理対象ライフサイクルフックを追加します。

4. フックスクリプトを管理者が管理するディレクトリにインストールします。ユーザー、プロジェクト、プラグインのフックを無視する必要がある場合は、allow_managed_hooks_only = true を設定します。

5. サンドボックス内のコマンド通信を、独立してログを記録するプロキシ経由にします。OTel はツールが実行されたことを記録し、プロキシはサブプロセスが接続を試みた宛先を記録します。

6. ウェブ検索、アプリ、コネクター、MCP server、ブラウザのアクティビティ、Codex Cloud のテレメトリを別途設定します。ローカルコマンドのプロキシルールは、これらを自動的には対象にしません。

7. サポートされている Compliance API の記録を SIEM にストリーミングし、組織の保持ルールとリーガルホールドの制御を適用します。Compliance API と監査イベントを参照してください。

8. ユーザーまたはサービスアカウント、ホストまたはランナー、会話 ID、モデル、クライアントバージョン、権限プロファイル、承認判断、接続先、ツール名を関連付けます。

検証

管理されたセッションで、以下を実行します。

• 許可されたファイルを 1 つ読み取ります。

• ブロック対象のファイルの読み取りを 1 回試みます。

• 許可されたコマンドを 1 つ実行します。

• ブロック対象の外向きリクエストを 1 回試みます。

• 承認をリクエストし、拒否されます。

• セッションを終了します。

証拠ソースごとの期待される結果：

• OTel に実行イベントとツールイベントが表示されます。

• フックにセッションのライフサイクルが記録されます。

• プロキシログに許可された接続先とブロックされた接続先が記録されます。

• コンプライアンス用の取り込み処理が、サポート対象の記録を受信します。

• SIEM がそれらの記録をユーザーまたはワークロードと関連付けます。

ロールバック

以前の設定を復元して、エクスポーターとフックを無効にします。テレメトリのロールバックの一環として、独立したプロキシログの記録を削除しないでください。

制御の範囲と限界

Codex のテレメトリが、すべてのコマンド引数、出力バイト、ネットワークパケットを取得すると保証しないでください。各層がカバーする範囲を文書化してください。

Codex にインターネットアクセスを与えない場合や、承認済みの接続先のみへのアクセスを許可する場合に、このレシピを使用します。設定する環境に応じてローカルまたはクラウドの手順を選び、それぞれのポリシーの適用範囲が異なる点に注意してください。

目指す結果

選択した設定に応じて、Codex はインターネットにアクセスできないか、承認済みのドメインにのみアクセスできます。Codex Cloud (Legacy) 環境では、HTTP メソッドも制限できます。

現行の Codex Cloud を設定する

1. no-internet-review、approved-dependencies-build、cyber-lab など、信頼レベルごとに別々の環境を作成します。

2. ワークフローでインターネットアクセスが必要でない限り、環境設定の Allow Codex to access internet をオフのままにします。

3. アクセスが必要な場合は、Allow Codex to access internet をオンにします。Allow domains で Custom domains only を選び、Additional allowed domains に必要なホストを正確に追加します。

4. 保存し、セットアップ中にサービスをテストします。環境を公開または再公開してから、新しいタスクで承認済みおよび未承認の接続先へのアクセスをテストします。セットアップスクリプトは別途レビューしてください。依存関係のバージョンを固定し、承認済みのミラーを優先し、レビューされていない実行ファイルのダウンロードを避けます。

サービスへの接続を参照してください。現行の Codex Cloud の設定には、Legacy の HTTP メソッド選択機能はありません。

Codex Cloud (Legacy) を設定する

1. 不要な場合は、エージェントのインターネットアクセスを Off のままにします。Legacy Cloud は、デフォルトでエージェントフェーズ中のインターネットアクセスをブロックします。ただし、セットアップスクリプトは依存関係をインストールするため、インターネットアクセスがある状態で実行されます。

2. エージェントのアクセスが必要な場合は、対象を絞った許可リストを設定して On にします。None から始め、正確なドメインを追加します。

3. ダウンロード専用のワークフローでは、GET、HEAD、OPTIONS のみを許可します。これにより、POST、PUT、PATCH、DELETE、その他のメソッドがブロックされます。エージェントフェーズの制限はセットアップスクリプトのインターネットアクセスには適用されないため、スクリプトは別途レビューしてください。

Legacy のエージェントインターネットアクセスを参照してください。これらのプリセットと HTTP メソッドの制御は、Legacy Cloud にのみ適用されます。

ローカルの Codex を設定する

1. 管理者が管理する requirements.toml で、承認済みのネットワークプロファイルを定義して選択し、ユーザーがそのプロファイルのみを使用できるように制限します。

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. 管理対象の設定を使用して、レビュー済みの要件バンドルを展開します。名前付きプロファイルは、それだけでは有効になりません。default_permissions がそのプロファイルを選択し、許可リストがほかのプロファイルの選択を防ぎます。

3. 同じ要件バンドル内で管理者管理のプロキシを有効にし、ドメイン制限を強制適用して、ユーザーがその範囲を広げられないようにします。プロキシとネットワークを有効にしたプロファイルは、同時に展開してください。プロキシが有効でない状態でネットワークを有効にしたプロファイルを使うと、ドメインルールを強制せずに、直接のネットワークアクセスが許可されます。

   注意： [experimental_network] は試験的な機能であり、変更される可能性があります。広く展開する前に、サポート対象のローカルクライアントの各バージョンと OS で検証してください。Windows のサポートは限定的です。環境内で強制適用をテストするまでは、Windows ユーザーにこのポリシーを適用しないでください。

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. ワークフローで必要でない限り、ローカルポートへのバインドはオフのままにします。プライベートネットワークの接続先へのアクセスは別途設定してください。ドメインの許可だけでは、そのプライベートアドレスまで承認されません。ネットワークアクセスの要件を参照してください。

5. ウェブ検索、アプリ、MCP server、ブラウザのアクティビティ、Codex Cloud は別途設定します。ローカルのサンドボックスルールでは、これらを制御できません。

検証

• 承認済みのドメインにリクエストを送信し、成功することを確認します。

• 未承認のドメインにリクエストを送信し、ブロックされることを確認します。

• localhost、プライベート IP、クラウドメタデータのエンドポイントにリクエストを送信します。明示的に承認されていない限り、各リクエストがブロックされることを確認します。

• Codex Cloud (Legacy) で、許可されたドメインへの POST リクエストを試みます。GET、HEAD、OPTIONS のみが許可されている場合に、リクエストがブロックされることを確認します。

• プロキシまたはゲートウェイのログに、許可されたリクエストと拒否されたリクエストの両方が記録されていることを確認します。

ロールバック

環境を Off に戻すか、以前のドメインポリシーを復元します。無制限のインターネットアクセスに戻すことは避けてください。

制御の範囲と限界

サンドボックス制限を全面的に解除する昇格が承認されると、ローカルコマンドのプロキシを迂回できる場合があります。この制限を前提にする前に、通常のサンドボックス内コマンドと、承認を受けて昇格したコマンドを別々にテストしてください。

許可されたドメインにも、プロンプトインジェクション、侵害されたパッケージ、安全でないドキュメントが存在する可能性があります。

Codex に承認済みのソースディレクトリへのアクセスを許可しつつ、シークレット、.env ファイル、SSH キー、無関係なリポジトリにはアクセスさせない場合に、このレシピを使用します。ファイルアクセスの制限と、起動するコマンドに渡される認証情報を含む環境変数の削減を扱います。

目指す結果

Codex は承認済みのソースディレクトリで作業できますが、一般的なシークレットを含むファイルを読み取ることも、認証情報を含む多数の環境変数を継承することもできません。

設定

1. ワークスペースプロファイルで読み取り拒否パターンを定義します。

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. 既知の認証情報ディレクトリ、署名キー、本番環境の設定、隣接するリポジトリについて、拒否する正確なパスを追加します。

3. システムの /etc/codex/config.toml またはユーザーの ~/.codex/config.toml で、起動するコマンドに渡す環境変数を減らします。

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

これはユーザーが設定できるデフォルト値であり、強制適用される要件ではありません。継承される変数は減りますが、認証情報ファイル、ヘルパー、シェル起動時に読み込まれる内容、ほかの ID へのアクセスは防げません。高度な設定を参照してください。

4. 管理者が管理する requirements.toml で、制限付きプロファイルを選択し、そのプロファイルのみを許可します。組み込みプロファイルは、このプロファイルのシークレットファイルに対する拒否設定を継承しません。

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Cloud 環境の認証情報フローを選びます。

   • 現行の Codex Cloud では、許可された HTTPS サービスに送信する認証情報に Network secrets を使用します。プログラムにはプレースホルダーが渡され、セットアップ中およびタスク中に、プロキシがポート 443 上の承認済み接続先に対して実際の値に置き換えます。生の認証情報は、ローカルプロセスやファイルに配置されません。直接設定した環境変数はプログラムから利用できます。環境変数とネットワークシークレットを参照してください。
   • Codex Cloud (Legacy) では、シークレットはセットアップ時の認証に使用でき、エージェントフェーズの前に削除されます。環境変数はチャット全体を通して残ります。Legacy Cloud 環境を参照してください。

6. エージェントに認証が必要な場合は、独立したブローカーを使用して、対象とアクションを厳密に限定した短期間有効の認証情報を提供します。推奨設定を参照してください。

検証

無害な検証用ファイルを作成します。

.env.test
test-key.pem
.aws/credentials
.kube/config

次に、Codex に以下を依頼します。

• 通常のファイルを読み取ります。

• 各検証用ファイルを読み取ります。

• シークレットを再帰的に検索します。

• コマンドの実行環境を出力します。

• 隣接するリポジトリを読み取ります。

期待される結果：通常のファイルの読み取りは成功します。拒否対象のファイルと隣接するリポジトリには引き続きアクセスできず、除外された変数はコマンドの実行環境に含まれません。

ロールバック

以前のプロファイルを復元します。ただし、ワークフローの失敗を調査している間も、確実にシークレットファイルと判断できるものへの拒否設定は維持してください。

制御の範囲と限界

ファイルシステムの拒否設定では、すでにプロンプトに貼り付けられたシークレット、読み取り可能なソースにコミットされたシークレット、コネクターから返されたシークレット、モデルがアクセスできるログに書き込まれたシークレットは取り除けません。

git push、デプロイ、データベースマイグレーション、クラウド CLI コマンドなどのアクションで、実行前の承認が必要な場合に、このレシピを使用します。レビューを求めるコマンドと禁止するコマンドを決め、それらのコマンドのルールを設定します。

目指す結果

機密性の高いコマンドは、モデルが適切だと判断した場合でも、必ず承認待ちで停止するか、禁止されます。

設定

1. 承認を求めるコマンドと禁止するコマンドを決めます。

2. 管理者が強制適用するコマンドルールを追加します。

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

要件ルールでは、承認を求めることやコマンドを禁止することはできますが、コマンドを許可することはできません。管理対象の設定を参照してください。

3. 高リスクのプロファイルでは、ラッパーが機密性の高いコマンドを隠す可能性がある場合、同じ prefix_rules 配列にシェルラッパーのエントリを追加します。

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

シェルラッパーのエントリは多くの確認を発生させるため、対象を絞って使用してください。

4. 人によるコマンドの承認が必須の場合は、次の設定を強制適用します。

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

自動レビューはレビュー担当を変えるものであり、安全性を確定的に保証するものではありません。自動レビューを参照してください。

5. PermissionRequest、ツール判断、ツール結果のイベントをセキュリティパイプラインに送信します。

検証

• git status を実行します。期待される結果：承認プロンプトは表示されません。

• git push を実行します。期待される結果：承認プロンプトが表示されます。

• terraform apply を実行します。期待される結果：承認プロンプトが表示されます。

• kubectl delete pod test を実行します。期待される結果：承認プロンプトが表示されます。

• rm -rf test-directory を実行します。期待される結果：コマンドが禁止されます。

• 承認リクエストを 1 件拒否します。期待される結果：コマンドは実行されず、拒否がログに記録されます。

• クライアントを再起動し、同じ確認を繰り返します。期待される結果：ルールが引き続き強制適用されます。

ロールバック

以前の要件バンドルを復元します。機密性の高いコマンドの分類全体を削除するのではなく、広すぎるトークンパターンの範囲を狭めてください。

制御の範囲と限界

プレフィックスルールは、OS の完全なポリシーエンジンではありません。サンドボックス、最小権限の OS アカウント、ネットワーク制限、クラウド IAM、ブランチ保護、デプロイ承認、データベースの認可と組み合わせてください。

使用する設定レシピ： 権限プロファイルと Full Access を制限する、シークレットと無関係なリポジトリを保護する、機密性の高いコマンドに承認を必須にする。

開発者は正当な本番環境へのアクセス権を持っていますが、Codex にはレビューされていない本番変更を行わせずに、開発を支援させたい場合を想定しています。

• 承認済みのワークスペースプロファイルを定義し、許可するプロファイルと承認ポリシーを強制適用します。ユーザーによる上書きを防ぐため、これらの設定を管理者が強制適用する要件として配信します。

• 権限を抑えた別の ID で Codex を実行するか、本番環境への書き込み用認証情報にアクセスすることも取得することもできない環境で実行します。開発者は、別途認可されたワークフローを通じて本番環境へのアクセスを維持できます。

• 起動するコマンドに渡す環境変数を最小限にします。エージェントに認証が必要な場合は、独立したブローカーを使用して、対象とアクションを厳密に限定した短期間有効の認証情報を提供します。

• 承認を求めるコマンドと禁止するコマンドを決めます。git push、terraform apply、Kubernetes の変更、データベースマイグレーションなど、影響の大きい特定のコマンドには人による承認を必須とし、決して実行してはならないコマンドは禁止します。

• 本番環境の IAM、ブランチ保護、デプロイ承認は、Codex とは独立して強制適用し続けます。

権限プロファイルを制限し、人によるレビューを必須にする

管理者が管理する requirements.toml で、組み込みのワークスペースプロファイルと読み取り専用プロファイルを許可し、承認が必要なアクションにはユーザーによるレビューを必須にします。

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

ワークスペースプロファイルは、サンドボックスの範囲内でワークスペース内の作業を許可します。より限定した作業には、読み取り専用プロファイルを使用できます。フルアクセスのプロファイルは許可リストに含まれません。

クライアントで互換性のある選択肢を明示する必要がある場合は、クライアント設定に approval_policy = "on-request" を設定します。on-request は必要に応じた承認プロンプトを許可するもので、すべてのコマンドで承認を求めるものではありません。レビューが必要なアクションには明示的なルールを追加し、本番環境の独立した認可を維持してください。

管理対象のプロファイル許可リストには、Codex 0.138.0 以降が必要です。古いクライアントでは、文書化されている従来のサンドボックスモードの要件を使用し、テストしてください。

試験導入する各クライアントを再起動し、承認済みのプロファイルが動作することと、許可されていないフルアクセスのプロファイルが拒否されることを確認します。

Codex の ID を本番環境の認証情報から分離する

デバイス管理システムまたは開発環境のプロビジョニングシステムで、必要なソースと開発用サービスのみにアクセスできる、Codex 専用のユーザー、コンテナ、または開発用ホストを作成します。その環境には、開発者の本番用認証情報ファイル、トークンヘルパー、キーチェーンをマウントせず、その ID が本番環境への書き込みロールを取得できないようにします。

エージェントにサービスへのアクセスが必要な場合は、組織の認証情報ブローカーを設定し、開発用リソースとアクションに限定した短期間有効の認証情報を発行します。開発者は、別途認可された本番用ワークフローを通じて、通常の ID を使用できます。

たとえば AWS IAM では、Roles を開き、Codex の開発用ロールを選択し、Permissions で次のようなレビュー済みのインラインポリシーを追加します。アカウントとロールは、自分のものに置き換えてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

この例は、指定されたロールの引き受けを拒否しますが、ほかのロールの引き受けは拒否しません。本番環境への直接の権限も削除し、ほかの本番用ロールと認証情報の取得元を制限したうえで、信頼ポリシーと組織レベルの制御もレビューしてください。

本番環境に変更を加えずに、代表的な開発環境および本番環境の権限に対して開発用ロールをテストします。AWS IAM ロールポリシーの例を参照してください。

シェル環境を最小限にする

システム全体の初期設定には /etc/codex/config.toml、ユーザー単位の設定には ~/.codex/config.toml を使用し、起動されるコマンドが継承する環境変数を設定します。

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

これは変更可能なデフォルト設定であり、認証情報へのアクセスを強制的に制限する境界ではありません。ユーザー設定、シェルの起動処理やスナップショット、認証情報ヘルパー、その他の認証情報ソースから、認証情報に引き続きアクセスできる場合があります。

requirements.toml では、ワークフローと互換性がある場合、次の任意の制限を使用してログインシェルとシェルスナップショットを無効にします。

allow_login_shell = false

[features]
shell_snapshot = false

ログインシェルの初期化に依存するワークフローもあるため、これらの設定は試験的に導入してください。

フィルターに一致する無害な合成変数を指定して Codex を起動し、起動されたコマンドの環境を調べます。また、ログインシェルを無効にした場合は、その要求が拒否されることも確認します。これとは別に、実行主体が実際の本番環境の認証情報にアクセスできないことを確認してください。シェル環境ポリシーを参照してください。

特に影響の大きいコマンドに承認を求める

組織で使用するコマンドに対して、要件ルールを追加します。例：

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

絶対に実行してはならないコマンドには forbidden を使用します。実際に使用するデプロイツールや移行ツールに合わせて、パターンを置き換えるか追加してください。

これらのルールはコマンドのプレフィックスに一致するもので、同等の操作をすべて網羅するわけではありません。絶対パス、ラッパー、引数の順序の変更、別のクライアント、その他のツールについては、個別にテストしてください。

使い捨てのテスト対象で通常のコマンドを実行し、リストにある操作を要求して承認要求を拒否し、その操作が実行されなかったことを確認します。コマンドルールの適用を参照してください。

リポジトリとデプロイの承認を Codex の外部で適用する

ソース管理プラットフォームで、main などの本番用ブランチを保護します。レビュー済みの変更、必要な承認、ステータスチェックを必須にし、これらの要件を回避できるロールを確認してください。デプロイの承認は該当するデプロイシステムで設定し、データベースの権限はデータベース自体で設定します。

使い捨てのリポジトリを使用して、レビュー済みの変更が正常に反映され、許可されていない直接プッシュが拒否されることを確認します。これらの制御は、操作が Codex を通じて要求されたかどうかに関係なく適用されます。

検証

使い捨てのテスト対象で次を実行します。

• 通常のワークスペースタスクを実行します。期待される結果：タスクが成功します。

• 代表的な機密性の高いコマンドの実行を試み、承認要求を拒否します。期待される結果：拒否したコマンドは実行されません。

• Codex の実行主体が本番環境への書き込みアクセス権を取得できないことを確認します。

• クライアントを再起動し、同じ検証を繰り返します。

制約

プレフィックスルールは、完全なオペレーティングシステムのポリシーエンジンではありません。サンドボックス化、最小権限の OS アカウント、ネットワーク制限、クラウド IAM、ブランチ保護、デプロイの承認、データベースの認可と組み合わせてください。

使用する設定レシピ： シークレットと無関係なリポジトリを保護する、ネットワークの接続先を制限する、承認済みの MCP serverのみを許可する、機密性の高いコマンドに承認を必須にする。

開発者が社内リポジトリで Codex を使用しており、コードが公開リポジトリ、公開コードスニペット、その他の未承認の送信先に送られるリスクを減らしたい場合を想定します。

• 既知の認証情報ディレクトリと無関係なリポジトリに対して、拒否する正確なパスを追加し、起動されるコマンドに渡す環境変数を最小限にします。

• エージェントのインターネットアクセスが必要な場合は、承認済みドメインに絞った許可リストを使用します。承認済みの MCP server名と ID のみを許可し、git push など、選択した公開コマンドにレビューを必須にするか、実行を拒否します。

• ソース管理のフックと権限、公開リポジトリとコードスニペットに関するポリシー、および組織に適したデータ損失防止の制御を使用します。

無関係なリポジトリと認証情報ファイルへのアクセスを拒否する

管理者が管理する requirements.toml に、ローカルエージェントが読み取ってはならない正確なパスを追加します。

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

例を、管理対象デバイスに存在するパスに置き換えてください。この管理対象の拒否設定は、許可されたすべての権限プロファイルに適用されます。1 つのカスタムプロファイル内だけで拒否を設定しても、別のプロファイルを選択したユーザーは保護されません。既知の正確なパスを優先し、glob パターンは必要なディレクトリ階層でテストしてください。

ネイティブ Windows では、管理対象の deny_read はファイルに直接アクセスするツールを対象としますが、それだけではシェルのサブプロセスによる読み取りを防げません。OS の実行主体とファイルのアクセス制御リストも使用してください。

拒否対象の場所に、無害なカナリアファイルを作成します。許可されたすべてのプロファイルで、それらのファイルの直接読み取りとシェル経由の読み取りが拒否され、承認済みのソースファイルは読み取れることを確認します。管理対象の読み取り拒否要件を参照してください。

認証情報を含むシェル変数を最小限にする

/etc/codex/config.toml または ~/.codex/config.toml で、継承する環境を必要最小限に設定します。

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

この設定は継承される変数を減らしますが、ユーザーが変更できるため、認証情報ファイル、ヘルパー、シェルの起動時に読み込まれる内容、別の実行主体へのアクセスを防ぐものではありません。

必要に応じて、管理者は次の制限を requirements.toml に追加し、試験的に導入して開発者のワークフローへの影響を評価することもできます。

allow_login_shell = false

[features]
shell_snapshot = false

合成のカナリア変数と、最小権限を持つ別の実行主体を使用してテストします。実際の認証情報は使用しないでください。シェル環境ポリシーを参照してください。

ローカルコマンドのネットワーク接続先を承認済みのものだけに制限する

サンドボックス内のローカルコマンドにネットワークアクセスが必要な場合は、以下のプロファイル設定と管理対象プロキシ設定の両方を requirements.toml に統合し、ドメインを承認済みのエンドポイントに置き換えます。

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

ネットワークを有効にしたプロファイルは、サンドボックス内のコマンドにネットワーク経路を提供し、管理対象プロキシはその接続先を制限します。両者を一緒に導入してください。意図した管理対象プロキシがないままネットワークを有効にしたプロファイルを使用しても、同じ接続先制限は適用されません。インターネットアクセスが不要な場合は、ネットワークアクセスを無効のままにします。

標準の domains テーブルを、従来の allowed_domains または denied_domains 設定と組み合わせないでください。既存のポリシーを移行し、テストしてください。

クライアントを再起動し、承認済みのエンドポイントには接続でき、未承認のエンドポイントはブロックされることを確認します。

これらの設定は試験段階です。OS とクライアントの対応状況を検証し、承認済みホストの名前解決結果がプライベートアドレスになる場合は、プライベートネットワークへのアクセスを別途設定してください。サンドボックスの完全な権限昇格が承認されると、コマンドプロキシを回避できます。

このローカルコマンド向けのネットワーク制御だけでは、ウェブ検索、アプリ、MCP server、ブラウザーの操作、クラウド環境は対象にならないため、それぞれに別のポリシーが必要です。また、承認済みのホスティングドメインに公開リポジトリや公開コードスニペットが含まれる場合もあるため、接続先の許可リストだけではコンテンツを保護できません。ネットワークアクセス要件を参照してください。

クラウド環境のネットワークを別途設定する

現在の Codex Cloud インターフェースで、環境設定を開きます。Codex にインターネットへのアクセスを許可する はオフのままにします。インターネットアクセスが必要な場合はオンにして、カスタムドメインのみ を選択し、追加の許可ドメイン に必要な正確なホストを追加します。その後、設定を保存し、環境を公開または再公開して、新しいタスクでテストします。

サービスの認証と機能は、個別に確認してください。

従来の Codex Cloud では、環境ごとに独立したエージェントのインターネット設定を使用し、許可するドメインと HTTP メソッドを制御します。セットアップスクリプトには、独自のアクセス動作があります。

実際に使用する環境のバージョンでテストしてください。サービスへの接続と従来のインターネット設定を参照してください。

MCP serverを制限し、Git プッシュの前に承認を求める

requirements.toml で、承認済みのローカル MCP server ID のみを許可します。例：

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

実際のサーバーは、ユーザー設定または管理対象のデフォルト設定である config.toml に別途設定します。一致する名前と URL、およびサーバーが要求する認証を使用してください。

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

この要件は一致するサーバーの使用を許可するだけで、サーバーを作成するものではありません。そのサーバー自体のアクセス権とツールを確認してください。

承認済みのサーバーには接続でき、名前または URL が異なるサーバーは許可されないことを確認します。

代表的な公開コマンドの実行前にレビューを求める、管理対象のコマンドルールを追加します。

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

人によるレビューが必要な場合は、これに加えて allowed_approval_policies = ["on-request"] と allowed_approvals_reviewers = ["user"] を最上位の要件として設定します。

テスト用のプッシュを拒否し、実行されないことを確認します。

プレフィックスの一致では、すべてのラッパー、API クライアント、アプリ、代替の公開経路を網羅できません。

ソース管理と DLP の制御で一般公開を制限する

ソース管理プラットフォームで、サポートされている場合は、公開リポジトリの作成を制限し、リポジトリの公開範囲を変更できるユーザーを限定します。特権ユーザーの回避権限も確認してください。個人アカウント、コードスニペット、外部組織、トークンによるアクセスは別途確認します。組織の設定がすべての送信先を管理するわけではありません。

該当するリポジトリでは、レビュー済みの変更を必須にし、ブランチ保護と回避権限を確認します。

組織の DLP コンソールで、機密性の高いソースコードの内容と、DLP 製品が実際に対応するアップロード経路またはリポジトリ経路を対象に、試験用のポリシーを設定します。アクションをブロックに設定し、無害な合成マーカーでテストしてください。

ソース管理プラットフォームがサーバー側の制御をサポートしている場合は、プッシュを受け付けるリポジトリに対して、レビュー済みのフックを設定して適用します。

許可されたテスト先を使用し、公開する前にブロックされることを確認します。

検証

• 無害なカナリアを作成し、拒否対象ファイルの読み取りが失敗することを確認します。

• ネットワークアクセスが有効な場合は、承認済みの接続先には接続でき、未承認の接続先はブロックされることを確認します。無効な場合は、ネットワークリクエストがブロックされることを確認します。

• 無害なマーカーと使い捨てのテストアカウントまたはテスト先を使用し、代表的な一般公開の試みが公開前にブロックされることを確認します。

制約

許可されたドメインでも、公開コンテンツがホストされている場合があります。ウェブ検索、アプリ、MCP server、ブラウザーの操作、Codex Cloud は個別に設定してください。ローカルのサンドボックスルールでは制御できません。

使用する設定レシピ： 権限プロファイルと Full Access を制限する、承認済みの MCP serverのみを許可する、ネットワークの接続先を制限する、シークレットと無関係なリポジトリを保護する、機密性の高いコマンドに承認を必須にする。

Codex がリポジトリで作業しているときや、ユーザーがローカル設定を変更したときも、Codex を制御する制限が引き続き適用されるようにしたい場合を想定します。

• サポートされている権限、承認、MCP、ネットワーク、コマンドの制限を、管理者が強制する要件として配布します。

• フックスクリプトを管理者が管理するディレクトリにインストールし、ユーザー、プロジェクト、プラグインのフックを無視する必要がある場合は、管理対象のフックのみを使用します。

• ポリシーファイルと設定の配布経路を、オペレーティングシステムとデバイス管理の制御で保護します。それらの保護を変更するために必要な権限を持たない状態で Codex を実行します。

• 対象範囲の各クライアントと環境で、実際に適用されている設定を確認します。

許可するプロファイル、承認、サーバー ID、コマンドを強制する

ユーザーやリポジトリが編集できる設定に頼るのではなく、レビュー済みの設定を、管理者が管理する requirements.toml に統合します。例：

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

この例では、2 つのプロファイルを許可し、承認が必要な場合は人間のレビュアーを必須にし、一致する MCP ID を許可し、特定のコマンドプレフィックスに承認を求めます。

MCP server自体は別途設定し、組織におけるその他の機密性の高いコマンドパターンも追加してください。必要に応じて、グローバルなファイル制限とネットワーク制限を追加します。要件はサポート対象の設定を制約しますが、Codex の外部にある実行主体、サービス、接続先の制御の代わりにはなりません。

管理対象のプロファイル許可リストには、Codex 0.138.0 以降が必要です。

試験用クライアントで、許可されていないプロファイルの選択、制限対象のユーザー設定またはプロジェクト設定の変更、許可リストにない MCP ID の使用を試みます。それぞれが拒否されるか、再起動後も制約が維持されることを確認してください。テストコマンドの承認を拒否し、コマンドが実行されないことも確認します。

管理対象のファイルシステム制限とネットワーク制限を追加する

許可されたすべてのプロファイルで機密性の高いローカルファイルへのアクセスを拒否するには、次のテーブルを requirements.toml に追加し、例を組織のパスに置き換えます。

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

サンドボックス内のローカルコマンドにネットワークアクセスが必要な場合は、許可するネットワーク有効プロファイルと管理対象の接続先を一緒に定義します。

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

先ほどの :workspace のデフォルト設定の代わりに、このプロファイルポリシーを選択するか、意図に合わせて両方のプロファイル名を統合します。キーやテーブルを重複して貼り付けないでください。コマンドにネットワークが不要な場合は、無効のままにします。

無害なファイルを使って正確な拒否対象パスを検証し、承認済みと未承認の接続先も検証します。

ネイティブ Windows では、管理対象の deny_read だけではシェルのサブプロセスによる読み取りを制御できないため、ファイルのアクセス制御リストも使用してください。

ローカルコマンドのネットワーク設定は、他のクライアント、アプリ、コネクター、クラウドでの実行を制御しません。

管理者が管理するフックをインストールして強制する

管理者に、レビュー済みのフックプログラムを /etc/codex/hooks/pre_tool_use_policy.py などの root 管理下のディレクトリにインストールしてもらい、Codex の実行ユーザーがそのファイルやディレクトリを変更できないようにします。requirements.toml でフックを有効にし、ユーザー、プロジェクト、セッション、プラグインのフックを無視します。

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

この要件はフックを登録しますが、インストールはしません。ローカル macOS での統合テストでは、以下を pre_tool_use_policy.py として保存し、管理者に以下のコマンドでインストールしてもらいます。

これは合成マーカーだけをブロックします。実際に使用する前に、レビュー済みの組織固有のポリシーに置き換えてください。対象に /usr/bin/python3 が存在することを確認し、必要に応じてインタープリターのパスを調整します。

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

ローカルクライアントを再起動してから、次を実行します。

• 無害な Bash コマンドが実行されることを確認します。

• CODEX_HOOK_TEST_DENY を含むコマンドがブロックされることを確認します。

• Codex の実行ユーザーがポリシーと依存関係を変更できないことを確認します。

allow_managed_hooks_only は、管理対象ではないユーザー、プロジェクト、セッション、プラグインのフックをすべてスキップするため、他のワークフローに影響する場合があります。

Bash マッチャーは、すべてのツールや、既存のプロセスに後から渡される入力を網羅しません。エラー、タイムアウト、不正な形式のフック応答によって、ツール呼び出しの続行が許可される場合があります。

クラウドでオーケストレーションされる Work では、サポートされるフックハンドラーが異なります。OS とサービスによる独立した保護を維持してください。管理対象フックとフックの動作を参照してください。

ポリシーとその配布経路を保護する

macOS では、管理者がレビューと統合を済ませた要件ファイルを root 所有の親ディレクトリに配置し、Codex の実行ユーザーがそのファイルに書き込めないようにできます。

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

Linux では、適切な管理者グループを使用します。Windows では、管理者が管理するアクセス制御リストで ProgramData ディレクトリとファイルを保護します。MDM またはクラウドポリシーを変更できるユーザーを制限し、変更をレビューして、ロールバック用のコピーを保存してください。

管理者権限のない試験用アカウントを使用し、そのアカウントがポリシー、親ディレクトリ、管理対象のフックプログラムを変更できないことを確認します。制限の弱いユーザー設定またはプロジェクト設定を試し、Codex を再起動して、強制された動作が維持されることを確認してください。

すべてのクライアントが同じポリシーを読み込むと想定せず、対象範囲の各クライアントと環境をテストします。

検証

管理者権限のないテスト用の実行主体で、次を実行します。

• 管理対象ポリシーの編集を試みます。期待される結果：管理対象ファイルは変更できません。

• ユーザー設定またはプロジェクト設定を通じて制限を弱めようとします。期待される結果：制限の弱い設定は拒否されるか、制約されたままになります。

• クライアントを再起動し、制限が引き続き適用されることを確認します。

制約

ホストの十分な管理者権限を持つユーザーやエージェントは、周辺の保護を変更できる場合があります。ユーザーが編集できる設定だけでは、管理者が管理する要件の代わりにはなりません。