GitHub's Microsoft eXecution Container sandboxes Copilot CLI, the Copilot app, and VS Code Agent Host. It limits blast radius, not bad code.
GitHub made local sandboxing for Copilot generally available on October 7, 2026, across Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host. The feature runs on a piece of infrastructure GitHub calls the Microsoft eXecution Container, or MXC, which takes one shared sandbox policy and maps it onto native operating system controls on Windows, macOS, and Linux. GitHub describes MXC as a cross-platform layer over those native controls rather than a separate container or virtual machine: it confines what an already-running process can read, write, and reach on the network, without walling the agent off inside its own isolated environment.
Sources: GitHub Changelog, GitHub Docs: About cloud and local sandboxes
That matters because all three surfaces can already run shell commands, edit files, and call tools on a developer's behalf. Before this, a Copilot CLI session or a VS Code Agent Host run carried the same reach as the account it ran under: whatever that account could read, write, or reach on the network, the agent could too. MXC puts an operating-system-enforced boundary around that process instead of relying on the agent to stay inside one voluntarily, and GitHub includes it with Copilot at no additional cost.
Sources: GitHub Changelog
GitHub joins a pattern already underway
GitHub is not the first vendor to decide that an agent running real shell commands needs an operating-system boundary rather than a polite instruction to stay inside one. Claude Code already ships a sandboxed Bash tool that uses Apple's Seatbelt framework on macOS and bubblewrap on Linux and WSL2 to confine shell commands to an approved set of files and network domains, enforced by the OS rather than by the model choosing to behave. OpenAI's Codex CLI ships three sandbox modes, read-only, workspace-write, and a fully unrestricted danger-full-access, paired with an approval policy that decides when the agent has to stop and ask before crossing whichever boundary is active. MXC is GitHub's entry into that same category: a shared policy enforced natively on Windows, macOS, and Linux, across every surface Copilot runs agentic sessions through.
Sources: Claude Code Docs: Sandboxing, OpenAI Codex Docs: Sandboxing
What the sandbox actually restricts
GitHub is specific about what MXC actually restricts, not vague about security in the abstract. Once a developer turns sandboxing on, it puts four categories of access under policy control.
- Files: limits which files and directories agent-run commands can read or modify, instead of granting the same filesystem access the developer account has.
- Network: controls access to the internet and to local networks, so a sandboxed process cannot reach an arbitrary host by default.
- Credentials: restricts access to Git credentials and GitHub CLI credentials, narrowing what a compromised or misdirected session could use once it is running.
- MCP and language servers: applies the same sandboxing policy to local MCP servers and language servers, where supported, rather than leaving those processes outside the boundary.
The MCP and language-server line is easy to skip past, but it is the detail that keeps this from being a half-measure. An agent session rarely just runs Bash: it typically also starts a language server for type information and one or more MCP servers for tools, search, or data access, and either of those child processes could reach outside a sandbox that only covers the top-level shell command. Extending the same policy to them closes exactly that gap, which is also where a narrowly scoped sandbox tends to quietly fail in practice.
The network restriction is doing the most load-bearing work of the four. File and credential limits bound what an agent can damage or take on the machine it is already running on, but network access is what turns a local mistake into a remote one: it is the difference between an agent reading a file it should not have and that same agent sending the contents of that file somewhere outside the organization's control. A sandbox that locks down files and credentials but leaves outbound network access open still leaves the one path that matters most for an actual data-exfiltration scenario unguarded, which is presumably why GitHub lists internet and local-network access as its own explicit restriction category rather than folding it into the general file policy.
Off by default for individuals, mandatory where an enterprise says so
For an individual developer, sandboxing ships off: GitHub's documentation confirms it, and until a developer enables it, a shell command runs with the same access as their own user account. Enabling it in Copilot CLI makes it stick: the setting persists across future sessions until the developer runs `/sandbox disable`, rather than resetting silently the next time the tool starts. The Copilot app adds its own layer underneath that: project settings there set the default sandbox state for new local sessions in that project, so a team can opt a whole project in without relying on every contributor to flip the same switch individually.
Sources: GitHub Docs: About cloud and local sandboxes
Organizations get a stronger lever than a project default. Enterprise-managed settings can require sandboxing for every developer and lock the policy so that ordinary settings and startup options cannot turn it back off, which closes the gap between a feature that exists and a feature an organization can actually count on being used. GitHub's documentation extends that even to machines the sandbox was not built to fully support: device-managed settings can require sandboxing even on an unsupported host, rather than silently falling back to unsandboxed execution the moment a developer is on a platform MXC does not cover cleanly.
Sources: GitHub Docs: About cloud and local sandboxes
This GA announcement also caps a rollout that moved in stages rather than shipping all at once. GitHub had already put local and cloud sandboxes for Copilot into public preview earlier in 2026, and the October 7 changelog is what converts local sandboxing specifically, across CLI, the app, and VS Code's Agent Host, from preview into a supported option every Copilot customer can turn on individually or require organization-wide.
Sources: GitHub Changelog: public preview
What this actually changes for a team running Copilot today:
- An individual developer gets nothing automatically. Sandboxing has to be turned on in Copilot CLI, the Copilot app, or VS Code before it does anything, so a team that assumes GA means protected is wrong until someone flips the switch.
- A team lead can set the default at the project level in the Copilot app, which is the lower-friction option for getting a project sandboxed without chasing every contributor individually.
- A security or platform team gets the strongest option: an enterprise-managed setting that requires sandboxing and blocks developers from loosening it, including on hosts the sandbox does not fully support.
- None of the three options above change what happens after a change is written. They change what an agent could reach while writing it.
A sandbox decides what a running agent is allowed to touch. It has no opinion on whether the diff that agent just wrote is correct, or safe to merge.
Containment is not review
MXC is a real, concrete improvement, and it is worth being precise about what kind of improvement it is. It shrinks the blast radius of a single running session: a compromised or simply misdirected Copilot agent can no longer wander outside an approved set of files, reach an arbitrary network destination, or pull a Git or GitHub CLI credential it was never supposed to touch, assuming the policy is configured to stop that. None of that tells you anything about the quality of the code the agent produced. A fully sandboxed agent, running inside MXC with every restriction GitHub offers turned on, can still write a change with a logic error, an injected vulnerability, or a broken authorization check, and that change can still pass through to a pull request and get merged if nothing downstream is checking it. Runtime vs code-time guardrails draws this exact line in more general terms: controls that bound what a running process can reach and controls that inspect whether a finished diff is safe to ship are two different layers, built to catch two different failures, and neither substitutes for the other. MXC is a strong new entry in the first layer. It was never going to be an entry in the second.
Sources: GitHub Changelog
Put another way: sandboxing answers whether a process can reach something, and review answers whether what it produced is actually correct and safe to ship. A team that enables MXC and stops there has solved the first question and left the second one exactly as open as it was before. A team that runs strict diff review but lets every agent session run unsandboxed has the opposite gap, a reviewed change sitting downstream of a process that could have exfiltrated a credential or reached an unintended host on the way to producing it. The table below lines the two layers up side by side, using MXC as the containment example and an independent diff review as the review example.
| Dimension | Sandboxing (MXC) | Independent Review |
|---|---|---|
| What it acts on | A running process, while the agent works | A finished diff, before it merges |
| What it stops | Reading or writing unapproved files, reaching unintended network hosts, leaking Git or GitHub CLI credentials | Logic errors, injected vulnerabilities, broken authorization checks, scope creep against the spec |
| Its blind spot | Whether the code the agent wrote is correct, even inside the boundary | Anything a process does with real credentials or network access once it is already running |
| Who or what sets the bar | A sandbox policy, individually enabled or enterprise-required | A spec, a reviewer, or an adversarial pass checking the diff against it |
| Can a bad outcome still happen | Yes: a sandboxed agent can still write and merge a vulnerable change | Yes: a reviewed change can still run inside a process with too much reach |
Where TLM Forge sits
TLM Forge sits in the review layer of that table, not the containment layer, and that boundary is worth stating without blurring it. It runs a spec audit before an agent generates any code, an independent review pass on every diff once code exists, and an adversarial red-team security pass on top of that, then holds the merge behind a convergence gate until every flagged issue hits zero rather than logged and deferred. You can read the specifics of how it works. None of that reaches into the process an agent runs to get there: TLM Forge does not sandbox a shell, filter network egress, or scope a credential while an agent session is executing. A team adopting MXC gets a materially smaller blast radius for what a Copilot session can touch while it runs. A team adopting TLM Forge gets an enforced check on whether what that session produced is actually safe to ship. Running both closes more of the pipeline than either one does alone, because each is built to catch exactly what the other cannot see, and neither one is a substitute for turning the other on.
Frequently asked questions
01What is the Microsoft eXecution Container (MXC)?
MXC is the sandboxing technology behind GitHub Copilot local sandboxing. It takes one shared sandbox policy and maps it onto native operating system controls on Windows, macOS, and Linux, so Copilot CLI, the Copilot app, and VS Code Agent Host sessions all get the same enforced boundaries.
02Which GitHub Copilot surfaces does local sandboxing cover?
Three: Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host. GitHub's October 7, 2026 changelog lists all three as generally available under the same MXC-based sandbox policy.
03Is Copilot local sandboxing turned on by default?
No. GitHub's documentation says it is off by default for individual developers, who must enable it themselves, after which it persists across sessions. Organizations can override that default with enterprise-managed settings that require sandboxing and that developers cannot loosen, even on a host the sandbox does not fully support.
04What does Copilot local sandboxing actually restrict?
It limits which files and directories agent-run commands can read or modify, controls access to the internet and local networks, restricts Git and GitHub CLI credential access, and applies the same policy to local MCP and language servers where supported.
05Does sandboxing remove the need for code review on Copilot-generated changes?
No. Sandboxing limits what a running agent process can reach while it works; it says nothing about whether the code it produces is correct. A sandboxed agent can still write and merge a vulnerable or broken change, which only review can catch.