OpenAI Engineering Blog 解説: Codex on Windows の sandbox 設計

OpenAI は 2026年5月15日、Engineering / セキュリティ の公式ブログとして Building a safe, effective sandbox to enable Codex on Windows を公開しました。Codex が Windows 上で command execution を安全に扱うための サンドボックス 設計を説明する記事です。

要点

• Codex for Windows で、command execution を安全に制約する サンドボックス implementation の設計が説明された
• AppContainer、Windows サンドボックス、Mandatory Integrity Control labeling などを検討したが、Codex の open-ended 開発者 ワークフロー には課題があった
• 現行実装は setup 時に elevated admin 権限 を使う elevated sandbox
• CodexSandboxOffline と CodexSandboxOnline という local ユーザー を使い、firewall rules と restricted トークン を組み合わせる
• Codex の default mode が ワークスペース write と network restriction を OS レベルで実効化するための基盤として重要

今回のブログ記事で語られていること

OpenAI の記事は、Codex が コーディング エージェント として 開発者 laptop 上で command を実行する以上、OS が強制する isolation が必要だという問題設定から始まります。Codex は shell、Git、Python、package managers、build tools など、モデル が必要と判断したローカルコマンドを harness 経由で動かします。これは強力ですが、ユーザー権限のまま無制限に動かすと危険です。そのため Codex の default mode は、ファイルを読み、ワークスペース 内に書き、必要に応じて network access を制御する サンドボックス を前提にしています。

macOS や Linux では Seatbelt、seccomp、bubblewrap のような仕組みを使えますが、Windows では同じ要件を満たす標準機能が簡単にはありません。記事では、AppContainer、Windows サンドボックス、Mandatory Integrity Control labeling が検討対象として挙げられています。AppContainer は OS 境界として魅力的ですが、必要な capabilities を事前に決める アプリ に向いた仕組みで、shell や build tools を自由に呼ぶ Codex の ワークフロー には合いにくいと説明されています。Windows サンドボックス は軽量 VM ですが、Codex の通常操作には重く、host ワークスペース や tooling との統合が難しくなります。

OpenAI が現在の実装として説明するのが elevated sandbox です。setup 時に elevated admin 権限 が必要ですが、Codex が command を spawn する runtime 境界では restricted トークン を使い、書き込みや network を制約します。大きな違いは、command の principal が実ユーザーではなく、Codex が作る local ユーザー になる点です。記事では、offline 用の CodexSandboxOffline と online 用の CodexSandboxOnline が挙げられ、firewall rules との組み合わせで network control を実現する設計が説明されています。

この設計は、Windows で Codex を使う組織にとって実務上の意味があります。開発者が Full Access mode を常用するのではなく、default mode で ワークスペース write と network restriction が効くなら、agentic コーディング のリスクをかなり下げられます。一方で、setup に admin 権限 が必要なこと、local ユーザー と firewall rules が作られること、企業端末の エンドポイント セキュリティ / デバイス management / least privilege ポリシー とどう整合するかは、IT 管理者が確認すべき点です。

また、記事は Codex の安全性を「モデルが安全に振る舞うか」だけではなく、「OS が command execution をどこまで制約できるか」として扱っています。コーディング エージェント は、モデル出力が shell command になり、ファイル変更、dependency インストール、テスト execution、network call につながります。安全な agentic development には、プロンプト ポリシー、approval UI、secret scanning だけでなく、プロセス tree に伝播する OS enforced boundary が必要です。

Windows 版の サンドボックス 設計は、Codex の利用対象を広げるうえでも重要です。Windows 開発者は、これまで approvals を細かく求められるか、Full Access を許すかの二択になりがちでした。サンドボックス が実用的に動けば、開発者 experience と セキュリティ control の両立がしやすくなります。

対象になりそうなチーム

• Windows 端末で Codex CLI / IDE / アプリ を使う software engineering team
• 開発者 workstation セキュリティ を管理する IT / エンドポイント セキュリティ team
• コーディング エージェント の command execution ポリシー を設計する platform / セキュリティ team

実務で確認したいポイント

Windows で Codex を展開する場合、サンドボックス setup に必要な admin 権限、作成される local ユーザー、firewall rules、エンドポイント protection との相互作用、network access を許す条件を確認します。企業環境では、MDM / EDR / firewall ポリシー と Codex サンドボックス の整合性を検証してから広げるのが安全です。

結局、この発表をどう見るべきか

Codex on Windows の サンドボックス は、コーディング エージェント を実務端末で安全に動かすための基盤です。Windows サポート の機能追加というより、エージェント が local command を扱う時代の エンドポイント isolation 設計として読むべき記事です。