CodexをWindowsで有効にするための安全で効果的なサンドボックスの構築

OpenAIは、非効率な手動コマンド承認と無制限の「Full Access」モードの間で選択しなければならないユーザーの負担をなくすため、Windows向けにカスタムサンドボックス実装を開発しました。このサンドボックスは、Codexが広範にファイルを読み取ることを許可しつつ、書き込みアクセスを特定のワークスペースに限定し、許可されていないネットワークアクセスをブロックします。これにより、Windowsでの体験がmacOSやLinux上のCodexと同等の安全性と使いやすさを実現します。

既存のWindows分離ツールが不十分だった理由

OpenAIは複数のネイティブWindows分離プリミティブを評価しましたが、開発者のワークフロー（シェル、Git、Python、各種ビルドツール）というオープンエンドな性質と互換性がないことが判明しました。

  • AppContainer: 強力なOS境界を提供しますが、 tightly scoped applications 用に設計されており、コーディングエージェントが実行する幅広いバイナリに対しては制限が厳しすぎます。
  • Windows Sandbox: この軽量VMは強力な分離を提供しますが、Codexは使い捨てのゲストOSではなく、ユーザーの実際のローカルチェックアウトと環境上で動作する必要があるため不適切です。また、Windows Home SKU では利用できません。
  • Mandatory Integrity Control (MIC): 低インテグリティラベリングの使用はリスクが高すぎると判断されました。ワークスペースを低インテグリティに設定すると、ホスト上の任意の低インテグリティプロセスの「シンク」になり、サンドボックスへの限定的なアクセス付与だけではなくなります。

「非昇格サンドボックス」プロトタイプ

最初のプロトタイプは管理者権限なし（非昇格）での実行に焦点を当て、Security Identifiers (SIDs) と書き込み制限トークンを利用してファイルシステムアクセスを管理しました。

ファイルシステム書き込み制限

Codexがファイルを変更できる場所を制御するために、チームは合成SIDと書き込み制限トークンの組み合わせを使用しました：

  1. Synthetic SIDs: カスタムの sandbox-write SID を作成し、Access Control Lists (ACLs) で権限を定義し、他のシステムユーザーに干渉しないようにしました。
  2. Write-Restricted Tokens: これらのトークンは書き込み操作が成功するために二つのチェックが必要です。通常のユーザーIDが許可されていること、そしてトークンの制限リストにある少なくとも一つのSID（sandbox-write SID を含む）がアクセスを許可されていることです。

これにより、Codexは現在の作業ディレクトリおよび設定された writable_roots に対して書き込み/実行/削除アクセスが付与され、.git、.codex、.agents フォルダーなどの機密領域へのアクセスは明示的に拒否されます。

ネットワークアクセス制限

プロトタイプが非昇格だったため、Windows ファイアウォールを使用できませんでした。その代わりに、環境変数（HTTPS_PROXY、GIT_HTTPS_PROXY）を汚染したり、PATH の先頭に denybin ディレクトリを追加して SSH や SCP の呼び出しをインターセプトするなどの「助言的」な制限に依存していました。しかし、このアプローチはプロセスが環境変数を簡単に回避したり、ソケットを直接開くことができるため、十分に強固ではないことが判明しました。

最終的な「昇格サンドボックス」アーキテクチャ

堅牢なネットワーク抑制を実現するため、OpenAIはセットアップ時に管理者権限が必要な「昇格サンドボックス」へと移行し、ファイアウォールルールと専用システムユーザーを実装しました。

セットアップと権限

codex-windows-sandbox-setup.exe バイナリが昇格された設定を処理します：

  • User Creation: CodexSandboxOffline（ファイアウォールルールでブロック）と CodexSandboxOnline（ブロックされない）の二つのローカルユーザーを作成します。
  • Credential Management: ユーザー認証情報は Windows Data Protection API (DPAPI) を使用して暗号化されます。
  • Firewall Rules: CodexSandboxOffline ユーザーに対しては外部ネットワークアクセスが完全にブロックされます。
  • Read ACLs: サンドボックスユーザーは実際のユーザーとは別であるため、セットアップは非同期に必須ディレクトリ（例：C:\Users\<real-user>、C:\Windows\、C:\Program Files\）への読み取り/実行権限を付与し、エージェントが必要なファイルを読み取れるようにします。

コマンド実行フロー

Windows の特権境界のため、codex.exe は制限トークンを持つ別ユーザーとして直接プロセスを生成できません。そのため、実行フローを分割するために codex-command-runner.exe を導入する必要がありました：

  1. Initiation: codex.exe は CreateProcessWithLogonW を使用して、指定されたサンドボックスユーザーとして codex-command-runner.exe を起動します。
  2. Restriction: ランナー内部で、プロセスは自身のトークンを開き、CreateRestrictedToken を用いて制限トークンを作成し、続いて CreateProcessAsUserW で最終的な子プロセス（例：Python スクリプトや Git コマンド）を起動します。

サンドボックスコンポーネントスタックの概要

最終的なアーキテクチャは、セキュリティと開発者の生産性のバランスを取るために、4 つの異なる層で構成されています：

  • codex.exe: メインの非昇格ハーネス。
  • codex-windows-sandbox-setup.exe: 昇格されたセットアップ、ユーザー作成、ファイアウォール設定を処理します。
  • codex-command-runner.exe: 制限トークンを生成し、サンドボックスユーザーとして最終的な子プロセスを起動します。
  • The Child Process: エージェントが制限された権限で実行する実際のコマンド。

Sources