GitHub has made local sandboxing generally available for GitHub Copilot CLI, the GitHub Copilot app, and VS Code sessions using Agent Host. The feature gives developers a way to restrict the resources Copilot commands can access on their machines. GitHub’s October 7 announcement follows the Copilot app’s September 23 public preview.
The practical qualification is that local sandboxing remains off by default, according to GitHub’s documentation. Availability alone does not activate it. Developers also need to distinguish between the app’s project settings, the CLI’s persistent sandbox setting, and execution that falls outside the local sandbox’s scope.
How local sandboxing works
GitHub describes local sandboxes as isolated execution environments for Copilot’s interactions with code, tools, the filesystem, and network resources. The purpose is to reduce the potential impact of unintended commands by limiting access to resources on the developer’s machine.
The underlying technology is Microsoft eXecution Container (MXC), which GitHub describes as a cross-platform interface to the isolation mechanisms available on each operating system. That places operating-system enforcement at the center of the design. In its app announcement, GitHub says that if the operating system cannot enforce the requested policy, the sandboxed shell returns an error instead of running without a sandbox. GitHub’s documentation explains the MXC architecture; the app announcement describes the enforcement behavior.
For engineers assessing the feature, that failure behavior matters: an unenforceable requested policy stops the sandboxed shell. It does not establish that every tool or external service involved in a Copilot workflow is covered. GitHub explicitly excludes remote MCP servers from sandboxing, a boundary teams need to account for separately.
What the Copilot app lets developers control
The Copilot app configures local sandboxing per project for local repository and working tree sessions. GitHub’s September preview announcement describes three groups of settings:
| Policy area | Documented project controls |
|---|---|
| Filesystem | Additional read/write folders, additional read-only folders, and denied folder lists |
| Network | Outbound internet and local network settings |
| Credentials | Git credentials for authenticated HTTPS git operations, and GitHub CLI credentials for GitHub CLI authentication |
These controls make the access policy more specific than a single decision to enable isolation. Folder permissions, network access, and authentication are separate parts of the configuration. For a security review, the useful question is therefore which resources a particular project session can reach under its effective policy.
The distinction between requested and effective policy is explicit in GitHub’s app announcement. Project settings describe the policy the app requests when a sandboxed session starts. Enterprise-managed settings can make the effective policy more restrictive. A project’s configuration consequently should not be read as the final authority over what a session is permitted to access.
This also creates a practical troubleshooting distinction. A developer can request access in project settings while enterprise restrictions still limit the running session. Separately, a shell error can indicate that the operating system cannot enforce the requested policy. Those are different conditions to consider when reviewing a sandboxed workflow.
Enabling the app and CLI requires different steps
In the Copilot app, GitHub’s documented setup is to open app settings, select the project, and turn on Sandbox new sessions under Sandbox. The switch applies to new sessions in that project; it does not change sessions already running.
Changes to filesystem, network, and credential settings likewise apply to new sessions or when an existing session restarts. That timing matters when tightening access: editing a project policy is not evidence that an already running session has adopted it.
For an active local app session, the September announcement gives this command:
/sandbox on
GitHub says this changes that session without changing the project default. The app’s project default and an individual session’s sandbox state therefore need to be considered separately. These app instructions come from the September preview announcement; the later general-availability notice establishes the launch status.
The CLI has its own documented command. Inside a Copilot CLI session, run:
/sandbox enable
According to GitHub’s sandbox documentation, Copilot continues using local sandboxing, including in future sessions, until it is disabled with:
/sandbox disable
The app and CLI sandbox settings are configured separately. The commands and persistence rules should be kept attached to their respective interfaces: the app’s active-session command does not change its project default, while the CLI documentation describes a setting that continues into future sessions.
GitHub’s general-availability announcement also includes VS Code sessions using Agent Host. The evidence supporting that availability does not provide a separate VS Code configuration procedure, so the app and CLI steps above should not be treated as universal instructions for every supported interface.
Local and cloud sandboxes have different boundaries
GitHub offers local and cloud sandboxes as distinct execution environments. Its documentation draws the following distinction:
| Local sandboxing | Cloud sandboxing | |
|---|---|---|
| Execution location | On the local machine | A GitHub-hosted, fully isolated, ephemeral Linux environment |
| Session scope | Local sandboxed execution | An entire Copilot session running remotely |
| Charging | No extra charge for local sandboxing | Billed based on usage |
The documentation supplies these environment and charging details. It does not give a usage rate in the supplied evidence, so the pricing distinction supports an architectural comparison rather than a cost estimate.
Local sandboxing does not apply to cloud sandbox sessions or sessions running on a remote host, according to the app announcement. GitHub’s documentation separately states that remote MCP servers are never sandboxed. Enabling local isolation should therefore not be taken as evidence that those remote execution paths have acquired the same restrictions.
For software and security engineers, the launch’s value lies in a configurable boundary around local execution. Evaluating that boundary requires checking whether sandboxing is enabled, which application’s settings apply, when policy changes take effect, and whether the work actually runs inside its scope. Those details determine what protection a particular session receives.
