CodexのWindows sandbox設定｜3方式の違い

「CodexをWindowsで使おうとしたら、sandboxのsetupで止まった」「elevatedとunelevatedのどちらを選べばいいのか分からない」「MXCという新しい方式が出たらしいが、自分の端末で使えるのか」——WindowsでCodexを動かすとき、多くの人がこのsandbox（AIが動かすコマンドの範囲を区切る仕組み）で手が止まります。

結論から言うと、CodexのWindows sandboxはmxc・elevated・unelevatedの3方式で、公式の優先順は mxc → elevated → unelevated です。Windows 11 24H2／25H2の対応ビルドならmxc、管理者の承認を通せるならelevated、どちらも無理なときだけunelevatedを「つなぎ」に使い、動かないからといってfull accessに切り替えない。これが基本です。

株式会社Fyveは、Codex と Claude Code を毎日の業務と無人の定期ジョブで使い、中小企業のAI導入を支援しています。この記事では、OpenAIの公式ドキュメント（2026年11月9日に確認）を軸に、3方式の違い・設定・エラーの直し方を整理し、私たちが Codex CLI 0.167.0 で確かめた sandbox の動きと、方式を選ぶときの判断を添えます。

CodexのWindows sandboxは3方式（早見表）

先に全体を表で示します。どの方式も目的は同じで、Codexが動かすコマンドに、作業フォルダの外を書き換えさせないことです。違うのは、Windowsのどの仕組みを使って区切るかです。

MXCは「Microsoft Execution Containers」の略で、Microsoftが Windows 11 に順次入れているプロセス隔離の仕組みです。OpenAIの開発者向けアカウントが2026年10月9日にCodexでの対応を告知したと報じられており、公式ドキュメントでもいまは推奨の方式として最初に書かれています。

Codexのsandboxが止めるもの（Macで確かめた動き）

方式の話に入る前に、sandboxが何を止めるのかを確認しておきます。ここが分かると「動かないからsandboxを切る」が、なぜ危ないのかが見えます。

Codexの既定は、作業フォルダの中なら読む・書く・コマンドを動かすを確認なしで進め、作業フォルダの外を書き換えるときやネットワークを使うときは確認を求める設定（workspace-write）です。公式によると、ネットワークは既定でオフです。

私たちは社内の Mac mini で Codex CLI 0.167.0 を使い、codex sandbox コマンド（指定したコマンドをsandboxの中で1回だけ動かす機能）で、この区切りを確かめました。権限のプロファイルは作業フォルダ向けの :workspace です。

Macでは、この区切りを Seatbelt（macOSのsandboxの仕組み）が担っています。Windowsでは同じ役割を mxc・elevated・unelevated のどれかが担う、という関係です。方式が違っても、Codexの側から見た「どこまで書けて、ネットワークを使えるか」の決まりは同じで、その決まりをWindowsのどの仕組みで守らせるかが3方式の違いです。

承認モードとsandboxの関係そのものは、別の記事で整理しています。

CodexCodexの承認モードとサンドボックス｜安全運用

この記事を読んでいるあなたへ無料プレゼントCodexを使い始める前に、「絶対に」見直してほしい5つのこと学習の設定・確認なしの操作・戻せる状態など。Codexにそのまま貼れる頼み方つき（全9ページ）

仕事の画面や資料を、AIの学習に使わせない設定取り返しのつかない操作が確認なしになっていないか、Codexに調べさせる頼み方AGENTS.mdのいちばん上に書く「絶対にしないこと」の例

無料でダウンロード

中身のプレビューを見る ↓登録すると、過去の特典もまとめて受け取れます（PDF 19点・合計499ページ ＋ すぐ使えるzip素材 3点）

MXC：管理者の承認なしで使える新しい方式

MXCは、Windowsそのものが持つプロセス隔離を使う方式です。公式ドキュメントは、管理者の承認が要るsetupも、追加のWindowsアカウントも、ローカルのファイアウォールの規則も要らない、と説明しています。従来のelevatedでつまずきやすかった部分がまるごと無くなるのが一番の違いです。

MXCが使えるWindowsの条件

• Windows 11 24H2：ビルド 26100.9278 以降
• Windows 11 25H2：ビルド 26200.9278 以降
• 確認コマンドを動かすには Codex CLI 0.162.0 以降

公式は「MicrosoftがWindows 11へ順次配っている」と書いています。同じ24H2でも、更新の当て方によっては対応のビルドに届いていないことがあるので、まずビルド番号を確かめます（設定 → システム → バージョン情報、または winver）。

MXCが使えるかを確かめるコマンド

作業するプロジェクトのフォルダで、PowerShellから次を実行します（公式ドキュメントのコマンドそのままです）。

codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE

MXC_OK と表示され、終了コードが 0 ならMXCが使えます。--include-managed-config は会社が配っている管理者の設定（後述の requirements.toml）も含めて試す指定なので、会社の端末ではこのまま実行するのが確実です。

MXCを使う設定（CLIとデスクトップアプリで違う）

ここが分かりにくいところです。公式ドキュメントと openai/codex のリポジトリの説明を合わせると、次のように整理できます。

• デスクトップアプリ：個人向けのアカウントでは、端末が対応していれば自動でMXCを選びます
• CLI：MXCを優先する設定（prefer_mxc）は既定でオフです。自分で config.toml に書きます

# config.toml
[features]
prefer_mxc = true

[windows]
sandbox = "elevated"   # MXCが使えない時の受け皿

prefer_mxc = true は「使えるならMXC、使えなければ従来の方式へ」という優先の指定です。公式も、受け皿として windows.sandbox を残しておくよう書いています。

一方、windows.sandbox = "mxc" と直接書くとMXCに固定になります。openai/codex のリポジトリの説明では、この指定は厳格で、端末が対応していない・ポリシーで止められているときは従来の方式に逃げずにコマンドが動きません。また、MXCを選んだあとでコマンド自体が失敗しても、別の方式でやり直すことはしない、と書かれています。「とりあえずmxcと書く」より「prefer_mxcで優先にする」ほうが、対応していない端末で止まりません。

MXCで知っておきたい動きの違い

• コマンドが終わると、そこから起動した子プロセスも止まる：開発用のサーバーを裏で立ち上げて残す使い方は、MXCの下ではできません
• ネットワークの管理を使うなら allow_local_binding = true が要る：この設定は既定で false で、自分のPC内（ループバック）や社内向けのアドレスへの接続を止めます
• 読ませないフォルダの指定（deny-read）は、各コマンドが起動した時点でパターンに一致したものが対象になります。途中で増えたファイルには効きません

MXCまわりの修正は今も続いています。公式の変更履歴では、Codex CLI 0.166.0（2026年10月29日）でMXCのパスの許可まわりの調整、0.167.0（2026年11月6日）でWindowsのMXCの「読ませないパス」の親フォルダが無い時の修正が入っています。MXCで不自然な失敗が出たら、まずCLIを最新にしてから確かめ直すのが近道です。

elevatedとunelevated：従来の方式の違い

MXCに対応していない端末では、従来の2方式から選びます。公式は elevated を優先の受け皿、unelevated をその次に置いています。

elevated（管理者の承認が要る代わりに、区切りが強い）

elevated は、sandbox専用の権限の低いWindowsユーザーを作り、ファイルの境界とファイアウォールの規則で区切る方式です。コマンド自体は管理者の権限では動きません。管理者の承認が要るのは、最初にその専用ユーザーや規則を用意するsetupのときです。

会社の端末で、利用者自身がUACを通せない場合は、IT担当が利用者の代わりに用意できます。公式ドキュメントにあるコマンドは次のとおりです（ユーザー名とフォルダは各自のものに置き換えます）。

codex sandbox setup --elevated --user 'DOMAIN\alice' --codex-home 'C:\Users\alice\.codex'

これで、そのユーザーの設定に windows.sandbox = "elevated" が保存されます。

unelevated（承認なしで使えるが、ネットワークの区切りが弱い）

unelevated は、今のユーザーから権限を削った「制限付きトークン」でコマンドを動かし、フォルダの権限（ACL）で書き込みの範囲を区切ります。管理者の承認は要りませんが、公式はネットワークの隔離が弱く、読ませないフォルダの指定にも対応しないと書いています。

私たちは、unelevated を「elevated のsetupを通すまでのつなぎ」と考えています。社外秘のファイルが置かれたフォルダや、ネットワークに出てほしくない作業では、elevated かMXCが使えるようになってから進めるほうが安全です。

従来の方式を選ぶ設定

# config.toml
[windows]
sandbox = "elevated"   # または "unelevated"

どちらも書かれていないときは、Codexは elevated を優先します。

会社でCodexを配るときの設定（requirements.toml）

会社として方式を決めたいときは、利用者の config.toml ではなく、管理者が配る requirements.toml（利用者が上書きできない設定）で制限します。公式ドキュメントの例です。

# requirements.toml（管理者が配る）
[features]
prefer_mxc = true      # MXCを優先させる（従来の方式への切り替えは残る）

[windows]
allow_mxc = false      # MXCを使わせない（自動・明示の両方を止める）
allowed_sandbox_implementations = ["elevated"]

• allow_mxc = false は、MXCを自動で選ぶことも、windows.sandbox = "mxc" と書くことも止めます。社内でMXCの検証が済むまで止めておきたいときに使います
• allowed_sandbox_implementations は従来の2方式のどちらを許すかの指定で、MXCには効きません。両方を許すなら ["elevated", "unelevated"] と書きます

Windowsでsandboxの方式を決める順番

ここまでを、迷わないための順番にまとめます。上から確かめ、当てはまったところで決めます。

1. ビルド番号を見て、MXCの確認コマンドを動かす：MXC_OK が出れば prefer_mxc = true を書いて終わりです
2. 出なければ elevated：UACを通せるならそのままsetup。会社の端末で通せないなら、IT担当に codex sandbox setup --elevated での用意を頼みます
3. それも無理なら unelevated をつなぎに：会社のポリシーが許す場合だけ。機密のある作業は後に回します
4. Linuxの道具で開発しているなら WSL2：WSL2の中でCodexを動かせば、Linux側のsandboxが使われます（次の節）

WSL2で動かす場合のsandbox

Windowsのネイティブのsandboxが既定ですが、公式は「Linuxの道具で開発している」「すでにWSL2で作業している」「ネイティブの方式では要件を満たせない」場合はWSL2を選ぶよう案内しています。

• WSL2の中で動くCodexは、Windowsの3方式ではなくLinuxのsandboxを使います。Codex 0.115 からは bubblewrap（Linuxの隔離の仕組み）です
• WSL1は 0.114 までで終わりです。WSL1のままだとsandboxが動かないので、WSL2に上げます
• デスクトップアプリは、設定のエージェントの環境を「Windows native」から「Windows Subsystem for Linux」に変えて再起動すると、WSL2の中で動きます
• VS Codeの拡張は、設定に "chatgpt.runCodexInWindowsSubsystemForLinux": true を入れるとWSL2の中で動きます

WSL2でのCodexの入れ方は、こちらで手順をまとめています。

CodexCodex CLIのWindowsインストール手順【WSL編】

Windows sandboxのエラー別の直し方

公式ドキュメントの「Troubleshooting and FAQ」にある症状を、確認する順番に並べ直しました。

setupが失敗する（elevated）

主な原因は、UACの確認で「いいえ」を押した、会社のポリシーがローカルのユーザーやグループの作成・ファイアウォールの変更・sandbox用ユーザーのログオン権限を止めている、のどれかです。setupをやり直す、IT担当に頼む、ポリシーが許すなら一時的に unelevated を使う、のどれかで進めます。その前に、MXCが使えるかを先に確かめると遠回りが減ります。

エラー 1385 が出る

Windowsが、sandbox用のユーザーに必要なログオンの種類を許していないときに出ます。会社の端末では、グループポリシーでログオン権限が絞られていることが原因になりやすい箇所です。IT担当に権限の付与を頼み、それまでは必要なら unelevated を使います。IT担当には後述のログを渡します。

「Everyone に書き込み権限がある」という警告

一覧に出たフォルダから、Everyone（全ユーザー）の書き込み権限を外せるなら外し、Codexを再起動するか setup をやり直します。誰でも書けるフォルダがあると、sandboxで区切る意味が薄れるための警告です。

sandboxの中のコマンドがネットワークにつながらない

まず、そのチャットがそもそもネットワークなしの設定で動いていないかを見ます。既定ではネットワークはオフなので、これは故障ではありません。作業フォルダに書ける設定でネットワークも使いたいなら、config.toml で許可します。

[sandbox_workspace_write]
network_access = true

ネットワークが要る設定のはずなのにつながらない場合は、Codexを再起動し、それでも続くならログを集めます。

今まで動いていたsandboxが急に動かなくなった

作業フォルダを移した、フォルダの権限や会社のポリシーが変わった、Windowsの更新が入った、が典型的なきっかけです。Codexを再起動し、MXCの確認コマンドか elevated のsetupをやり直します。

VS Codeの拡張が固まる・反応しない

公式は、Visual Studio Build Tools（C++のワークロード）と x64 の Visual C++ 再頒布可能パッケージを入れ、VS Codeを完全に再起動するよう案内しています。

winget install --id Microsoft.VisualStudio.2022.BuildTools -e

IT担当やサポートに渡すもの

• CODEX_HOME/.sandbox/sandbox.log（sandboxのログ）
• 選んでいる方式（mxc・elevated・unelevated）、出たエラーの文面、1385 や PowerShell のエラー
• Windowsのバージョンとビルド番号

CODEX_HOME/.sandbox-secrets/ は渡しません。公式も送らないよう明記しています。名前のとおり、秘密の情報が入るフォルダです。

従来のsandboxを片付けたいとき

MXCに移ったあと、elevated のために作られたアカウントやネットワークの規則を消したいことがあります。Codex CLI 0.167.0 のヘルプを見ると、codex sandbox uninstall というコマンドがあり、「従来のWindows sandboxが作った、PC全体のアカウントとネットワークの規則を消す」と説明されています。

ヘルプには、従来のsandboxとその用意のためのサービスを使っているアプリを止めてから、管理者として実行すること、Codexのホームフォルダ（sandbox用のフォルダとその権限を含む）は残すこと、も書かれています。私たちはWindowsの端末でこのコマンドを実行してはいないので、会社の端末ではIT担当と相談のうえで使ってください。

そのほかの起動まわりのエラーは、こちらで切り分けています。

CodexCodexのエラー・トラブル対処集｜詰まりやすい点

私たちがsandboxで決めていること

私たちの手元のCodexはMacで動いており、Windowsの3方式は公式ドキュメントで確かめた範囲で書いています。そのうえで、方式を問わず変わらない判断が3つあります。

無人で動かす処理でも workspace-write から広げない

私たちは記事の画像を作る定期ジョブで、Codexを codex exec --sandbox workspace-write で呼んでいます。人が見ていない時間に動く処理なので、作業フォルダの外を書き換えられないことと、ネットワークが既定でオフであることが、そのまま安全の前提になっています。先ほどの表のとおり、作業フォルダの外に書こうとしたコマンドはsandboxが止めます。

だからこそ、「動かないからfull accessにする」はしません。公式も、full access は作業フォルダの外まで手が届き、データを失うおそれがあると注意したうえで、sandboxの境界は残し、例外はルールで個別に足すよう案内しています。止まったら、まず何が止めたのか（書き込みか、ネットワークか、読み取りか）を見て、その1点だけを許すのが順番です。

会社の端末では「先にIT担当に聞く」

私たちの支援先には、社内のサーバーとWindowsのPCで業務を回している会社もあります。こうした会社の端末は、ローカルのユーザー作成やファイアウォールの変更が会社のポリシーで止められていることがあり、公式もsetupが失敗する原因として挙げています。

利用者が自分でsetupを何度もやり直したり、unelevated に切り替えて済ませたりする前に、IT担当に「MXCが使えるビルドか」「elevated を用意してもらえるか」を聞くほうが早く、安全です。allowed_sandbox_implementations や allow_mxc のように、会社として方式を決める設定もあります。

確認コマンドを最初に1回だけ動かす

Macで codex sandbox を動かしてみて、書ける範囲とネットワークの状態は、設定ファイルを読むより1回コマンドを動かすほうが早く確かめられると分かりました。Windowsなら、MXCの確認コマンドがその役割です。導入の最初に1回動かし、MXC_OK が出るかどうかで、その後の手順がほぼ決まります。

よくある質問

Q. Windows 10でもCodexのsandboxは使えますか？

公式の対応表では、Windows 11が推奨、更新を当てた新しいWindows 10は「できる範囲での対応（best effort）」で、ConPTYのために1809以降が必要です。古いWindows 10のビルドは推奨されていません。MXCはWindows 11 24H2／25H2の対応ビルドが前提なので、Windows 10では elevated か unelevated、またはWSL2になります。

Q. 勝手にunelevatedに切り替わったのはなぜですか？

公式によると、設定で unelevated を選んでいる場合か、elevated のsetupが使えない場合に起きます。ネットワークの隔離が弱いままなので、まずMXCが使えるかを確かめ、だめなら elevated のsetupをやり直すかIT担当に頼みます。

Q. MXCにしたら開発用のサーバーがすぐ止まります

MXCでは、コマンドが終わると、そこから起動した子プロセスも止まります。サーバーを裏で立ち上げたまま残す使い方は、MXCの下ではできません。公式とリポジトリの説明のとおりの動きで、故障ではありません。

Q. 承認の確認を出さずに自動で進めたいのですが、sandboxは外す必要がありますか？

外す必要はありません。公式は、自動で進めたいときもsandboxの境界は残し、承認の設定を「確認しない（never）」にするか、ルールで例外を足すよう案内しています。sandboxを外す（full access）と、作業フォルダの外まで書き換えられるようになります。

Q. Windowsのデスクトップアプリでsandboxを効かせるには？

公式のデスクトップアプリの説明では、入力欄の下で「Ask for approval」を選んでから送ると、sandboxの保護がかかります。アプリを「管理者として実行」すると、エージェントもその権限を引き継ぐので、必要がない限り管理者では起動しないほうが安全です。

まとめ

• CodexのWindows sandboxは mxc・elevated・unelevated の3方式。公式の優先順は mxc → elevated → unelevated
• MXCは管理者の承認もアカウント追加も要らない。Windows 11 24H2（26100.9278）／25H2（26200.9278）以降と、CLI 0.162.0以降の確認コマンドで使えるかを見る
• CLIは prefer_mxc = true で「使えるならMXC」。windows.sandbox = "mxc" は固定で、使えない端末では動かない
• elevated はsetupで管理者の承認が要る。会社の端末ではIT担当が codex sandbox setup --elevated で用意できる
• unelevated はネットワークの隔離が弱く、読ませないフォルダも使えない。つなぎとして使う
• Linuxの道具で開発するならWSL2（0.115以降は bubblewrap・WSL1は非対応）
• 動かないからといってfull accessにしない。何が止めたのかを見て、その1点だけをルールで許す

sandboxは、AIに作業を任せる範囲を決める土台です。株式会社Fyveでは、こうした設定の判断も含めて、中小企業のAI導入を一緒に進めています。