OpenAI Codex 的 Sandbox、Trust 与 Approval 安全机制解析

「Codex」のセキュリティの仕組みについてまとめました。

1. はじめに

OpenAIの「Codex」は、プログラムの作成・修正、テスト、コマンド実行などを自律的に行うAIコーディングエージェントです。

AIがローカルPCのファイル操作やコマンド実行を行うため、誤操作やセキュリティ上のリスクもあります。そのため、CodexにはAIの操作を制限し、必要に応じてユーザーが許可する仕組みが用意されています。

実際にCodexを利用していると、次のような場面に遭遇します。

・Sandboxでコマンドを実行できない
・作業フォルダを信頼（Trust）するか聞かれる
・コマンドの実行を承認（Approval）するか聞かれる

これらは似たようなセキュリティ機能に見えますが、それぞれ役割が異なります。

今回は、OpenAIの公式ドキュメント「Agent approvals & security」をもとに、Sandbox・Trust・Approvalの違いを紹介します。

2. Sandbox - 操作できる範囲を制限する

2-1. Sandboxとは

「Sandbox」（サンドボックス）は、Codexが実行するコマンドに対して、ファイル操作やネットワーク通信などを制限する仕組みです。

主に3種類のモードがあります。

・read-only：ファイルの読み取りを許可し、書き込みを制限
・workspace-write：作業フォルダや一時フォルダなどへの書き込みを許可。ただし、一部の保護対象は書き込み禁止
・danger-full-access：Sandboxの制限を解除

通常の開発では「workspace-write」が基本です。

Sandboxの制限を適用した状態を「Sandbox内」、その制限を受けずにコマンドを実行する状態を「Sandbox外」と呼びます。danger-full-accessは、Sandboxの制限を解除するモードです。

2-2. 作業フォルダと保護ファイル

「作業フォルダ」とは、Codexが作業対象とするフォルダです。Sandboxの「Workspace」には、作業フォルダに加えて、一時フォルダなども含まれます。

CodexのGUI版で「Open Folder」からmy-appフォルダを選択した場合、my-appが作業フォルダになります。

workspace-writeでは、原則として作業フォルダ内のファイルを編集できます。ただし、作業フォルダ内でも、一部のファイルやフォルダは書き込みが制限されます。

代表的な保護対象は次のとおりです。

・.git/：Gitの管理情報
・.codex/：Codexの設定
・.agents/：AIエージェント関連の設定
・.aws/：AWSの認証情報など

標準的なworkspace-writeでは、これらの保護対象は読み取り専用となり、Sandbox内からの書き込みが禁止されます。

ただし、.で始まる隠しファイルがすべて保護されるわけではありません。たとえば、.envや.gitignoreなどは通常のファイルと同様に扱われます。

2-3. よくある勘違い

勘違い1：Sandbox内ではコマンドを実行できない
Sandbox内でもコマンドは実行できます。

たとえば、workspace-writeでは、作業フォルダ内のファイル編集やテストの実行が可能です。ただし、禁止されたファイル操作や通信を行おうとすると制限されます。

つまり、Sandbox内とは「実行禁止」ではなく「制限付きで実行する状態」です。

勘違い2：Sandbox内とは、作業フォルダ内のこと
Sandbox内・Sandbox外は、フォルダの場所ではなく、コマンドの実行にSandboxの制限が適用されているかを表します。

たとえば、作業フォルダ外のファイルに対する操作でも、Sandbox内で実行する場合は、書き込みが制限されます。

勘違い3：作業フォルダ外のファイルにはアクセスできない
標準的なworkspace-writeでは、作業フォルダ外への書き込みは原則禁止ですが、読み取りは広く許可されています。

そのため、別プロジェクトのソースコードや、OSの権限で読み取り可能な機密ファイルにアクセスできる場合があります。

作業フォルダの選択だけでは、読み取り可能な範囲を限定できません。

3. Trust - プロジェクト固有の設定を有効にする

3-1. Trustとは

Codexを起動すると、作業フォルダを「信頼」（Trust）するか聞かれる場合があります。

Trustは、プロジェクト固有のCodex設定を利用するかどうかを決める仕組みです。

Codex設定は主に次の2か所で管理されます。

・ユーザー共通設定：~/.codex/
・プロジェクト固有設定：プロジェクト/.codex/

信頼状態による違いは次のとおりです。

・Trusted（信頼済み）：ユーザー共通設定に加え、プロジェクト固有設定も読み込む
・Untrusted（未信頼）：プロジェクト固有設定を読み込まず、ユーザー共通設定などを利用する

プロジェクト固有の設定には、Sandboxモードや承認ポリシー、コマンドのルールなどが含まれます。

3-2. よくある勘違い

勘違い1：Trustすると、そのフォルダを読み書きできるようになる
Trust自体は、ファイルの読み書き権限を付与しません。

実際のアクセス範囲は、SandboxやOSの権限などによって決まります。

つまり、「フォルダを信頼する」と「フォルダへのアクセスを許可する」は別の操作です。

勘違い2：Trustすると、Sandboxの制限が解除される

TrustしただけではSandboxの制限は解除されません。

ただし、プロジェクト固有の設定に、次のような指定がある場合は注意が必要です。

sandbox_mode = "danger-full-access"
approval_policy = "never"

これらの設定が有効になると、Sandboxの制限が解除され、承認も要求されなくなる可能性があります。

つまり、Trustは、プロジェクトが用意したセキュリティ設定を受け入れることにもつながります。

勘違い3：Trustしなければ、安全に実行できる
Trustしなくても、Codexがすべてのファイルにアクセスできなくなるわけではありません。

Trustは主にプロジェクト固有の設定を利用するかどうかを決める仕組みであり、ファイルへのアクセスはSandboxやOSの権限などによって制限されます。

4. Approval- 例外的な操作を許可する

4-1. Approvalとは

Codexでは、通常の権限では実行できない操作などについて、ユーザーに「承認」（Approval）を求める場合があります。

たとえば、次のような操作です。

・ファイル操作：作業フォルダ外のファイルを書き換える
・ネットワーク通信：Sandboxで禁止されている通信を行う
・コマンド実行：Sandbox外でコマンドを実行する
・コマンドルール：実行前の確認が必要なコマンドを実行する

ユーザーが承認すると、許可された範囲で操作を実行できます。

これは「Human in the Loop」と呼ばれる、人間が重要な操作を確認するセキュリティ設計です。

4-2. Auto-review - AIによる自動承認

Codexには、ユーザーの代わりにAIが承認要求を審査する「Auto-review（自動レビュー）」もあります。
通常のApprovalではユーザーが操作を確認しますが、Auto-reviewでは別のAIエージェントが操作内容やリスクを評価し、承認・拒否などを判断します。

主な特徴は次のとおりです。

・自動審査：承認要求をAIが評価
・リスク評価：危険なコマンドや情報漏洩などを確認
・承認・拒否の判断：リスクやユーザーの事前許可をもとに、操作の承認・拒否を判断

設定ファイル「~/.codex/config.toml」では、次のように指定できます。

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Auto-reviewは、Sandboxの制限を解除する機能ではなく、通常はユーザーが行う承認判断をAIに任せる仕組みです。

ただし、AIの判断が常に正しいとは限らないため、重要なファイルや認証情報を扱う環境では慎重に利用する必要があります。

4-3. よくある勘違い

勘違い1：Approvalすると、Sandboxの制限が完全に解除される
Approvalは通常、要求された操作に対する承認です。

たとえば、作業フォルダ外への書き込みを承認しても、そのフォルダ全体が永続的に書き込み可能になるわけではありません。

また、OSや管理者ポリシーによって、承認しても実行できない場合があります。

勘違い2：Sandbox内で許可されている操作は、必ず承認なしで実行される
Sandbox内で許可された操作でも、コマンドルールなどによって承認を求められる場合があります。

つまり、Sandboxの制限とApprovalの判断は、必ずしも一対一ではありません。

勘違い3：承認ポリシーをneverにすると、すべての操作が実行できる
Codexには、承認を要求するかどうかを決める「Approval Policy」があります。

・on-request：必要な場合に承認を要求
・never：ユーザーに承認を要求しない

neverは、すべての操作を許可する設定ではありません。Sandboxの制限は残るため、実行できない操作もあります。

5. Sandbox・Trust・Approvalの関係

3つの仕組みを組み合わせた具体例を紹介します。

Codexでmy-appを作業フォルダに選択し、次の条件で実行した場合です。

作業フォルダ：my-app
Sandbox：workspace-write
Trust：Trusted
Approval Policy：on-request
ネットワーク通信：禁止

この場合、操作は次のようになります。

・my-app内のファイル編集：保護対象を除き、原則として実行可能
・別フォルダのファイル読み取り：原則として実行可能
・別フォルダへの書き込み：追加承認が必要になる場合がある
・外部ネットワーク通信：追加承認が必要になる場合がある
・Sandbox外でのコマンド実行：承認などの条件を満たせば実行可能

重要なのは、Trustしたから読み書きできるのではなく、適用されたSandbox設定によってアクセス範囲が決まることです。

また、Sandbox内で許可されない操作の一部は、Approvalによって例外的に実行できます。

実際の操作可否は、OSの権限やコマンドルール、管理者ポリシーなどにも左右されます。

6. 安全に使うための基本設定

通常のCodex開発では、次の設定がおすすめです。

・~/.codex/config.toml

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

これにより、作業フォルダ内の編集などは自動実行し、追加の権限が必要な場合にはユーザーに承認を求められます。

さらに、必要に応じて詳細なセキュリティ設定も利用できます。

・Rules：コマンドの許可・承認要求・禁止
・Permissions：ファイルの読み書きやネットワークなどの詳細な権限制御
・Network Proxy：通信先ドメインの制限

通常の開発では、最初からこれらを細かく設定する必要はありません。まずはSandbox・Trust・Approvalを理解し、必要に応じて追加するとよいでしょう。

特に、外部から取得したプロジェクトをTrustする場合は、.codex/config.tomlなどに危険な設定が含まれていないか確認することが重要です。

また、Sandboxで書き込みを制限していても、作業フォルダ外の機密ファイルを読み取れる場合があります。機密性の高い開発では、コンテナや仮想マシンによる隔離も検討するとよいでしょう。