OpenAI Codex が Windows 向けサンドボックスを自社実装——設計の全工程と技術的判断を公開

記事のサマリー（TL;DR）

OpenAI の Codex は macOS・Linux では OS 標準サンドボックスを利用できたが、Windows には同等の機能がなく独自実装が必要だった
AppContainer・Windows Sandbox・MIC ラベルの3候補をすべて採用できず、SID と制限付きトークンによる「非昇格サンドボックス」→ Windows Firewall を加えた「昇格サンドボックス」へ2段階で設計を進化させた
最終的に codex.exe / codex-windows-sandbox-setup.exe / codex-command-runner.exe / 子プロセスの4層構成を採用し、ファイル書き込み制御とネットワーク遮断を両立した

Windows 向け AI コーディングエージェント導入を検討する開発チームへの示唆

Codex のような AI コーディングエージェントを Windows 環境で業務利用する場合、OS 標準の権限分離機構の有無が安全性に直結する。今回 OpenAI が公開した詳細は、同種の課題を抱える企業内開発環境にとって実践的なリファレンスとなる。特に企業の Windows PC 上で自律エージェントを動かすケースでは、ファイルシステムへの書き込み範囲と外部ネットワークアクセスの2点が最重要の管理ポイントとなる。kintone・Salesforce・freee などの業務 SaaS と連携する自社開発スクリプトを Codex に触れさせる構成では、writable_roots の適切な設定と、オフライン用サンドボックスユーザー（CodexSandboxOffline）によるファイアウォール制御の組み合わせが安全運用の前提条件となる。Windows Home SKU では Windows Sandbox 自体が使えないため、エンタープライズ・Pro SKU の確認も先決事項として押さえておく必要がある。

詳細

なぜ Windows にサンドボックスが必要だったのか

Codex は開発者のラップトップ上で動作するコーディングエージェントであり、CLI・IDE 拡張・デスクトップアプリを経由して人間とクラウド上のモデルの会話を仲介する。デフォルトでは実ユーザーの権限で動作するため、ファイルの読み書き・Git 操作・テスト実行・パッケージインストールなど、ユーザーができることは原則すべて実行できる。

macOS では Seatbelt、Linux では seccomp や bubblewrap といった OS 標準ユーティリティを使ってサンドボックスを実現できる。一方 Windows にはこれに相当する機能が標準では存在しないため、2025年9月時点で Windows ユーザーは「ほぼすべてのコマンドを手動承認する」か「Full Access モードで制限なく実行させる」かの二択を強いられていた。

Codex のデフォルトモードは、ワークスペース（Codex を起動したディレクトリ）への書き込みを許可しつつ、インターネットアクセスは明示的に許可しない限り遮断するという設計を目指している。この制約を OS レベルで強制するにはサンドボックス環境が必須であり、Windows 向けに自前で実装することが要件となった。

既存の Windows ツールが採用できなかった理由

AppContainer

AppContainer は Windows ネイティブのサンドボックスで、ケイパビリティベースの分離モデルだ。事前にアクセス先が明確に定義されたアプリには適合するが、Codex のようにシェル・Git・Python・パッケージマネージャ・ビルドツールなど不特定多数のバイナリを動かすオープンエンドなエージェントワークフローとは相性が悪い。「開発者として動くエージェント」というユースケースには分離の形が合わなかった。

Windows Sandbox

Microsoft の使い捨て軽量 VM であり、セッション終了時に中身が消去される強固な分離境界を提供する。ただし Codex は実際のユーザーチェックアウト・ツール・環境に直接作用する必要があり、別の使い捨てデスクトップを介する構成はホスト/ゲスト間のブリッジが必要になる。さらに Windows Home SKU では利用自体が不可能という製品上の制約もあった。

Mandatory Integrity Control（MIC）ラベリング

Windows の「整合性レベル」（低・中・高）を利用し、Codex を低整合性で実行してワークスペースを低整合性にリラベルするアプローチ。見た目は洗練されているが、ワークスペースを低整合性にマーキングすると「Codex がそこに書ける」だけでなく「低整合性プロセス全般が書き込める」ことを意味し、実際の開発者マシン上ではチェックアウト全体のトラストモデルを大きく変えてしまうリスクがあった。

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

既存ツールがすべて不採用となったため、OpenAI チームは独自設計に着手した。最初の設計方針は 管理者権限（昇格）を不要にすること であり、ファイル書き込みとネットワークアクセスの2点を制限することを目標とした。

SID と書き込み制限トークンによるファイル制御

SID（Security Identifier）: Windows がアクセス権に紐付けるアイデンティティ。合成 SID を作成して ACL（アクセス制御リスト）に含めることで、実ユーザーに干渉せずサンドボックス専用のアクセス制御が実現できる
書き込み制限トークン（Write-Restricted Token）: 書き込み操作に追加チェックを加えるプロセストークン。通常のユーザー ID による許可に加え、制限付き SID リストの中に少なくとも1つの許可済み SID が存在しないと書き込みが成功しない二重チェック構造

具体的な動作は以下のとおり。

サンドボックスセットアップが sandbox-write という合成 SID を作成
sandbox-write SID に対して、カレントワーキングディレクトリおよび config.toml で設定した writable_roots への書き込み・実行・削除アクセスを付与
<cwd>/.git・<cwd>/.codex・<cwd>/.agents などの「書き込み可能範囲内の読み取り専用」場所への書き込みは明示的に拒否
Codex は [Everyone, ログオン SID, sandbox-write 合成 SID] を制限 SID リストに含む書き込み制限トークンでコマンドを起動

ネットワーク遮断の限界

管理者権限なしで使える Windows Firewall がなかったため、ネットワーク制限は「ベストエフォート」に留まった。具体的には以下の環境変数オーバーライドで代替した。

HTTPS_PROXY=http://127.0.0.1:9
ALL_PROXY=http://127.0.0.1:9
GIT_HTTPS_PROXY=http://127.0.0.1:9
NO_PROXY=localhost,127.0.0.1,::1
GIT_SSH_COMMAND=cmd /c exit 1

また、スタブの SSH・SCP スクリプトを含む小さな denybin ディレクトリを PATH の先頭に追加し、PATHEXT を並び替えることで主要な抜け穴を塞いだ。しかしこのアプローチには根本的な問題があった。プロセスが環境変数を無視したり、PATH をバイパスしたり、直接ソケットをオープンしたりすれば容易に回避できる。

第1プロトタイプの評価

利点:

管理者権限不要でサンドボックスが起動できる
ファイルシステムの書き込みを細粒度で制御できる
実システムへのフットプリントが小さい（合成 SID に限定）

欠点:

ACL 適用のコストがワークスペース構造によって高くなる
ファイルベース制限の変更が高コストかつ複雑
ネットワーク保護が実質的にアドバイザリ（回避可能）

ネットワーク保護の脆弱性は設計上許容できないと判断し、次のイテレーションへ進んだ。

再設計：「昇格サンドボックス」

Windows Firewall によるネットワーク遮断を使うには、コマンドを「実ユーザー」ではなく「別のプリンシパル」として実行する必要があった。これにより「昇格なし」の制約を緩和し、セットアップ時に管理者権限を要求する設計へ移行した。

2つのサンドボックスユーザー

Codex はセットアップ時に2つのローカル Windows ユーザーを作成する。

CodexSandboxOffline: すべてのアウトバウンドネットワークアクセスをブロックするファイアウォールルールの対象
CodexSandboxOnline: ファイアウォールルールの対象外

各ユーザーの認証情報は Windows Data Protection API（DPAPI）で暗号化してローカルに保存され、サンドボックスユーザー自身は参照できない場所に格納される。

セットアップステップの詳細

合成 SID を作成（未作成の場合）
オンライン・オフラインのサンドボックスユーザーを作成（未作成の場合）
ユーザー認証情報を DPAPI で暗号化して保存
CodexSandboxOffline ユーザーへの全アウトバウンドネットワークアクセスをブロックするファイアウォールルールを作成（または既存ルールを検証）

また、サンドボックスユーザーが実ユーザーと同等の読み取りアクセスを持てるよう、以下の共通 Windows ディレクトリに読み取り ACL を付与する処理を非同期で実行する。

C:\Users\<real-user>\
C:\Windows\
C:\Program Files\
C:\Program Files (x86)\
C:\ProgramData\

この ACL 付与処理は時間がかかるため非同期化し、ユーザーをブロックするセットアップステップとは分離している。

`codex-command-runner.exe` の誕生

別 Windows ユーザーとしてプロセスを起動するには CreateProcessAsUserW(...) が必要だが、実ユーザー側からこの API を直接呼び出すには特権の壁があり実用的でなかった。そこで処理を2段階に分割した。

Part 1（codex.exe 側）
CreateProcessWithLogonW(...) を呼び出し、制限トークンなしでサンドボックスユーザーとして codex-command-runner.exe を起動する。

Part 2（codex-command-runner.exe 内部）

OpenProcessToken(GetCurrentProcess(), ...) で自身のトークン（サンドボックスユーザー所属）を取得
GetTokenInformation(...) でサンドボックスログオン SID を抽出
CreateRestrictedToken(...) で最終的な制限トークンを作成
CreateProcessAsUserW(...) でその制限トークンを使って実際の子プロセスを起動

最終アーキテクチャ：4層構造

最終的なアーキテクチャは以下の4層で構成される。

レイヤー	役割
`codex.exe`	メインハーネス。通常権限で動作
`codex-windows-sandbox-setup.exe`	昇格が必要なすべてのセットアップを担当する専用バイナリ
`codex-command-runner.exe`	制限トークンの作成と子プロセスの起動専用バイナリ
子プロセス	実際のエージェントコマンド（Git・Python 等）

セットアップロジックを独立したバイナリに分離した理由は複数ある。UAC 境界を必要な時だけ越える設計にすること、codex.exe を通常の非昇格ハーネスとして維持すること、Windows 専用のセットアップ機構を他プラットフォームに影響させないこと、そしてメインプロセスのライフタイムとセットアップ処理を分離することが主な理由だ。

安全性と実用性のバランス

このプロジェクトから得られた2つの教訓を OpenAI チームは挙げている。

教訓1: Windows は「安全な自律コーディングエージェント」に直接マッピングできるプリミティブを提供していなかった。複数のツールと概念を組み合わせて整合性のある仕組みを構築する必要があった。初期アイデアのいくつかは行き詰まり、最終設計は各プロトタイプが部分解として提供した要素のハイブリッドとなった。

教訓2: コーディングエージェントのセキュリティは、古典的なアプリケーションセキュリティとは性質が異なる。Codex は実際の開発者ワークフローで機能しなければならないため、エージェント的なワークロードとの互換性と真の実行制御のバランスを取り続けることが設計全体を通じた緊張関係だった。