OpenAI、Codex の Windows サンドボックスを再設計。Mac/Linux と同じ「全コマンド自動承認なし」体験へ
Codex の Windows 版が、ようやくまともになった話です。
OpenAI が 5 月 13 日付で公開したエンジニアリングブログで、コーディングエージェント Codex の Windows 用サンドボックス再設計の経緯を明かしました。これまで Windows ユーザーは「コマンドごとに承認」か「Full Access モードで全部許可」の二択を迫られていました。Mac や Linux と違って、Windows には Seatbelt や seccomp に相当する「OS が標準で提供する強い分離機能」が無かったからです。
ざっくり言うと、Codex 側で独自のサンドボックスを実装するしかなかった、という話です。今回のブログはその試行錯誤と、いまの実装に至るまでの設計判断を、当事者のエンジニアが書いています。
何が変わったのか
ポイントはひとつで、Windows 上で Codex を動かしても、Mac/Linux と同じく「ファイル書き込みは作業ディレクトリ内に限定」「ネットワークは原則遮断」が OS レベルで強制 されるようになりました（以前は環境変数ベースの「ふりだけ」でした）。
これ、なかなかすごいんですよ。以前の試作（OpenAI が「unelevated sandbox」と呼んでいるバージョン）はネットワーク遮断が `HTTPS_PROXY=http://127.0.0.1:9` のような環境変数や、PATH の前段に置いたダミー実行ファイルでの「ふりだけ」でした。OpenAI 自身が advisory（強制力のない助言）と書いている通り、悪意あるコードがソケットを直接開けばすり抜けられる。
それを根本から変えたのが今回の「elevated sandbox」です。
仕組みをやさしく — どうやって守っているのか
要はこういうことですね。Codex は起動時に CodexSandboxOffline と CodexSandboxOnline という専用の Windows ローカルユーザーを 2 つ作っておきます。実際にコマンドを動かすときは、ログインしているあなた本人ではなく、この専用ユーザーの権限で動かす。
そうすると Windows Firewall のルールを「このユーザーのアウトバウンドだけ全部止める」と書けるようになる。Codex のプロセスツリー全体に効くので、Git でも Python でも git clone でも、ファイアウォールが知らないところで勝手にネットには出られません。
ファイル書き込みは、専用ユーザーに対して sandbox-write という合成 SID（Windows のセキュリティ識別子）を割り当てて、作業ディレクトリだけに書き込み権限を ACL（アクセス制御リスト）で渡す。書き込み制限つきトークン（write-restricted token）の仕組みと組み合わせるので、Codex から派生したどの子プロセスも、その境界の外には書けない。
<cwd>/.git <cwd>/.codex <cwd>/.agents の 3 つは「作業ディレクトリの中だけど書き込ませない」という明示的な denial が入っている、という細かい話まで書かれています。仕事道具に勝手にコミットされない、ということです。
セットアップで一度だけ管理者権限が要る
ちょっと立ち止まって考えると、専用ユーザーを作る・Firewall ルールを足す・各種 ACL を書く——これは admin 権限がないとできません。なので Codex の初回セットアップでは管理者昇格（UAC）が一度だけ走ります。
OpenAI は最初、admin 昇格なしでやろうとしていました。最初の試作はそのために unelevated 設計だった。でもネットワーク強制が advisory になる時点で「うちが守りたい安全水準じゃない」と判断して、elevation を許す方向に舵を切った経緯がブログにそのまま書いてあります。実装担当のエンジニアが「elevation 要求は嫌だったが、firewall を入れるには principal を別ユーザーにするしかなかった」と書いていて、設計判断の生々しさが残っています。
セットアップ専用のバイナリは codex.exe 本体とは別に分けてある。これは Mac/Linux のビルドに不要なコードを混ぜないため、という地味だけど合理的な理由です。
いまの実力と限界
公開された設計を素直に読むと、Mac/Linux と同じ「デフォルト安全運転」モードが Windows でも素直に使える、というところまで来ています。資格情報は DPAPI（Windows Data Protection API）で暗号化して保存し、サンドボックスユーザー自身は読めない場所に置く。読み取り ACL の付与（C:\Users\<real-user> C:\Windows C:\Program Files 系）はバックグラウンドで非同期に走るので、起動待ち時間が膨らまない。
ただし、これは「サンドボックス内のコマンドがネット越しに悪さできない」という保証であって、開発者が --full-access を意図して有効化したり、許可を出した範囲で外に出る挙動は当然そのまま可能です。エージェントの自律性をどこまで広げるかは、いままで通り使う側が決める設計です。続報待ちですね。
日本のユーザーにとっては
日本では Windows 11 Home / Pro で Codex CLI を使っている個人開発者、社用 Windows ノートで AI コーディングを試している情シス、社内コードを扱う SIer——このあたりが直接効きます。Windows Sandbox は Home SKU で動かないため使えなかった、というブログの記述は、社用 Home 機を配布されている現場には地味に効く話です。
社内ポリシーで「AI ツールはアウトバウンドを許可制で」と縛っている法人ユーザーにとっても、firewall が OS レベルで効くなら、「使わせたいが情報持ち出しが怖い」というよくある板挟みが少し楽になる可能性があります。
で、何が変わるかというと
Codex を Windows で使っていた人は、「全部承認するか、全部開放するか」の極端な二択から解放されます。Mac/Linux と同じ感覚で、デフォルトのまま安心して動かせる体験に揃った、というのが今回の本質。社内導入を検討していた現場は、これで「Windows 端末で AI エージェントを動かす標準的なやり方」がようやくひとつ提示された格好です。
個人的には腑に落ちる話で、設計判断の経緯まで開示してくれているのは、社内に説明するときの材料としても助かる。動向は追っておきたいです。
情報元
– OpenAI Engineering Blog — Building a safe, effective sandbox to enable Codex on Windows（2026-05-13）
– OpenAI — Codex product page
