GitHub Copilot local sandboxing is generally available

What became generally available on 7 October?

GitHub’s changelog dated 7 October 2026 states that local sandboxing is generally available in three surfaces: GitHub Copilot CLI, the GitHub Copilot app, and VS Code sessions using Agent Host. The same post lists what organizations can do with it: limit readable and writable paths, control internet and local-network access, gate Git and GitHub CLI credentials, apply sandboxing to supported local MCP and language servers, and enforce enterprise-managed policies that developers cannot weaken.

The 9 October weekly Copilot release note repeats the GA line and adds Haiku 5.5 availability plus Copilot CLI `/model` discovery for local Ollama instances. Those are separate product updates; this article stays on sandboxing. For broader agent isolation patterns, see our AI agent sandboxing explainer.

How does local sandboxing actually constrain tools?

GitHub’s conceptual docs say local sandboxing is powered by Microsoft eXecution Container (MXC): Copilot declares a policy—paths, network, capabilities—and MXC applies the matching OS backend. On macOS that is Seatbelt; on Linux, bubblewrap with additional packages for outbound traffic; on Windows, a recent Windows 11 build with feature-dependent support. The docs explicitly place local sandboxing on the lighter-weight end of the isolation spectrum: restricted read/write and network reach, not a separate hypervisor or container by default.

The changelog also separates model execution from tool isolation: sandbox policies apply to tool execution regardless of which model Copilot uses. That matters if your org swaps models while keeping the same agent host. Microsoft’s public MXC repository is the implementation pointer GitHub cites for evaluation detail; we opened the repository page but did not audit its code.

Important caveats in the docs: local sandboxing is off until enabled (`/sandbox enable` in CLI, or project defaults in the app). Built-in in-process file tools are not seen by the OS sandbox and instead honor policy on a best-effort basis inside the CLI. Settings in the CLI and the app are separate. Remote MCP servers are never sandboxed.

What is still separate: cloud sandboxes and enterprise policy?

Cloud sandboxes are a different product surface: entire sessions in GitHub-hosted ephemeral Linux environments, currently called out as public preview/experimental in the docs we opened, with compute, memory, and storage meters. Local sandboxing is included in the Copilot seat; cloud sandboxing is billed. Organization owners must enable cloud-sandbox access before members can use it.

Enterprise-managed settings can require local sandboxing and refuse disable attempts. That is the governance path for teams that want autonomous agents without giving them the user’s full shell. Pair it with approval gates described in our agent approval gates guide rather than treating the OS boundary as a complete control plane.

What should a team try before trusting the GA label?

Start with a disposable repository and a hostile prompt that tries to read `~/.ssh`, hit an unexpected host, or call `gh` against a private org. Confirm `/sandbox status` and `/sandbox policy` match the paths you intend. On Linux, verify bubblewrap and the outbound-network helpers before promising enforcement. On Windows, confirm the host build supports denied paths and proxying if those are in your policy.

If your workflow depends on local MCP servers, decide whether they should run inside the sandbox. If they need broad filesystem access, either grant explicit paths or keep those tools out of the agent loop. Document the difference between “sandbox enabled in CLI” and “sandbox enabled in the Copilot app,” because they do not sync.

Also decide your failure mode when the host cannot enforce a requested control: GitHub documents fail-open versus fail-closed behaviors that depend on managed settings and `sandbox.failIfUnavailable`. Security teams usually want fail-closed for required sandboxes; developer laptops without bubblewrap may need a clear exception process instead of a silent downgrade.

1. Enable sandboxing on a canary machine and attempt a denied-path write.
2. Probe network allow/deny lists with a known-bad host.
3. Confirm enterprise managed settings survive a local `/sandbox disable` attempt.
4. Retest after the next Copilot CLI or VS Code Agent Host update.

What did we not test?

We did not install Copilot CLI, enable local sandboxing, exercise MXC backends, start a cloud sandbox, or measure breakout resistance. Platform support statements and pricing tables are GitHub’s. Partner claims about “more autonomous agent workflows” remain vendor framing until verified on your hosts.