Local sandboxing for GitHub Copilot is now generally available. Commands and tools that Copilot's agent runs on a developer's machine can be confined to set files, network destinations and credentials, and organisations can enforce those limits centrally. For teams, it turns "how much can the agent touch on my laptop?" into a written policy rather than a habit.
What was released
Local sandboxing for GitHub Copilot was announced as generally available by GitHub on 7 October 2026 in the GitHub changelog. It covers three places where Copilot runs agent work locally: GitHub Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host. GitHub says it is included with Copilot at no additional cost.
What actually changed
According to the announcement, tools and commands started by Copilot now run with restricted access to the filesystem, network, credentials and other system capabilities, based on policies set by the developer or their organisation. In practice that means:
- Files: limit which files and directories agent-run commands can read or change.
- Network and credentials: control access to the internet, local networks, Git credentials and GitHub CLI credentials.
- Local tools: apply the same sandbox to local tools and services, including local MCP servers and language servers where supported.
- Central enforcement: enterprise-managed settings can require sandboxing and set policies that developers cannot weaken.
GitHub also makes a point that matters for architecture: model execution and tool isolation are separate concerns, so the sandbox policy applies to tool execution whichever model Copilot is using.
How it works underneath
The sandbox is built on Microsoft eXecution Container (MXC), an open-source project that turns one policy into native operating-system controls on Windows, macOS and Linux. Its README lists the default backend on each platform: a process container on Windows 11, Bubblewrap on Linux and Seatbelt on macOS. Policies cover filesystem paths (read-only, read-write and denied lists), outbound network controls and, on some backends, host filtering.
The same README is candid about the cost of adoption: tools will hit access-denied errors until the containment rules are tuned, and MXC ships diagnostics to find what a trusted tool actually needs. Teams should expect that tuning step rather than a silent switch-on.
What it means for teams building with AI agents
Until now, giving a coding agent more autonomy on a laptop has mostly meant trusting it with everything the developer can reach: the whole home directory, every network, and the Git and GitHub credentials already signed in. Local sandboxing gives that trust a boundary you can write down and review. In CodeDTX's view, these are the practical steps:
- Start with credentials and network, not files. The most damaging agent mistakes are a push, a token sent somewhere it should not go, or a call into an internal service. Deny GitHub CLI credentials and broad internet access by default, and allow back only what a workflow needs. Our guide on the AI agent attack surface covers why these paths matter most.
- Include local MCP servers in scope. An MCP server running locally is often the widest door an agent has. Where sandboxing supports them, put them under the same policy rather than treating them as trusted. See how AI agents connect securely.
- Enforce it centrally once the policy is stable. Pilot with a few teams, collect the access-denied cases, then use enterprise-managed settings so the policy cannot be weakened on individual machines.
- Keep the sandbox and the model decision apart. Because the policy applies regardless of model, changing models or adding a local model does not need a new security review of tool access. It does still need an evaluation of output quality.
- Write it into your agent controls. A sandbox limits what can be touched; it does not decide whether an action is right. Keep approvals for consequential steps, as in stopping an agent taking a wrong action.
When not to rely on it alone
Local sandboxing covers agent work on a developer's own machine through the three supported surfaces. It is not a replacement for repository protections, branch rules, secret scanning or code review, and it does not govern agents your team runs on servers or in CI. If developers use other coding agents alongside Copilot, those agents are outside this policy, so an organisation-wide rule that only covers Copilot can give a false sense of coverage. For the wider picture, see stopping agents reaching restricted data.
Frequently asked questions
What does GitHub Copilot local sandboxing restrict?
It restricts what commands and tools started by Copilot can do on a developer's machine. Policies can limit which files and directories they read or change, and control access to the internet, local networks, Git credentials and GitHub CLI credentials. It can also cover local tools such as MCP servers and language servers where supported. The limits come from policies set by the developer or their organisation.
Where is Copilot local sandboxing available?
GitHub's announcement of 7 October 2026 says it is generally available in GitHub Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host. It works across Windows, macOS and Linux, because the underlying Microsoft eXecution Container project maps one policy onto each operating system's native controls. GitHub says it is included with Copilot at no additional cost.
Can an organisation force developers to use the sandbox?
Yes. GitHub says enterprise-managed settings can require sandboxing and enforce policies that developers cannot weaken. A sensible path is to pilot a policy with a small group, record the access-denied cases that real work produces, adjust the rules, and only then enforce it across the organisation so developers are not blocked on their first day.
Does the sandbox depend on which AI model Copilot uses?
No. GitHub states that model execution and tool isolation are separate concerns, and sandbox policies apply to tool execution regardless of the model. That means switching between cloud models, or adding a local model, does not change what the agent's tools can reach. You should still evaluate a new model's output quality before relying on it for real work.
