CodexのWindows版に、Microsoftの仕組みを使う新しいサンドボックス「MXC」が加わりました。OpenAI Developersは2026年10月9日の投稿で、セットアップの速さ、ネットワーク制御の強さ、ファイルアクセスの細かい制御を挙げています。従来の方式との大きな違いは、管理者の承認を伴うセットアップ、追加のWindowsアカウント、ローカルのファイアウォール規則がいらないことです（公式のWindows sandboxの説明）。この記事では、使える条件、設定、確認コマンド、会社で使うときの制御と注意点を公式資料から整理します。
10月9日に何が変わったか
元のX投稿を見る
OpenAI DevelopersがXで公開した告知です。MicrosoftのExecution Containers（MXC）を使う新しいサンドボックスで、セットアップの速さ、ネットワーク制御の強さ、ファイルアクセスの細かい制御を挙げ、対応するWindows 11端末が必要と案内しています。この投稿に動画はありません。
出典：OpenAI Developersの元投稿をXで見る ↗ · 確認日：2026-10-10CodexはWindows上でコマンドを実行するとき、サンドボックス（作業できる範囲を区切る仕組み）の中で動かします。これまでの選択肢はelevatedとunelevatedの2つでした。今回、3つ目のmxcが加わり、対応する端末では推奨の方式になりました。
MXCはMicrosoft Execution Containersの略で、Windowsに組み込まれたプロセス隔離の機能です。OpenAIの投稿は「対応するWindows 11端末が必要」としています。WSLや仮想マシンを使わず、Windowsのままファイルとネットワークの権限を区切れる点は従来と同じです。
MXC・elevated・unelevatedの違い
公式資料は3つの実装を次のように説明しています。
| 実装 | 位置づけ | 準備に必要なもの | 制約 |
|---|---|---|---|
mxc | 対応端末での推奨 | 管理者の承認、追加のWindowsアカウント、ローカルのファイアウォール規則はいずれも不要 | 端末側にMXCの機能が必要。下の「注意点」を参照 |
elevated | MXCが使えない・無効なときの第一候補 | 管理者の承認を伴うセットアップ（専用の低権限ユーザー、ファイアウォール規則、ローカルポリシーの変更） | サンドボックス内のコマンド自体は管理者権限なしで動く |
unelevated | elevatedのセットアップができず、組織のポリシーが許す場合の予備 | 今のユーザーから作った制限付きトークン | elevatedよりネットワーク隔離が弱く、読み取り禁止のパスを指定できない |
公式の推奨順は「使えるならMXC、だめならelevated、それも無理ならunelevated」です。会社のPCで管理者の承認が通らず、ネットワーク隔離の弱いunelevatedを使っていた人にとって、MXCは管理者の承認を伴うセットアップなしで使える選択肢になります。ただし、端末の対応と会社のポリシーが前提です。
使える端末の条件
MXCを使うには、端末にMicrosoft Execution Containersの機能が入っている必要があります。公式資料によると、MicrosoftはMXCのプロセス隔離を次のビルドで導入し、Windows 11端末へ順次配布しています。
- Windows 11 24H2：ビルド26100.9278
- Windows 11 25H2：ビルド26200.9278
ただし、バージョンの対応表は「その端末でMXCが使える」ことを保証するものではない、とも書かれています。ビルド番号だけで判断せず、次の章の確認コマンドで実際に動くかを見てください。なお、Codex全体の対応表では、最新の更新を適用したWindows 10は「ベストエフォート」、古いビルドは非推奨とされ、企業での標準化にはWindows 11が勧められています。
MXCを有効にする方法
ChatGPTのデスクトップアプリは、個人アカウントで端末が対応していれば、自動でMXCを優先します（設定リファレンスでは、アプリ側は段階的な展開の設定で有効になると説明されています）。一方、単体のCodex CLIでは初期設定で無効です。CLIや会社での配布では、config.tomlに次を書きます。
[features]
prefer_mxc = trueこの設定は「使えるときはMXC、使えないときは従来の選び方」という意味です。端末によって対応状況が違う会社では、予備として従来方式も指定しておくよう公式は勧めています。
[windows]
sandbox = "elevated" # or "unelevated"逆に、windows.sandbox = "mxc"と直接指定すると、MXCが使えない端末やポリシーで禁止された環境では失敗します。予備に切り替わるのはprefer_mxcを使った場合だけです。また、設定リファレンスには「コマンド自体の失敗では予備に切り替わらない」と書かれています。テストやビルドの失敗をサンドボックスの問題と混同しないようにしてください。
保存済みの設定を変えずに1回だけ試す
Codex CLI 0.162.0以降では、保存済みのサンドボックス設定を変えずに、MXCで1つのコマンドだけを試せます。プロジェクトのフォルダでPowerShellを開き、次を実行します。
codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODEMXC_OKと表示され、終了コードが0なら成功です。このコマンドは、作業フォルダ用の権限プロファイルと、会社が配布した必須設定（managed requirements）を含めた状態で、コマンドが起動できるかを確かめます。CLIが古い場合は、先にcodex --versionで0.162.0以降かを確認してください。導入手順はCodex CLIのインストールガイドにまとめています。
公式が示す成功の条件は「MXC_OKと終了コード0」だけです。それ以外の結果の読み方を、編集部の目安として表にまとめます。
| 結果 | 考えられること | 次にやること |
|---|---|---|
MXC_OKと終了コード0 | この端末と設定でMXCが起動できる | prefer_mxc = trueを設定し、普段の作業を試す |
| エラーで止まる | 端末にMXCの機能がない、または会社のポリシーで禁止されている | Windowsのビルドと、管理者がallow_mxc = falseを配布していないかを確認する |
| コマンドが見つからない・オプションの誤り | CLIが0.162.0より古い | CLIを更新してから再実行する |
会社で使うときの制御
管理者はrequirements.tomlでMXCの扱いを決められます。組織でMXCを使わせない場合は、次を配布します。
[windows]
allow_mxc = falseこれで、自動選択（prefer_mxc）と直接指定の両方が止まります。従来方式の設定はそのまま有効です。なお、この項目を書かない、またはtrueにしても「MXCを許可する」だけで、MXCを有効にしたり強制したりはしません。
予備に使う従来方式を絞ることもできます。
[windows]
allowed_sandbox_implementations = ["elevated"]この例ではelevatedだけを許可し、unelevatedへの切り替えを防ぎます。この一覧はMXCを制限しません。MXCも止めたい場合は、上のallow_mxcを別に指定します。また管理者は、features.prefer_mxc = trueを初期値として配る方法と、必須設定として強制する方法を選べます。どちらも従来方式への切り替えは残ります。
切り替える前に確かめる注意点
公式資料は、MXCの互換性について2つの制限を挙げています。
- ネットワーク：会社が配布したネットワーク設定（managed networking）を使う場合は、実効値で
allow_local_binding = trueが必要です。MXCはホストのループバック（localhost）上のサービスとの接続を許可します。プロキシ経由の通信にはドメインの規則が引き続き適用されますが、プロキシが追加で行っていたプライベートネットワーク宛ての確認はなくなります。 - 開発サーバー：前面のコマンドが終わると、残った子プロセスも止まります。開発サーバーをバックグラウンドで起動したまま次の作業へ進む使い方をしている場合は、切り替える前に試してください。
どちらも、セキュリティの担当者と開発者で影響の受け方が違います。ネットワークの制限は管理者側、開発サーバーの挙動は開発者側で確認すると、切り替え後の「動かなくなった」を減らせます。
うまくいかないときの確認先
- 以前は動いていたのに止まった：Codexを再起動し、MXCなら確認コマンドを再実行して、実効のネットワークポリシーを見ます。リポジトリの移動、端末の権限やWindowsポリシーの変更の後に起きることがあります。
- フォルダが読めない：CLIの
/statusと/debug-configで、今の権限プロファイルと設定を確認します。サンドボックスを無効にするのではなく、管理者に必須設定の見直しを頼むよう公式は案内しています。 - OpenAIに問い合わせる：
CODEX_HOME/.sandbox/sandbox.logに、使っていた実装（mxc・elevated・unelevated）、エラー表示、Windowsのビルド番号を添えて送ります。CODEX_HOME/.sandbox-secrets/の中身は送りません。
Codexに確認を頼む依頼文の例
手元の設定を確かめる作業をCodexに頼む場合の例です。編集部が作った依頼文の例で、実行結果を示すものではありません。設定ファイルの変更は、結果を見て自分で判断してください。
このWindows端末で、CodexのサンドボックスをMXCに切り替えられるか確認したいです。
設定ファイルはまだ変更しないでください。
1. codex --version の結果と、Windowsのエディション・バージョン・ビルド番号を報告する
2. 今の config.toml にある [features] と [windows] の設定を、値を変えずに書き出す
3. CLIが0.162.0以降なら、公式の確認コマンドを1回だけ実行し、出力と終了コードをそのまま報告する
4. このプロジェクトで、開発サーバーをバックグラウンドで起動したまま使う手順があるかを探し、あれば場所を示す
5. 以上から、prefer_mxc = true にしてよいか、予備の windows.sandbox に何を残すかの案を出すプロジェクト固有の前提をCodexに毎回伝える方法は、AGENTS.mdの書き方で解説しています。
よくある質問
WSLを使っている場合も切り替えるべきですか？
WSL2の中で動かすCodexは、Linux用のサンドボックスを使います。公式は、通常はWindowsネイティブのサンドボックスを使い、Linuxのツールが必要な場合や作業がすでにWSL2にある場合はWSLを選ぶよう案内しています。MXCはWindowsネイティブで動かす場合の選択肢です。
MXCなら管理者権限は一切いりませんか？
MXCを使うために、管理者の承認を伴うセットアップは不要と説明されています。ただし、端末にMXCの機能が入っていることが前提で、会社のポリシーで禁止されていれば使えません。Windowsの更新や配布の状況は、各社の管理者に確認してください。
サンドボックスが面倒なら、フルアクセスにしてもよいですか？
公式は、フルアクセスではCodexがプロジェクトのフォルダに限定されず、意図しない破壊的な操作でデータを失うおそれがあると注意しています。例外が必要な操作は、サンドボックスを外すのではなく承認とセキュリティの設定や規則で個別に許可する方法が勧められています。
