MoorAI and Microsoft Execution Containers (MXC)

On 9 October 2026, OpenAI said Codex on Windows has a new sandbox mode built on Microsoft Execution Containers (MXC), for “faster setup, stronger network enforcement, and granular file access controls”, on compatible Windows 11 devices. Microsoft announced MXC as generally available on 7 October. A sandbox boundary and a per-action check are two layers, and each leaves a hole without the other. This guide covers what each layer does, what MoorAI agent v1.17.1 does next to MXC, and what to ask of any stack that claims both.

What MXC contains

Microsoft describes MXC as policy-driven containment for AI agents. A developer declares the resources a workload needs, and the container enforces that boundary. The policy covers the isolation environment, how the process starts, which file system locations the workload can modify, only read or not access, inbound and outbound network connectivity, and access to the desktop. It stays outside the workload’s control, so the agent or the code it generates cannot grant itself more access. Microsoft lists OpenAI Codex and GitHub Copilot among the agents that already support MXC, and Claude Code among those that will release support.

In those agents, MXC contains the commands. OpenAI’s Codex documentation says the Windows sandbox enforces the permission profile for commands and their child processes, and recommends MXC on compatible devices. It is selected with windows.sandbox = "mxc" or preferred with prefer_mxc, and an administrator can block it with allow_mxc = false. GitHub’s documentation says Copilot CLI runs most of the commands and tools it invokes inside an operating-system sandbox, saved as sandbox.enabled in the user’s settings, and GitHub’s changelog says that local sandbox is built on MXC.

That is the right layer for what it does. A command that writes outside the paths the policy grants, or connects where the policy does not allow, is stopped by the operating system whatever the model decided. An agent sandbox bounds the damage of a bad action.

What a boundary does not judge

A boundary answers one question: can this command reach that file or that host? It does not ask whether the agent should be taking this action at all. Inside what the policy allows, four kinds of action pass:

What MoorAI checks before each action

MoorAI runs in the agent’s pre-tool hook: Claude Code’s own, and Codex CLI’s and GitHub Copilot CLI’s through adapters that translate each agent’s hook payload, run the same engine and policy, and translate the verdict back. Each call is judged on the device before the tool runs. In agent v1.17.1, for the four actions above:

• Secrets in arguments. MCP tool-call arguments are inspected for secrets and policy violations, and blocked. Local secret values, such as .env files and cloud credentials, are fingerprinted on the device as keyed one-way hashes, and an outbound command or tool call that carries one verbatim is blocked.
• The MCP approval gate. With the console’s approval gate on, the allow-list is the approved set, and a server not approved yet is denied. Tool drift blocking removes a tool whose description or schema changed since an admin approved the server, a tool added after approval, or a tool name another server owns, and refuses its calls until re-approval.
• Destructive commands. The destructive-command rule (#43) is matched on the command before it runs, and the policy sets what happens, from coaching the agent to blocking the call.
• Egress rules. egressRules say which binary may reach which host, port, HTTP method and path, each with allow, alert or block. A block denies the call. So a host the agent needs can still be limited to one tool, one method or one path, and the secret check above still applies to what is sent there.

An enrolled device enforces the policy; a device that is not enrolled coaches, and the action goes ahead. The console receives a category, a risk level and a keyed one-way hash, never the prompt, the file or the matched text.

Is the boundary actually on?

A sandbox protects only the sessions that run inside it. On a Windows device, MoorAI’s daily content-free heartbeat says, for Claude Code, Codex and Copilot, whether the commands that agent runs are inside MXC, read from that agent’s own config, and whether the device’s Windows build is new enough for MXC.

mxcCapable compares the Windows build and its update revision with MXC’s documented minimum builds. It is false on an older build and null when the build is not listed or cannot be read. The console raises Coverage: agent running without containment for a Windows agent whose containment is none, or unknown on an MXC-capable device. The finding is report-only and changes no verdict. Gemini CLI and Cursor have no documented MXC support and get no containment field; on macOS and Linux the existing sandboxOff and sandboxFullAccess flags cover the sandbox.

One rule set, two layers

The egress rules MoorAI judges on each call can also become the network part of the MXC policy, so one rule set drives both layers:

node cli/sandbox-policy.mjs --target mxc --rules policy.json

The policy goes to stdout. Only numeric hosts become MXC rules (network.egress.allow or deny, as /32 or /128), and egress.default stays deny. Hostnames, loopback, and the binary, method and path fields stay with MoorAI’s check. Every rule the target cannot express is printed to stderr with its reason; nothing is dropped silently. The container holds the addresses it can enforce at the operating-system level, and MoorAI holds the parts of the same rule that need to see the call.

Questions to ask of any sandbox + guardrail stack

• What is inside the boundary? The commands, the MCP servers, the agent process, or all three? Ask for each agent you run, from the vendor’s own documentation.
• How do you know it is on, on each device? A config file, a command-line flag, a managed setting and the Windows build can each change it. Ask what is read and what is assumed.
• What judges the action inside the boundary? A secret in an argument, an unapproved MCP server, a destructive command in the workspace, an upload to an allowed host.
• Does one rule set drive both layers? And when one layer cannot express a rule, is that reported, or dropped or widened without a word?
• What happens when the check cannot decide? Who chooses fail open or fail closed, and can the agent change it?
• What has run on real devices, and what only in tests? Ask for each layer, each agent and each platform.
• What leaves the device? Ask whether the check sends content, or only a verdict and metadata.

Limits

Sources

• MoorAI. MoorAI on GitHub, agent v1.17.1: README sections “Containment on Windows (MXC)”, “Sandbox egress policies from the same egress rules”, “What it does” (Agency Enforcement, MCP hardening, egress rules, local secret-egress detection, on-device and content-free) and “Other agents”; testing status from docs/CAPABILITY_SPEC.md.
• OpenAI. OpenAI Developers on X, 9 October 2026, the Codex sandbox mode built on MXC; Codex documentation, Windows sandbox.
• Microsoft. Microsoft Execution Containers: policy-driven containment for AI agents, Windows Developer Blog, 7 October 2026; microsoft/mxc on GitHub.
• GitHub. Using local sandboxing, GitHub Docs; Cloud and local sandboxes for GitHub Copilot now in public preview, GitHub Changelog, 2 June 2026.

See also: MoorAI for AI coding agents, Capabilities and MCP security.