先に結論
OpenAI が今回出した Windows 向け sandbox 実装の価値は、Codex をもっと自由に動かせるようにしたこと ではありません。どこまで自動で動かしてよくて、どこから止めるかを Windows でも現実的に設計しやすくしたこと にあります。
これまで Windows では、Codex を安全に使おうとすると approve が増えやすく、逆に friction を消そうとすると Full Access に寄りがちでした。今回の実装は、その間に workspace だけを書ける制限付き運用 を置こうとした更新です。
Windows 向け AI coding tool の全体像を先に見たいなら Windows向けAIコーディングツール比較【2026年版】Codex app vs Cursor vs Claude Code vs GitHub Copilot、承認設計の考え方を広く見たいなら Claude Code Auto Mode vs Codex approval policy vs GitHub Copilot も合わせて読むと整理しやすいです。
何が変わったのか
今回のポイントは、Windows でも「読める範囲」と「書ける範囲」を分けた sandbox をちゃんと説明できるようになったこと です。
OpenAI の engineering post では、Codex はもともとユーザー権限で動くため、読み取りや編集、テスト実行、Git 操作まで広く触れます。そのままだと便利ですが、ローカル環境では危険も大きいです。
そこで Windows 向けでは、次の考え方が前面に出ました。
- 読み取りは広めに許しつつ、書き込みは workspace と
writable_rootsに寄せる .git、.codex、.agentsのような場所は read-only に寄せる- ネットワークはデフォルトで自由にせず、必要時だけ明示的に扱う
- 子プロセスまで同じ制限境界に残す
要するに、Windows でも「何でもできる agent」ではなく「必要な範囲だけ動ける agent」に近づけた ということです。
以前の課題は、approve 地獄か Full Access かの二択になりやすかったこと
OpenAI は、Windows 版 Codex が抱えていた元の問題をかなり率直に書いています。安全側に倒すと、agent がやりたい読み取りや実行まで細かく承認しがちでした。楽に使おうとすると、今度は Full Access でほぼ無制限になります。
この二択は、個人開発でも扱いにくいです。社内端末ならなおさらです。開発者は毎回 approve したくありませんが、情シスや platform team も unrestricted 実行を標準にはしにくいからです。
今回の更新は、この二択の間に 制限付きで前進できる実装 を置いたことに意味があります。
制限モデルはどうなったか
最初の試作段階では、OpenAI は synthetic SID と write-restricted token を使い、どこに書き込めるかを ACL で細かく制御する 方向を試していました。
ここで重要なのは、書き込み可能な場所を最初から狭く置いていたことです。基本は current working directory と writable_roots だけです。その内側でも .git、.codex、.agents は read-only に寄せています。
これだけでも、日常的な修正や生成を回しながら、Git メタデータや agent 管理領域まで好き放題に書かせない形は作れます。
ただし問題はネットワークでした。初期案では proxy 変数や PATH 上の denybin で Git や SSH を失敗しやすくする工夫を入れていましたが、これは強制力が弱く、独自の networking stack を使うプログラムには抜け道が残ります。
そのため OpenAI は、最終的に 別の Windows ユーザーと firewall rule を使う elevated sandbox へ設計を寄せています。現在の実装では、オフライン用とオンライン用の sandbox user を分け、ネットワークを止めたい側には outbound block をかける説明です。
つまり今回の sandbox は、単に「ACL を付けた」話ではありません。書き込み制限とネットワーク制限を、Windows で実用レベルまで持っていくための再設計 です。
AppContainer、Windows Sandbox、MIC を採らなかった理由
ここは Windows 利用者にとってかなり参考になります。OpenAI は、既存機能を知らなかったのではなく、試した上で外しています。
AppContainer を採らなかった理由
AppContainer は OS 境界としては魅力がありますが、Codex の仕事には狭すぎます。Codex は単一アプリではなく、shell、Git、Python、package manager、build tool まで含む開いた開発者ワークフローを動かすからです。
OpenAI の説明をそのまま読むと、強い隔離はあるが、開発者がその場で必要になる任意ツール群に向かない という判断です。
Windows Sandbox を採らなかった理由
Windows Sandbox は軽量 VM としての強さがありますが、Codex が欲しいのは捨て環境の中で完結することではありません。実際の checkout、普段の toolchain、今の環境に直接触れること が必要です。
加えて、Windows Sandbox は Windows Home で使えません。読者目線ではここも大きいです。つまり、技術的に強くても、日常の開発フローへ自然に差し込めない と判断されたわけです。
Mandatory Integrity Control を採らなかった理由
MIC は「低信頼プロセスから高信頼オブジェクトへ書けない」仕組みとして筋が良さそうに見えます。ただ、workspace 自体を low integrity に寄せると、Codex だけでなく その場所に対するホスト側の信頼モデルまで広く変わる 問題があります。
OpenAI はここをかなり重く見ています。狙いは Codex の書き込み制限であって、開発者の checkout 全体を低信頼の受け皿にしたいわけではありません。
いまの実装で、Windows 利用者が確認したいこと
ここからが実務です。今回の更新を見てすぐ「これで安心」とは言い切れません。導入前に確認したい論点は残ります。
1. writable_roots に何を含めるか
Codex に書かせたい場所を雑に広げると、せっかくの制限モデルが薄まります。逆に狭すぎると、普段の開発フローで詰まります。
まずは、どの repo、生成物、テンポラリ領域まで自動書き込みを許すかを決めたほうが安全です。
2. .git や agent 管理領域を read-only にして困らないか
OpenAI は .git、.codex、.agents を read-only に寄せる考え方を示しています。これは事故防止には効きますが、チームの運用次第では friction も出ます。
たとえば branch 操作、補助ファイルの保存、agent 用のローカル管理ファイルがどこに置かれるかは先に見ておいたほうがいいです。
監査やレビュー運用まで含めて比較したいなら GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ も参考になります。
3. 管理者権限を伴う setup を受け入れられるか
OpenAI は、より強いネットワーク制御のために elevated sandbox へ寄せています。つまり、理想だった「完全に unelevated で済ませる」話からは一歩離れました。
個人環境では受け入れやすくても、社内 Windows 端末ではここが壁になります。local admin 権限、firewall rule 作成、追加ユーザー作成がどこまで許されるかは、先に確認したほうがいいです。
4. ネットワークを止めた時に、どの作業が止まるか
外向き通信を止めれば安全性は上がりますが、Git fetch、依存取得、外部 API 呼び出しも止まりやすくなります。つまり、何を sandbox 内で完結させ、何を承認付きへ逃がすか の設計が必要です。
ここを見ずに「ネットワークを切れば安全」とだけ考えると、現場では回りません。
誰に特に効く更新か
この更新が特に効くのは、Windows で Codex を本気で使いたいが、Full Access を標準にしたくなかった人 です。
- 個人で Windows ネイティブの agent 環境を整えたい開発者
- 企業 PC で AI coding tool を試験導入したい platform team
- Mac 前提の Codex 情報だけでは導入判断しにくかった組織
逆に、単純な横並び比較だけを探しているなら、この話は少し深すぎます。見るべきはベンチではなく、Windows で安全に前進できる運用境界ができたか だからです。
まとめ
Codex for Windows sandbox 実装で変わったのは、Windows でも AI coding agent を雑に自由化せず、書き込み範囲とネットワーク範囲を絞りながら使う現実的な道 が見えてきたことです。
以前の課題は、approve 連打か Full Access かに寄りやすかったことでした。今回の設計は、その間に workspace 制限、read-only ディレクトリ、ネットワーク制御を置いています。
導入前に見るべきなのは、性能比較より運用条件です。writable_roots に何を入れるか、.git を read-only にして困らないか、管理者権限つき setup を許可できるか。この3点が噛み合うなら、Windows での Codex 導入はかなり現実的になりました。