チームでCodexを安全に使うための権限と承認の確認方法

2026年10月4日

約30分で、チームリーダーはCodexの試用設定を用意し、編集できる場所、承認が必要になる条件、コマンドのネットワーク接続を確認できます。必要なのは、試験用のリポジトリ、技術ポリシーの責任者、代表メンバーのPCに入れたCodex CLIです。成果物は許可された操作と拒否された操作の確認記録です。一つの設定ですべてのリスクが消えるわけではありません。

この記事は、CLI、デスクトップアプリ、IDE拡張機能からローカルで動くCodexを扱います。CLIで初めて修正する場合は、慣れないリポジトリで小さな変更を加えて確認する方法から始めてください。ここではチーム全体の運用境界に絞ります。

準備するもの

本物の認証情報や顧客データを含まない試験用リポジトリを作ります。編集を許可するファイル、リポジトリ外のファイル、接続を許可するドメイン、拒否するドメインを一つずつ選びます。

OpenAIのAgent approvals & securityとAuto-reviewを確認します。「プルリクエストを作る前にテストする」などのチームの仕事の進め方は、Codex向けのAGENTS.mdに書けます。ただし、プロジェクトの文章はOSレベルの制限を自動で作りません。ファイル、ネットワーク、承認の権限は別々に設定して試します。

ポリシーを変更できる担当者と、更新後に見直す時期を決めておきます。

手順

手順1：実際の仕事に合うモードを選ぶ

Codexには異なる二つの層があります。サンドボックスはコマンドがファイルを読み書きできる場所やネットワーク接続を制限します。承認ポリシーは境界を越える前にいつ許可を求めるかを決めます。OpenAIによると、workspace-writeではワークスペース内を読み書きでき、コマンドのネットワーク接続は初期状態で無効です。on-requestでは、ワークスペース外の編集やネットワークが必要なコマンドが承認要求になる場合があります。

リポジトリを初めて調べるときは、読み取り専用から始めます。

codex --sandbox read-only --ask-for-approval on-request

試験用リポジトリで具体的な修正を任せるときは、次の設定を使えます。

codex --sandbox workspace-write --ask-for-approval on-request

CLIの/permissionsではセッションのモードを確認、変更でき、/statusでは認識されているワークスペースを確認できます。承認の表示を避けるためだけにdanger-full-accessを使わないでください。ローカルのサンドボックス境界がなくなります。

AIを使った開発の基礎を知りたいメンバーには、初心者向けのVibe Codingガイドも役立ちます。チームリーダーは作業範囲と生成されたコードを引き続き確認します。

手順2：保護すべきパスを決める

標準のworkspace-writeポリシーについて、OpenAIは書き込み可能なルートの中でも読み取り専用として保護されるパスを挙げています。.git、.agents、.codexです。適用条件は文書に従います。.gitが実際のGitディレクトリを指すファイルなら、参照先のディレクトリも保護されます。これは該当するパスに限った保護であり、リポジトリ内のほかの機密ファイルがすべて自動で守られるわけではありません。

環境設定ファイル、証明書、データのエクスポートを別に洗い出します。ベータ版のpermission profilesでは、OpenAIのPermissionsガイドにあるread、write、denyをパスごとに設定でき、.envファイルの読み取り拒否も定義できます。Profilesは同じセッションで従来のサンドボックス設定と組み合わせられません。どちらか一方を選び、代表的なPCで試します。

Codexには範囲を明確にした依頼を渡します。

この試験用リポジトリでは、[許可されたファイルパス]だけを編集して[変更内容]を実施してください。
編集前に触れる予定のファイルを挙げてください。秘密情報を読まず、リポジトリ外を編集しないでください。
編集後に[安全なテストコマンド]を実行し、変更したファイルを列挙してください。

挙げられたファイルと実際の変更を照合します。試験環境で範囲外の操作を一つ試し、拒否されるか承認が必要になることを確かめます。AGENTS.mdだけでは、パスが制限されている証拠にはなりません。

手順3：ネットワークを独立した権限として扱う

workspace-writeでは、ローカルコマンドのネットワーク接続は初期状態で無効です。サービスへの接続が必要なら、正確なドメイン、目的、送信を許すデータを決めます。OpenAIは、コマンドのネットワーク利用を有効にすることと、接続先を制限するプロキシを有効にすることを分けています。ドメイン一覧を書くだけではプロキシは動きません。プロキシなしでネットワークを有効にすると、コマンドが直接外部へ接続できる場合があります。

試験環境で使うローカル設定例は次のとおりです。

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = true

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

ドメインは会社が承認したものに置き換えてください。許可先と拒否先への接続をそれぞれ試します。コマンド用プロキシは、Web検索、ブラウザー、アプリ、MCP、Codex Cloudをフィルタリングしません。それぞれに別の制御があります。

現在のCodex Cloudを使うチームは、クラウドでの不具合修正からプルリクエストまでの手順と最新のConnect to services文書を参照してください。**Codex Cloud (Legacy)**のネットワーク手順は旧環境向けなので、新環境にそのまま持ち込まないでください。クラウドの権限も、メンバーのPCのサンドボックスポリシーにはなりません。

手順4：Auto-reviewを有効にする前に役割を理解する

approval_policy = "on-request"では、境界を越える要求は通常ユーザーに届きます。approvals_reviewer = "auto_review"を設定すると、別の審査エージェントが実行前にもともと承認が必要な要求を確認します。権限を追加したり、ネットワークを有効にしたり、保護されたパスを弱めたりはしません。サンドボックス内で許可済みの操作は、この審査なしに進むことがあります。

試行時の設定例です。

approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"

データの外部送信、本番環境の変更、取り消しにくい操作は、引き続き責任者の承認が必要です。Auto-reviewが拒否したら理由を読み、同じ境界を回避するためにコマンドを書き換えないでください。タイムアウトは危険だという証明ではありませんが、操作はまだ実行されていません。

手順5：許可と拒否の両方を試す

Codexが一つのファイルを編集できたことだけで、ポリシーが正しいと判断しないでください。試験用リポジトリで四つを確認します。範囲内のファイルを編集する、範囲外の編集を試す、許可ドメインに接続する、拒否ドメインに接続する。各試行について、モード、依頼またはコマンド、実際の結果、確認者を記録します。Auto-reviewを使う場合は、その判断と理由も残します。試験ログに秘密情報は必要ありません。

一般メンバーのアカウントでも繰り返し、ポリシーを変えた後にも再試験します。クラウドについては、リポジトリ、環境、ネットワークの権限を別々に確認します。引き継ぎ記録には、現在有効な権限、変更できる人、試験結果を記します。

結果の例

サンプルのリポジトリを使うチームなら、次のように記録できます。「Codexは試験用ワークスペースのsrc/を編集できる。ワークスペース外の編集には承認が必要になる。標準サンドボックスでは.gitは読み取り専用。承認済みのAPIコマンドはプロキシ経由で動き、拒否したドメインには接続できない。Auto-reviewは境界を越える要求だけを確認する。マージ前にチームリーダーが差分とテスト結果を確認する」。これは記録例であり、すべてのPC、クライアントのバージョン、プランで同じ結果になる保証ではありません。

想定と異なる結果が出たら、導入範囲を広げず、実際に有効な設定と実行経路を調べます。特にベータ版permission profilesと従来のサンドボックス設定が混ざっていないかを確認します。実際に使う担当者、PC、環境で再試験してください。

続けやすくするコツ

仕事に必要な権限だけを与える。 文書を読む人に書き込み権限は不要です。一つのリポジトリを編集する人に本番環境へのアクセスを与える必要もありません。拒否条件を試してから段階的に広げます。

指示と強制的な制御を分ける。 AGENTS.mdは仕事の手順、テストコマンド、レビュー基準を共有できます。サンドボックス、permission profiles、ネットワーク、承認が、それぞれの場所で権限を強制する仕組みです。

大きな更新の後は見直す。 権限の表示やprofileの対応状況は変わり得ます。古い設定画面を長期的な証拠にせず、クライアントのバージョンを記録して試験を繰り返してください。

知っておきたい限界

ローカルのサンドボックスは、GitHub、接続先サービス、Platform APIの権限を付与したり取り消したりしません。元のシステムの権限が引き続き適用されます。WebページやリポジトリにはAIを誤誘導する指示が含まれることもありますが、それによってユーザーが許可した仕事の範囲は広がりません。ポリシーを「試す」ために本物のAPIキーをプロンプトへ貼り付けないでください。

Auto-reviewが誤ることもあり、追加のリソースを使います。承認要求が発生した操作を確認する仕組みで、通常のコマンドをすべて審査するわけではありません。approval_policy = "never"では、Auto-reviewが確認する対話式の要求が発生しません。重要または取り消せない変更には、会社の方針に沿った責任者の判断が必要です。