Codex releases a Windows sandbox built on Microsoft Execution Containers

• Codex has a new Windows sandbox built on MXC, with faster setup, stronger network enforcement and granular file access, according to OpenAI's announcement.
• A compatible Windows 11 device is required; the eligibility wording prompted an immediate question about which machines qualify.
• MXC supports Windows, Linux and macOS through native isolation backends, as simonw noted.
• Unsloth's Windows timings differ: its launch post claims under 100 ms of overhead, while its sandbox guide lists 164 ms per OS-sandboxed call.

The documentation OpenAI links still describes dedicated sandbox accounts and firewall rules. Microsoft's MXC policy model keeps permission decisions outside the agent's control, the best part of this release. Its separate Quicksand project packages QEMU virtual machines behind a Python API; simonw says he has tried it on macOS, Windows and Linux.

OpenAI announced an MXC-backed sandbox mode for Codex with three changes:

• Faster setup.
• Stronger network enforcement.
• Granular file access controls.

Windows sandboxing has been one of Codex's top areas of user feedback, according to embirico.

OpenAI's linked Windows documentation covers native PowerShell execution in the desktop app, CLI and IDE extension. It still describes two sandbox implementations, without an MXC-specific configuration value:

• elevated: Dedicated lower-privilege sandbox users, filesystem permission boundaries, firewall rules and local policy changes. Setup requires administrator approval.
• unelevated: A restricted token derived from the current user, ACL-based filesystem boundaries and environment-level offline controls. The docs describe weaker network isolation than the elevated implementation.

Enterprise administrators can constrain the available implementations through windows.allowed_sandbox_implementations in requirements.toml, including prohibiting fallback to unelevated.

The troubleshooting page lists blocked local user creation, firewall changes and sandbox-user logon rights among the causes of elevated setup failures.

OpenAI specifies a “compatible Windows 11 device” without naming a build number, the gap raised in a launch reply.

Microsoft's OS-version support matrix gives MXC's default Windows processcontainer backend a supported floor of Windows 11 24H2, build 26100. That is the backend's support floor, not a Codex-specific compatibility matrix.

The same document includes a 23H2 column describing capabilities the code can enforce below the officially supported floor. Its presence in the table does not make 23H2 a supported MXC host.

MXC accepts versioned JSON container requests through Rust, .NET and Node SDKs. Microsoft describes five policy areas in its developer announcement:

• Containment: The isolation environment, such as a process or session container.
• Process: Command, arguments, working directory and environment.
• Filesystem: Read-write locations, read-only locations and denied paths.
• Network: Inbound and outbound connectivity, including access to services on the host's loopback interface.
• UI: Access to the desktop and related interface resources.

Fine-grained network rules have an additional dependency. MXC's schema 0.8 egress rules for IP/CIDR, port and protocol require the PSEC process-security-environment runtime contract, according to the support matrix; legacy SBOX and AppContainer fallbacks reject those requests.

Microsoft exposes four containment options in its launch backend table:

• Process container: Lightweight execution on Windows 11, macOS and Linux, using AppContainer, Seatbelt and Bubblewrap respectively.
• Session container: Windows-only execution under a distinct account and session, with separate desktop, clipboard, UI and input boundaries.
• WSL container: A Linux execution environment for Linux-first toolchains on Windows 11.
• MicroVM: Hardware-backed isolation for Linux workloads on Windows 11 and Linux, marked experimental.

For Windows process containers, the implementation matrix says 24H2 and 25H2 enforce filesystem grants and denies through host-path DACLs. Newer 25H2+ hosts can use BaseContainer when the required OS contract is enabled, with AppContainer remaining the fallback.

Unsloth says in its launch post that its Windows collaboration added MXC sandboxing with less than 100 ms of overhead. Its published latency table instead lists 164 ms per Windows High-mode call and 8 ms in Low mode.

Those figures describe Unsloth's integration. OpenAI's Codex announcement supplies no setup or execution timing measurements.

Unsloth exposes two sandbox levels and a bypass:

• Low: Software checks using strings, AST inspection and regular expressions.
• High: OS-level isolation for Python and terminal execution.
• Full Access: Disables both software and OS-level sandboxing.

Windows MXC process containers support three operating modes, described in Microsoft's policy-authoring documentation:

• Enforcement: Blocks ungranted access without producing an activity report.
• Learning: Blocks ungranted access and records it in a JSON activity report.
• Permissive: Allows and records access the policy would have denied, while retaining other applicable OS and organizational restrictions.

The MXC repository also documents wxc-exec.exe --audit policy.json for policy authoring. Its warning says this turns off all sandbox security for the workload being analyzed.

Microsoft included MXC in its broader Windows agent rollout. Its developer launch post distinguishes generally available containment from two forthcoming enterprise controls:

• Intune policy: Management of Windows 11 MXC process-container creation requests and enforced resource boundaries.
• Entra agent identity in Agent 365: Attribution separate from the employee's identity, allowing security controls to target a misbehaving agent's access without blocking the employee's access.