GitHub Copilot Local Sandboxing Is Now Generally Available
GitHub says local sandboxing for Copilot is generally available, using Microsoft's open-source MXC project to restrict what agent-run commands can touch on your machine.
GitHub says local sandboxing for GitHub Copilot is now generally available, GitHub announced in a changelog post on October 7, 2026. The feature gives commands and tools that Copilot starts on a developer's own machine a restricted execution boundary — limiting what they can read, write, reach over the network, or authenticate as — based on policy the developer or their organization sets. It ships at no extra cost on top of a standard Copilot seat and is powered by Microsoft eXecution Container (MXC), an open-source sandboxing SDK Microsoft maintains separately on GitHub.
The short version:
- Local sandboxing is GA as of October 7, 2026, for GitHub Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host.
- It is powered by MXC, Microsoft's open-source execution-container project, which maps one sandbox policy onto native isolation backends on Windows, macOS, and Linux.
- It restricts file access, network access, and Git/GitHub CLI credentials for agent-run commands — and, where supported, for local MCP servers and language servers too.
- It works the same way regardless of which AI model is powering Copilot, since the sandbox constrains tool execution, not the model.
- Local sandboxing is off by default for individual developers; enterprises can turn it on and lock it on org-wide.
- It's included in Copilot at no additional cost.
What GitHub actually announced
The October 7 changelog entry marks local sandboxing's move from preview to general availability. In GitHub's own description, local sandboxing gives "Copilot-initiated tools and commands a secure execution boundary for agentic workflows" that run on the developer's own hardware rather than in the cloud. Previously, when Copilot's agent mode ran a shell command, searched the filesystem, or called a local tool, that process inherited the same access as the signed-in user account — full read/write to the filesystem, full network access, and access to whatever credentials were sitting in the environment. Local sandboxing interposes a policy layer in front of that.
Crucially, GitHub frames this as independent of model choice: the restriction applies to how a tool executes, not to which large language model is reasoning about what to do next. Swapping models inside Copilot doesn't change what a sandboxed command is allowed to touch.
What MXC actually is
The engine behind the feature is Microsoft eXecution Container (MXC), described in its own repository as a sandboxed code-execution system for running untrusted code — model output, plugins, tools — on Windows, Linux, and macOS. Rather than being a single sandbox technology, MXC is an SDK (available as `mxc-sdk` on crates.io, `Microsoft.Mxc.Sdk` on NuGet, and `@microsoft/mxc-sdk` on npm) that an application embeds in-process. The host app describes a container type, a set of containment rules, and a workload command as versioned JSON; MXC validates that request, picks a backend, and launches the workload inside it.
The backend varies by platform: on Linux the default is bubblewrap (with lxc, micro-VM, and Hyperlight options available); on macOS it uses seatbelt; on Windows the default is a native processcontainer, with WSL-based, isolation-session, and experimental micro-VM/Hyperlight backends also listed. MXC's README describes three policy surfaces it exposes to the host app: filesystem (read-only, read-write, and denied paths), network (proxying, outbound control, and host filtering, which the sample configuration defaults to deny), and UI access (clipboard, display, GUI). The project is MIT-licensed and ships diagnostic flags — including an --audit mode that records what a workload touches, which the README explicitly warns turns off all sandbox enforcement and should never be pointed at untrusted code.
In short: MXC is the plumbing that lets one Copilot sandbox policy mean the same thing whether a developer is on a MacBook, a Linux workstation, or Windows 11, instead of GitHub having to hand-write three separate enforcement layers.
What local sandboxing actually restricts
GitHub's documentation on cloud and local sandboxes spells out the policy knobs in more detail than the changelog post does. The table below summarizes what's controllable, and where.
| Restriction area | Copilot CLI | GitHub Copilot app | VS Code (Agent Host) |
|---|---|---|---|
| Filesystem | Read-only, read/write, or denied access to specific paths | Additional read-only/read-write or denied paths, set in project settings | Listed by GitHub as a supported surface for the same file-access boundary |
| Network | Outbound internet, local network, and per-host allow/deny rules (availability varies by OS) | Allow or block outbound internet and local-network access | Listed by GitHub as a supported surface; granular controls not detailed in the changelog |
| Credentials | Git and GitHub CLI (gh) auth; sandboxed tools see placeholders while a local proxy supplies real credentials only to approved HTTPS destinations | Toggle for whether Git/gh credentials are available in the sandbox | Listed by GitHub as a supported surface |
| Local MCP & language servers | Sandboxed by default, where supported; remote MCP servers are never sandboxed | Not separately itemized in the docs | "Where supported," per the changelog |
| Enterprise enforcement | Server-managed, MDM-managed, or file-based settings can require sandboxing and block developers from weakening it | Org policy can require sandboxing; bypass-approval behavior isn't admin-controllable | Not covered by this changelog post (see note below on VS Code's own setting) |
A few caveats worth keeping, straight from the docs: built-in file tools run in-process inside Copilot CLI itself, so the OS-level sandbox can't fully constrain them — they check the sandbox policy on a "best-effort" basis instead. And local sandboxing is off by default; a developer running Copilot CLI without enabling it gets the old behavior, where shell commands run with the full access of their user account.
How to turn it on
For Copilot CLI, GitHub's documentation gives a single command: run /sandbox enable inside a CLI session. The setting persists across future sessions until you run /sandbox disable. From there, filesystem paths, network rules, credential handling, and whether local MCP/language servers run inside the sandbox are all configurable policy fields, per the docs. If an organization's managed settings require sandboxing, ordinary user settings can't turn it back off; if the managed policy explicitly allows a bypass, a developer can disable it for that session only, without changing the saved org policy.
The GitHub Copilot app exposes a smaller subset of the same controls through project settings — additional allowed/denied paths, a network on/off switch, and a credentials toggle — and can prompt a developer to approve an individual command running outside the sandbox when needed.
Platform support notes
Because MXC maps the same policy onto different OS primitives, support isn't perfectly uniform. GitHub's docs note that macOS uses a Seatbelt-based backend (macOS 15 Sequoia or later recommended, though older versions aren't blocked), Linux needs Bubblewrap 0.5.0+ on the PATH plus additional packages for outbound-traffic control, and Windows needs a recent Windows 11 update, with some features — denied paths, localhost connections, proxying — depending on exactly which Windows build is installed. Where a host can't enforce a given control, GitHub's stated behavior is to report the gap or fail the command, rather than silently running with a weaker policy.
Enterprise-managed policy
For organizations, the headline capability is control, not just protection. Server-managed, MDM-managed, or file-based managed settings let an enterprise require local sandboxing across its developers and prevent individual settings from weakening that policy. The docs also describe an edge case: if a managed policy requires sandboxing on a machine where the sandbox backend isn't available (say, missing Bubblewrap on an older Linux box), and the policy additionally sets a "fail if unavailable" flag, Copilot CLI will block model requests and tool execution entirely for that session rather than falling back to unsandboxed access.
How this relates to VS Code's agent sandboxing
This GA announcement lands one day after a related-sounding feature: VS Code 1.141 shipped its own "agent sandboxing" for terminal commands run by chat agents, toggled via the chat.agent.sandbox.enabled setting. The two are not confirmed to be the same thing, and it's worth not conflating them. GitHub's Copilot changelog lists "VS Code sessions using Agent Host" as one of three surfaces covered by local sandboxing and MXC — which strongly suggests shared underlying plumbing — but the VS Code 1.141 release notes describe their sandboxing using Bubblewrap and OS-level restrictions directly, without naming MXC or linking back to this Copilot changelog post. Until GitHub or the VS Code team explicitly says otherwise, the safest reading is that VS Code's agent sandboxing and GitHub Copilot's MXC-powered local sandboxing are closely related, overlapping security efforts aimed at the same problem — unrestricted agent-run commands — rather than confirmed to be one identical mechanism under two names.
Why this matters now
Agentic coding tools have spent the last year gaining more autonomy: running shell commands, editing multiple files, and increasingly operating a computer directly rather than just suggesting code. Each of those capabilities also expands what can go wrong if a model is manipulated by malicious content in a repo, a dependency, or a web page it fetches — a prompt-injection path that security researchers have flagged repeatedly as agentic tools get more autonomy. Local sandboxing is GitHub's answer for the "runs on my own laptop" half of that problem: instead of trusting the model's judgment about what a command should be allowed to do, the OS itself enforces a boundary around it, independent of whatever model happens to be generating the command.
That boundary is also how GitHub can let enterprises mandate a security posture across every developer's machine without touching the cloud at all, which matters for regulated environments where code, credentials, and internal network access can't leave a managed laptop. It follows other recent moves in the same general direction inside Copilot's security push, including the model lineup changes GitHub pushed through in early October, as the company continues iterating quickly on both capability and guardrails inside the same product. The underlying tension GitHub is managing is a familiar one in developer tooling: the more a coding agent can do unsupervised — install packages, run arbitrary shell commands, read and write anywhere on disk — the more useful it is for genuinely automating work, but also the larger the blast radius if something goes wrong, whether that's a hallucinated destructive command, a compromised dependency, or a maliciously crafted file designed to manipulate the agent into leaking credentials. Putting that enforcement at the OS layer, via MXC's native backends, rather than asking the model to simply decline unsafe actions, is a materially different trust model, and one that doesn't degrade as models change or get swapped out.
What's next
Local sandboxing is GA today, but GitHub's own docs flag it as one half of a two-part system: cloud sandboxing — fully isolated, ephemeral Linux environments built on Azure Container Apps Sandboxes — remains in public preview, billed separately by compute-second, memory, and storage, and is off by default at the organization level. Expect GitHub to keep expanding policy granularity (particularly around Windows network controls, which the docs already flag as weaker than the macOS/Linux proxy-based approach) and to fold more of Copilot's agentic surface area — MCP servers, language servers, and whatever comes after Agent Host in VS Code — under the same MXC-backed policy model. Developers evaluating Copilot CLI or VS Code's agent features against other AI coding assistants may also want to weigh sandboxing maturity as a factor; it's one more axis where tools in this category are starting to differentiate, alongside the pricing and model-choice comparisons already circulating for Copilot, Cursor, Claude Code, and Codex.
Frequently asked questions
What is GitHub Copilot's local sandboxing feature?
It's a secure execution boundary for commands and tools that Copilot's agent mode runs on a developer's own machine. It restricts what those commands can read or write on disk, what network destinations they can reach, and whether they can use Git or GitHub CLI credentials, based on a policy set by the developer or their organization. GitHub announced it reached general availability on October 7, 2026.
What is MXC (Microsoft eXecution Container)?
MXC is an open-source sandboxing SDK from Microsoft that local sandboxing is built on. It maps one common sandbox policy onto native OS isolation backends on Windows, macOS, and Linux (Bubblewrap on Linux, Seatbelt on macOS, and a native process container on Windows), so GitHub doesn't need separate enforcement code per platform. It's MIT-licensed and available on GitHub at microsoft/mxc.
Is local sandboxing turned on by default?
No. GitHub's documentation says local sandboxing is off by default for individual developers. Without enabling it, shell commands that Copilot runs have the same filesystem and network access as the signed-in user account. Enterprises can require it and block it from being turned off.
How do I enable local sandboxing in GitHub Copilot CLI?
Run the /sandbox enable command inside a Copilot CLI session. The setting persists across future sessions until you run /sandbox disable. From there you can configure filesystem paths, network rules, credential handling, and whether local MCP and language servers run inside the sandbox.
Which GitHub Copilot surfaces support local sandboxing?
According to GitHub's changelog, local sandboxing applies to GitHub Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host. It applies regardless of which AI model Copilot is using, since the sandbox restricts tool execution rather than the model itself.
Is GitHub Copilot's local sandboxing the same thing as VS Code 1.141's agent sandboxing?
They appear related but aren't confirmed to be identical. GitHub's Copilot changelog lists VS Code sessions using Agent Host as a supported surface for its MXC-powered local sandboxing, which suggests shared plumbing. However, VS Code's own 1.141 release notes describe their agent sandboxing using Bubblewrap and OS-level controls directly, without mentioning MXC or this Copilot announcement, so the two should be treated as closely related but separately documented features rather than one confirmed identical mechanism.
Sources
Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.
