GitHub Copilot local sandboxing reaches general availability

GitHub announced on October 7, 2026, that local sandboxing for GitHub Copilot is generally available. The feature applies to Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host. Commands that Copilot runs on a developer's own machine now execute inside an operating-system sandbox with limits on files, network and credentials.

What local sandboxing for GitHub Copilot does

The GitHub changelog entry (opens in a new tab) describes local sandboxing as an execution boundary for agentic workflows. Tools and commands that Copilot starts run with restricted access to the filesystem, network, credentials and other system capabilities. The developer or their organization defines the policy.

GitHub lists five controls in the post. Teams can limit which directories agent-run commands read or modify. Access to the internet, local networks, Git credentials and GitHub CLI credentials can be switched on or off. Local MCP and language servers can run inside the sandbox where supported. Enterprises can require sandboxing and lock policies so developers cannot weaken them.

Sandbox policies cover tool execution only. GitHub states that they apply whichever model Copilot uses, because model execution and tool isolation are separate concerns.

The engine underneath: MXC

Local sandboxing is built on Microsoft eXecution Container (MXC) (opens in a new tab), an MIT-licensed project that turns one sandbox policy into native operating-system controls. The MXC README lists seatbelt as the default backend on macOS, bubblewrap on Linux and processcontainer on Windows 11. MXC ships SDKs for Rust, .NET and Node.

How local and cloud sandboxes differ

GitHub's docs on cloud and local sandboxes (opens in a new tab) separate two options. A local sandbox runs Copilot on your machine and is included in the standard Copilot seat at no extra cost. A cloud sandbox runs the whole session in an isolated, ephemeral Linux environment hosted by GitHub, built on Azure Container Apps Sandboxes.

Cloud sandboxes remain in public preview and are billed by usage. Only the local option reached general availability in this announcement.

Who it is for

Developers who let GitHub Copilot run shell commands with less supervision get a fixed boundary around those commands. A command that tries to read outside allowed paths or reach a blocked host is stopped at the operating-system level, within the limits listed further down.

Credential handling has its own mechanism. The docs say sandboxed tools receive placeholders, and a local proxy supplies real credentials only to approved HTTPS destinations. Extra environment variables can be masked too.

Platform and security owners get enforcement. Managed settings can come from a server, MDM or a file. Once managed settings require sandboxing, ordinary settings and startup options cannot turn it off.

How to turn it on

In Copilot CLI, run /sandbox enable. The setting persists across sessions until you run /sandbox disable, and it is stored as sandbox.enabled. In the GitHub Copilot app, set the default in project settings or change it for an active local session. The two surfaces keep separate settings.

Each operating system has requirements:

• macOS uses Seatbelt, and the docs recommend macOS 15 (Sequoia) or later.
• Linux needs bubblewrap 0.5.0 or later with bwrap on your PATH. Outbound traffic also needs slirp4netns, util-linux 2.35 or later, iptables tooling and access to /dev/net/tun.
• Windows requires a recent Windows 11 update that supports sandboxing.

On an unsupported host, the CLI turns off the saved preference for that session and shows a notice. An administrator who wants a hard failure instead can set sandbox.failIfUnavailable. With both that setting and sandbox.enabled set to true in managed settings, the CLI blocks model requests and tool execution when it cannot enforce the sandbox.

Limits GitHub documents

Local sandboxing is lighter isolation than a VM or container. It restricts file, network and process access at the OS level.

The docs list several gaps:

• Built-in file tools run in-process in the CLI, so the OS sandbox cannot constrain them. They check the policy on a best-effort basis.
• On Linux, bubblewrap cannot control local network access separately for spawned processes, including shell commands and local MCP and LSP servers.
• On Windows, proxy and host rules depend on programs honoring proxy settings. Direct connections are less constrained than on macOS and Linux.
• Remote MCP servers are never sandboxed.

What is not known yet

The changelog does not explain how sandboxing behaves inside VS Code sessions using Agent Host beyond naming that surface. The docs page reviewed here covers configuration for the CLI and the app, not VS Code.

The sandboxes docs page does not list which Windows 11 builds qualify. It links to a separate Windows update page for that. The docs do not name Copilot plan tiers either; they say the feature is included in the standard seat. No timeline is given for cloud sandboxes leaving public preview.