OpenAIは2026年10月9日、公式XアカウントのOpenAI Developersで、Windows上のCodex向けに、Microsoft Execution Containers（MXC）を使う新しいサンドボックスモードを開発したと発表した。セットアップの高速化、ネットワーク制限の強化、きめ細かなファイルアクセス制御を特徴として挙げている。利用には、MXCに対応するWindows 11端末が必要となる。
An update for builders using Codex on Windows:
We’ve built a new sandbox mode using @Microsoft’s Execution Containers (MXC) for faster setup, stronger network enforcement, and granular file access controls.
Requires a compatible Windows 11 device.
— OpenAI Developers (@OpenAIDevs) October 9, 2026
MXCで変わるWindowsサンドボックス
MXCは、エージェントや生成されたコードがアクセスできるファイル、ネットワークなどの範囲を制限する実行基盤。Microsoftの解説によると、開発者や組織が定めたアクセス制限を実行時に適用し、エージェントが自ら権限を広げられない仕組みになっている。同社は2026年10月7日、Windows 11向けの一般提供を発表した。その発表記事では、Codexなどを対応済みのエージェントとして紹介していた（MXCの概要は、一般提供を紹介した記事を参照のこと）。
Codexは、このMXCをサンドボックスの新しい実行方式として採用した。実行するコマンドとその子プロセスが読み書きできるファイルや、ネットワーク接続の可否を制御する。OpenAIはWindowsサンドボックスのガイドで、対応端末でのMXCの利用を推奨している。
MXCでは、サンドボックスのセットアップに必要な作業が減る。これまでWindows版Codexで使われてきたelevatedモードでは、権限を絞った専用のWindowsアカウント（CodexSandboxOffline、CodexSandboxOnline）やローカルのファイアウォールルールなどで実行範囲を制限する。一方、MXC方式はWindowsのプロセス隔離機能を使うため、こうした専用アカウントやルールを作成する必要がなくなる[1]。
[1] セットアップ時の管理者承認は、elevatedモードでは必要となるが、MXC方式では不要。
端末のMXC対応を確認する
必要なMXC機能はWindows 11端末へ順次展開されており、端末ごとの対応確認が必要となる。公式ガイドでは、Codex CLI 0.162.0以降で、MXCを使ってコマンドを実行できるかを確かめる手順を紹介している。PowerShellでプロジェクトのディレクトリに移動し、次を実行する。
codex -c windows.sandbox=mxc sandbox –include-managed-config –permission-profile :workspace — cmd.exe /d /c echo MXC_OK
$LASTEXITCODE
MXC_OKが表示され、続く$LASTEXITCODEの結果が0なら、MXCでのコマンド実行は成功している[2]。
[2] このコマンドは、今回の実行だけMXCを使うよう指定する。config.tomlは書き換えない。組織の管理ポリシーでMXCの利用が禁止されている場合は、エラーになる。
MXCを優先して使う
デスクトップアプリでは、MXC対応端末で個人向けアカウントを使う場合、MXCが自動的に優先される。
設定ファイルでMXCを優先するよう明示する場合は、config.tomlに次のように記述する。この設定では、端末がMXCに対応し、管理ポリシーでも利用が認められていればMXCを使い、利用できなければelevatedを使う[3]。
[windows]
sandbox = “elevated”
[features]
prefer_mxc = true
なお、MXCでは、Codexが実行したコマンドが終了すると、そのコマンドから起動した子プロセスも停止する。たとえば、コマンドから開発サーバーをバックグラウンドで起動しても、そのコマンドが終了するとサーバーも停止する。
[3] 管理者はrequirements.tomlに次の設定を指定することで、MXCの自動選択と明示指定の両方を禁止できる。詳細は公式ガイドを参照のこと。
[windows]
allow_mxc = false
コラム：MXCの実行方式とアクセス範囲の設定
windows.sandboxは、elevatedやmxcなど、シェルコマンドを実行するサンドボックスの方式を選ぶ設定。これだけで、書き込み先がプロジェクト内に限定されるわけではない。実行方式とアクセス範囲は、分けて設定する。
MXCを必須にする場合
本編の設定では、MXCを利用できなければelevatedを使う。Codexによるシェルコマンドの実行をMXC内に限定したい場合は、次のように指定する（config.tomlの先頭にwindows.sandbox = “mxc”と1行で書くこともできる）。
[windows]
sandbox = “mxc”
端末がMXCに対応していない場合や、管理ポリシーで利用が禁止されている場合は、Codexはシェルコマンドを実行せずにエラーを返す。
アクセス範囲を指定する
アクセス範囲は、次の「方法1：sandbox_mode」か「方法2：権限プロファイル（permission profile）」のどちらかで指定する。どちらの方法も、MXCを優先する場合にも、必須にする場合にも使える。
以下の例では、方法1のsandbox_modeと、方法2のdefault_permissionsをトップレベルに記述する。これらの項目は、config.tomlの最初のセクション（[windows]など）より前に置く。
方法1：sandbox_modeで書き込み先を指定する
sandbox_mode = “workspace-write”でプロジェクト内への書き込みを許可し、writable_rootsで書き込み先を追加できる。この例では、C:/shared/outputにも書き込める。
sandbox_mode = “workspace-write”
[sandbox_workspace_write]
writable_roots = [“C:/shared/output”]
なお、上のコード例には明記していないが、workspace-writeでは一時フォルダーなどへの書き込みも許可される。また、プロジェクト内の.codexなどの設定ディレクトリは、書き込みから保護される。
これらのアクセス範囲はMXCでの実行にも反映される。
方法2：権限プロファイルでパスごとに指定する
権限プロファイルでは、パスごとにread（読み取りのみ）、write（読み書き）、deny（読み書き禁止）を指定できる。次の例では、プロジェクトへの書き込みを許可する組み込みプロファイル:workspaceを基に、project-editというプロファイルを定義し、default_permissionsで選択する。C:/shared/outputは読み書き可能、C:/referenceは読み取りのみ、C:/Secretsは読み書き禁止にする。
default_permissions = “project-edit”
[permissions.project-edit]
extends = “:workspace”
[permissions.project-edit.filesystem]
“C:/shared/output” = “write”
“C:/reference” = “read”
“C:/Secrets” = “deny”
MXCを使う場合、CodexはMXCのアクセス拒否機能でC:/Secretsへの読み書きを禁止する。端末でMXCのアクセス拒否機能を利用できなければ、コマンドの起動前にエラーを返す。
権限プロファイルの詳しい書き方は、CodexのPermission profilesを紹介した記事を参照のこと。
実行時の承認と通信の条件
MXCを使う場合も、許可範囲を超える操作の承認は、Codexの権限・承認設定に従う。たとえば、許可された書き込み先以外にファイルを保存するため、Codexが追加の権限を求めることがある。承認判断の自動化については、後のコラム「承認判断を任せるオートレビューの使い方」で紹介する。
ネットワーク通信をプロキシで管理する構成では、同じ端末内での通信を許可する必要がある。管理ポリシーなどでこの通信が許可されていない場合は、MXCを利用できない[4]。
[4] ネットワークをプロキシで管理する場合、MXCではallow_local_bindingのデフォルトがtrueになり、同じ端末上のサービスとのループバック通信を許可する。管理ポリシーなどを適用した結果、この値がfalseになる場合は、MXCを利用できない。
この構成では、ループバック以外への直接通信を遮断し、プロキシ経由の通信にはドメインルールを引き続き適用する。ただし、プロキシによるプライベートネットワーク内の宛先に対する追加チェックは外れる。なお、allow_local_bindingのデフォルトが変わっても、無効にしていたネットワークアクセスまで有効になることはない。詳細は実装上の制約を参照のこと。
コラム：Windows版アプリの「setup refresh had errors」からの復旧例
今週、手元のWindows版Codexアプリでは、コマンド実行時にhelper_unknown_error: setup refresh had errorsが表示され、ファイル読み込みやNode REPLの起動も失敗した。アプリを26.1002.52244から26.1007.21434へ更新した後は、コマンド実行とテストが成功した。
Issue #52179にも同じエラーの報告がある。関連Issue #52488によると、ファイルのアクセス権を定めるACLの更新時に、別のプロセスが使用中の実行ファイルを開こうとして、Windowsの共有違反（os error 32）が発生する。このためサンドボックスのセットアップに失敗し、コマンドを実行できなくなる。手元のログにも、同様の共有違反が記録されていた。
この問題に関連する修正PR #51822は10月7日にマージされた。ACLを更新するためにファイルを開く際、要求するアクセス権を必要な範囲に絞り、共有違反を避けるよう変更している[5]。
[5] この修正がアプリ26.1007.21434に含まれるかは未確認。
コラム：承認判断を任せるオートレビューの使い方
OpenAIのThibault Sottiaux氏は2026年10月6日、ChatGPTアカウントでサインインする全ユーザー向けに、オートレビューを無料化したと案内している。この機能による承認判断は、プランの利用枠も消費しないという。
コードの編集や調査など、通常の作業には引き続きプランの利用制限が適用される。
Day 2.1/
We have made Auto-review free for all users signed in through a ChatGPT account. You can enable it in settings > permissions > auto-review. Auto-review improves upon the default sandbox setting that requires you to approve everything, which is prone to decision fatigue unless you spend a lot of time configuring specific rules.
It allows you to run long tasks while having a second agent review all actions taken by the primary agent. Its only goal is to prevent high-risk actions from being taken and to protect against unwanted actions that are not aligned with the original user intent. This Auto-review feature is now free and does not draw usage from your plan.
— Tibo (@thsottiaux) October 6, 2026
Codexの「Auto-review」（オートレビュー）は、承認が必要な操作について、別のAIエージェントが実行してよいか判断する機能。操作のリスクや、ユーザーの依頼に沿っているかを確認する。
公式ドキュメントによると、オートレビューが扱うのは、通常ならユーザーに確認する承認要求。たとえば、許可された書き込み先以外のファイルを編集する場合や、承認が必要なApps・MCPのツールを呼び出す場合が含まれる。
承認されれば作業を進めるエージェントが操作を実行し、拒否された場合は、より安全な方法を探すか、作業を止めてユーザーに確認する。
オートレビューを有効にしても、サンドボックスの許可範囲自体は変わらない。許可範囲内の通常の操作は、レビュー用エージェントによる確認なしで実行される。また、オートレビューにも誤判断の可能性はある。
なお、画面上でアプリを操作するComputer Useでは、アプリ自体へのアクセス承認はオートレビューの対象外で、ユーザーが判断する。Computer Useの権限と承認を参照のこと。
有効化するには
デスクトップアプリでは、チャットの入力欄下にある権限メニューで「Approve for me」を選ぶと、そのチャットの承認判断をオートレビューに任せられる。
設定ファイルを使う場合は、ユーザー設定の~/.codex/config.tomlに次の2項目を記述する。どちらもトップレベルの設定なので、[windows]などのセクションより前に置く。同じ項目がすでにあれば、その値を変更する。
approval_policy = “on-request”
approvals_reviewer = “auto_review”
approval_policy = “on-request”では、Codexが必要に応じて追加の権限を求める。approvals_reviewer = “auto_review”を組み合わせると、対象の承認要求について、ユーザーに代わってレビュー用エージェントが許可・拒否を判断する。approval_policy = “never”の場合は承認要求を出さないため、オートレビューは働かない。
承認の判断基準をカスタマイズするには
オートレビューには、秘密情報の漏えいや破壊的な操作などを防ぐための判断基準が組み込まれている。有効化するだけなら、この基準が使われ、独自の指示文を書く必要はない。
カスタマイズには、既存のポリシーに指示を追加するextra_policyと、ポリシーを置き換えるpolicyがある。どちらも、組織が対応する管理設定を指定している場合は、組織の設定が優先される[6]。
[6] 組織の管理設定では、guardian_extra_policyがユーザーのextra_policyより、guardian_policy_configがユーザーのpolicyより優先される。詳細は設定リファレンスを参照のこと。
既存のポリシーに指示を追加する
extra_policyには、承認判断に追加したいルールだけを書く。基本のポリシーはそのまま使われるため、全文をコピーする必要はない。
次の例をconfig.tomlに記述し、山括弧内を実際の指示文に置き換える。
[auto_review]
extra_policy = “””
<承認判断に追加したいルールをここに記載>
“””
ポリシーを置き換える
policyに指定した内容は、基本のポリシーを置き換える。標準のポリシーはGitHubで公開されているが、実際に適用される内容はモデルや組織の設定によって異なる場合がある。
公式ドキュメントは、適用中のポリシー全文を確認し、既存のルールを保って調整するよう案内している。全文を確認できない場合は上書きしない。
コラム：次のメッセージを予測する「Composer predictions」
OpenAIは2026年10月9日、Codexの「Composer predictions」のベータ提供を案内した。現在の会話の内容やユーザーの話しかけ方を基に、次に送るメッセージ全体を予測し、入力欄に予測候補を表示する[7]。ベータ版では、入力途中の文章を逐次補完することはできない。
Now in beta: composer predictions in Codex for Pro users.
Codex can now suggest your next message based on your conversation and how you talk to it.
One of the most loved new features we’ve ever tested internally. https://t.co/0u8d2a3feS
— OpenAI Developers (@OpenAIDevs) October 9, 2026
公式ヘルプによると、対象は18歳以上の個人向けChatGPT Proユーザー。CodexデスクトップアプリのローカルおよびSSHの会話で、GPT-6 AstraまたはGPT-6.1 Solを使う場合に利用できる。
Codexの応答後に予測候補が表示されたら、Tabキーで取り込み、内容を確認・編集して送信する。Tabキーを押しただけでは送信されない。予測候補は毎回表示されるとは限らず、待たずに自分で入力することもできる。
対象ユーザーでは標準で有効になっている。不要な場合は、設定の「コンポーザー」（Composer）にある「予測候補を表示」（Show predictions）をオフにできる。
ベータ期間中、予測候補の生成に追加料金はかからず、Codexの利用枠やクレジットも消費しない。予測候補を採用してメッセージを送信した後の処理には、通常の利用制限と料金が適用される。
[7] 予測候補の生成には現在の会話を使い、メモリーや接続アプリの情報を独自に取得することはない。ただし、それらの情報がすでに会話に含まれていれば、予測候補に反映される場合がある。詳細は公式ヘルプを参照のこと。