OpenAI Codex MXC Sandbox on Windows 11: Requirements, Test Command and Known Issues

The word "compatible" matters here. A current Windows 11 build is required, but on its own it does not prove the feature will work on your machine. Below are the requirements, a test command that leaves your settings alone, and the problems early users have already reported.

What OpenAI changed​

OpenAI's developer account announced the feature on October 9, 2026. It said the MXC mode brings faster setup, stronger network enforcement and more granular control over file access, and it requires a compatible Windows 11 device. Codex on Windows is available in three places: the ChatGPT desktop app, the Codex CLI and the IDE extension.

When Codex runs a command, MXC applies the active file and network permissions to that command and to any child processes it starts. MXC changes how Windows enforces those limits. It does not loosen them, and a sandboxed command still cannot reach everything on your PC.

Section summary: Codex now has a native Windows isolation backend that avoids the account and firewall changes the older elevated sandbox needed.

MXC: Microsoft's platform behind the feature​

Microsoft first shipped MXC as a Windows 11 feature in the August 27, 2026 preview cumulative update, KB5120998. Microsoft's release notes call Process Isolation for MXC a fast, lightweight boundary for responsive workloads such as coding agents and model-generated code. It uses Windows containment capabilities to limit access to files, networking, the user interface and other operating-system resources according to a policy.

General availability followed on October 7. Microsoft's Windows Experience Blog said that Microsoft Execution Containers (MXC), becomes generally available on Windows 11, enabling organizations to define which files and networks agents can access, with those policies enforced at runtime.

A summary on the AI TL;DR tools directory adds some technical detail. MXC maps the requested controls onto a backend for each operating system: AppContainer-based process containers on Windows 11, Seatbelt on macOS and Bubblewrap on Linux. The same summary says policies can run in three modes. Enforcement blocks anything not granted; learning mode also blocks it but writes a JSON activity report that helps you author a policy; permissive mode allows and records ungranted operations while you draft one.

OpenAI has been involved since before the release. When Microsoft introduced MXC in June, OpenAI's David Wiesen said the companies aimed to help developers move from intent to reliable execution faster, while maintaining the security and control enterprises need.

Section summary: Microsoft built the containment layer and OpenAI built Codex's integration on top of it. MXC reached general availability two days before the Codex announcement.

Does your PC qualify?​

These are the minimum builds listed for MXC:

Three practical points apply before you start:

• KB5120998 was a preview update. Microsoft's support page says it arrived through gradual and normal rollout phases, and that during gradual rollout "availability varies by device." For people who skip optional updates, the MXC code would have arrived through a later cumulative update instead.
• Build number alone isn't enough. Microsoft is still rolling the capability out across Windows 11 devices, so a matching build does not guarantee MXC works on your PC. Use the test below.
• 24H2 Home and Pro are nearly out of support. The same Microsoft page says those editions reach end of updates on October 13, 2026, while Enterprise and Education editions are supported until October 12, 2027. If you are on 24H2 Home or Pro, moving to 25H2 is worth doing for MXC and for security fixes generally.

What about Windows 10? Codex runs on recent, fully updated Windows 10 devices on a best-effort basis, but that does not mean MXC is available there. The MXC capability and its support test are documented only for compatible Windows 11 devices.

How to test MXC without changing your setup​

You need Codex CLI 0.162.0 or later. Open PowerShell in your project directory and run these two lines in order:

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

If MXC works, the output is MXC_OK followed by an exit code of 0. The test forces MXC for this single command and leaves your saved sandbox selection untouched. It checks that a command can start with workspace permissions and any managed requirements. It is not a performance benchmark or a security audit.

If the test fails, check these first:

1. Confirm your build with winver against the table above.
2. Make sure your CLI is at least 0.162.0.
3. Find out whether your organization blocks MXC through managed policy (see the enterprise section).
4. Check for locked BitLocker drives (see the known issue below).

Who gets MXC automatically, and how to turn it on​

Consumer accounts in the ChatGPT desktop app prefer MXC automatically when the device supports it.

Standalone CLI users and enterprise deployments have to opt in. In config.toml, add a [features] section with prefer_mxc = true:

[features]
prefer_mxc = true

With that setting, Codex then selects MXC for Windows commands when the device and policy support it, with the legacy flow available otherwise.

There is an important difference between preferring MXC and requiring it. Setting windows.sandbox = "mxc" explicitly makes Codex fail if Windows lacks the capability or a policy blocks it. The preference setting falls back to the legacy flow instead. For most people, the preference is the safer choice.

For administrators: blocking MXC​

Organizations can turn it off. In managed requirements.toml, set allow_mxc = false under [windows]. This blocks automatic selection and an explicit windows.sandbox = "mxc" setting. Existing legacy sandbox requirements continue to apply.

The bigger management question is what controls Microsoft itself provides. Microsoft has described upcoming Intune policies for MXC process containers, Microsoft Entra identification of agent activity, and Agent 365 controls for managing and monitoring local agents. None of those has shipped yet. Beri.net's analysis puts the gap bluntly: the agent vendor writes the policy until Intune ships. Until those controls arrive, an admin can use Codex's requirements.toml to allow or block MXC, but cannot yet manage MXC centrally through Microsoft's tools. Testing it on a pilot group before rolling it out to every machine is the cautious approach.

MXC compared with the legacy modes​

Codex lists three Windows sandbox implementations:

Both legacy modes use a private desktop by default for extra UI isolation. They remain available as fallbacks.

Some perspective helps here. MXC's process container is the lightweight end of Microsoft's options. Beri.net notes that the GA process container runs the agent in the user's own session with policy restrictions, and that it suits lower-risk tasks better than a VM-grade boundary does. It is a real step up from the unelevated mode's weaker network controls, but it is not a disposable virtual machine.

What can break​

• Background dev servers. When the foreground command exits, any child processes still running are stopped. If your workflow starts npm run dev and expects it to keep running, test it before switching.
• Loopback traffic. MXC allows connections to and from services on the host's loopback interface. With managed networking, allow_local_binding = true must be in effect, and proxy domain rules still apply to proxied traffic.
• Locked BitLocker drives. A bug report on the Codex GitHub tracker, opened October 4, describes MXC failing before a command starts because an unrelated drive was locked by BitLocker. The reported error is: "MXC launcher: enumerate MXC volume E:\: This drive is locked by BitLocker Drive Encryption." Other users posted matching failures, and the issue was still open as of October 9. If you keep a locked external or secondary encrypted volume, unlocking it before running the test is a reasonable first step. Treat that as a workaround inferred from the report, not an official fix.

Cleaning up the old sandbox​

codex sandbox uninstall removes the machine-wide accounts and network rules that the legacy sandbox created. It needs administrator rights, and it leaves Codex home, sandbox directories and filesystem permissions in place. Codex still uses the legacy modes as fallbacks when MXC is unavailable, so don't run this on machines that may need them.

The bigger picture​

Codex isn't the only agent using MXC. Microsoft named GitHub Copilot, OpenClaw, Replit, LM Studio and Unsloth AI as already supported. Gadget Pilipinas's coverage of the announcement also includes OpenShell from NVIDIA, and lists Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast and Simular as bringing support.

This is part of a broader industry shift. Coding agents run real shell commands on real machines, and the people who own those machines want the operating system, not the agent, to enforce the limits. Microsoft's design puts the policy outside the agent's control, so code running inside the boundary cannot grant itself more access. On macOS and Linux, Codex already relied on OS-native sandboxing. With MXC, Windows now has a native equivalent without the workarounds the legacy modes needed.

Bottom line: If you're on Windows 11 25H2 or 24H2 with a recent cumulative update, run the two-line test. CLI users who pass it should add prefer_mxc = true rather than forcing MXC. Admins should decide whether to allow MXC in requirements.toml, and should not expect Intune, Entra or Agent 365 controls for it until Microsoft ships them.