Restrict Agent Permissions First as GitHub Copilot Local Sandboxing Reaches GA

What is local sandboxing, and where can you use it?

It is a boundary that limits what Copilot can do when it runs commands on your computer. According to the GitHub changelog, it is available in Copilot CLI, the GitHub Copilot app, and VS Code sessions that use the Agent Host. Isolation uses Microsoft eXecution Container (MXC), which applies one sandbox policy through the native controls of Windows, macOS, and Linux.

It is reportedly included in Copilot at no extra cost. The changelog did not say which plans can use it.

What can you restrict?

The official documentation describes these controls for Copilot CLI.

Credentials are handled in an unusual way. The documentation explains that tools inside the sandbox receive only placeholder values, and a local proxy passes the real values only to approved HTTPS destinations. The GitHub Copilot app offers a subset of these controls: it exposes only file paths, internet and local network access, and whether Git and GitHub CLI credentials are available.

This is based on the official GitHub documentation, checked on 2026-10-09.

How do you turn it on, and what is the default?

The default state is off. Until you turn it on, Copilot's shell commands run with the same access your user account has. In the CLI, running /sandbox enable in a session keeps it on for later sessions too, and /sandbox disable turns it off.

It applies to shell commands, file search, and, with the default settings, local MCP servers and language servers. Remote MCP servers, on the other hand, are not covered by the sandbox. If your automation connects to external services, design the permissions on the remote server side separately.

Is the protection level the same on every operating system?

No. Collecting the differences in the documentation by operating system gives the table below.

On macOS and Linux, even programs that ignore proxy settings cannot connect directly. On Windows, the documentation says that if a requested restriction cannot be enforced, the command fails rather than running with a weaker restriction.

Can an organization enforce its use?

Yes. Server-managed, MDM-managed, and file-based managed settings can require the sandbox and lock its configuration. The changelog also says enterprise-managed settings can enforce a policy that developers cannot weaken.

Two values are mentioned in managed settings: sandbox.enabled and sandbox.failIfUnavailable. When both are true, the CLI blocks model requests and tool execution in environments where the sandbox cannot be applied. On unsupported hosts, a server-managed enable request is rejected unless failIfUnavailable is also true. And if the policy allows bypass, a user can turn it off for the current session only, and the stored policy does not change.

What limits should you know before adopting it?

The documentation states a few limits itself.

• It is operating-system-level isolation, lighter than a virtual machine or container. If your security requirements are high, it advises checking the MXC implementation.
• The built-in file tools run inside the CLI process, so the operating system sandbox cannot see them. These tools check the policy themselves, and enforcement is best effort.
• On Linux, bubblewrap cannot separately control local network access for child processes such as shell commands and local MCP and language servers.
• On unsupported hosts, the CLI leaves the stored settings as they are, turns the sandbox off for that session only, and shows a notice.

Model and tool isolation are separate. The changelog explains that the sandbox policy applies to tool execution in the same way whichever model you use.

How is it different from the cloud sandbox?

The same documentation also covers cloud sandboxing. That runs the whole session in a temporary Linux environment hosted by GitHub, is in public preview, and may change. An organization or enterprise owner has to turn on the Cloud Sandbox access policy, and it is off by default. The difference is that local runs on your own computer and is included with your seat, while cloud is billed by usage. The general availability news in this article applies to the local one.

In what order should you apply it to agent automation?

Start by fitting the allowed paths to read-only work and narrowing them to a single project directory, and put only the hosts you need on an external-communication allow list. It is better to open Git credentials only for tasks that truly need them. Then add per-command exceptions one at a time, which leaves a record of which task needs which permission.

For teams, before you set a required level in managed settings, make a list of any development environments that are not supported. The protection level varies by operating system version.

Where do you check the latest information?

The reference is the October 7, 2026 GitHub Changelog post and the sandbox page in GitHub Docs, checked on 2026-10-09. Setting names and requirements can change, so reopen the official documentation once more before you apply this to your team.