Why it mattersTeams that were waiting for GA before letting the agent run its own commands can now limit each session to a folder, a network and a credential store without buying anything extra.
A team that lets a coding agent run shell commands used to give the agent the same access the developer has to the whole machine. GitHub narrowed that, moving its local sandbox for the Copilot agent to general availability and extending it from the desktop app alone to the Copilot CLI and to VS Code sessions that run through Agent Host. The feature had been in public preview in the Copilot desktop app since late September.
GitHub says a local sandbox "gives developers a secure execution boundary for agentic workflows on their own machines", and limits what tools and commands can reach on the filesystem, the network, in credential stores and in other system capabilities. The policy is set by the developer or by an organisation, and the operating system enforces it.
Three surfaces, one policy
The GA extends local sandboxing to three places a Copilot agent runs today. The Copilot CLI picks it up for autonomous command runs in a terminal. The Copilot desktop app, which had the preview, now carries the GA version. VS Code gets it on sessions started through Agent Host, which is the component that runs an agent inside the editor with its own tool permissions.
The three paths share one policy mechanism, so a team that writes a sandbox rule for a project does not have to maintain three copies. GitHub notes that policies cover filesystem access, outbound and local network reach, credentials in the operating system's stores, and other system capabilities such as process control.
The mechanism, named for the first time
GitHub also named the component that applies the policy. Local sandboxing uses Microsoft eXecution Container (MXC), which translates sandbox rules into native operating-system controls on Windows, macOS and Linux. That is a change from the preview announcement, which described the mechanism in general terms without naming the container layer, and it means the same policy can be enforced on Windows, macOS and Linux without a different rule per platform.
GitHub says MXC covers tool and command access by applying the policy as native controls rather than as hints the agent follows voluntarily. The post treats "model execution" and "tool isolation" as separate concerns, so an unsandboxed model can still answer in chat while its tool calls run inside the sandbox.
Price and scope
Local sandboxing is included with every GitHub Copilot plan at no additional cost, GitHub says. The post lists no new paid add-on, no seat-count change, and no cap on how many sandboxed sessions a developer can run.
The announcement does not state version numbers for the three clients that carry the GA, or a cutoff for a sandboxed session's duration. It also does not describe how a sandboxed session interacts with an MCP server that itself reaches external systems, beyond saying that sandboxing applies to "local tools and MCP servers".
The scope that is on the page: a session can be limited by file and directory, by internet and local-network reach, by access to credentials, and by the system capabilities a policy chooses to deny. Organisational policy can tighten what a developer has set, in the same way as the preview covered.
Source
Local Sandboxing for GitHub Copilot now generally available, GitHub Changelog.
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.