GitHub has introduced local sandboxing for the GitHub Copilot app as a public-preview feature. The project-level setting places agent-invoked tools inside an operating-system sandbox that can restrict access to files, network resources, credentials, and, where supported, other system capabilities.
For developers, the change adds a policy layer around local repository and working-tree sessions. For administrators, it provides a way to make agent actions more constrained, while retaining control over whether users can run an operation outside the sandbox. The feature is off by default and does not apply to cloud sandbox or remote-host sessions.
What changed in the GitHub Copilot app
Local sandboxing is configured separately for each project in the Copilot app. A project must be selected before its sandbox policy can be configured. The setting applies to new local sessions, or to an existing session after it is restarted; enabling it does not retroactively change a session that is already running.
The project policy can define:
- Additional paths with read/write access
- Additional paths with read-only access
- Denied filesystem paths
- Outbound internet access
- Local-network access where the app supports that control
- Whether Git credentials are available
- Whether GitHub CLI credentials are available
According to the GitHub announcement and the supplied configuration documentation, the documented default policy provides read/write access to the workspace and current working directory. It also permits internet and local-network access and allows authenticated Git and GitHub CLI operations. Teams can tighten those defaults when a project needs more restricted behavior.
A more-specific denied path remains denied even when a broader parent path has otherwise been granted access. That makes denied paths useful for protecting sensitive locations within an otherwise accessible directory structure.
Session behavior matters
Policy changes generally take effect only when a new session starts or an existing session restarts. The app’s /restart-session command restarts the session while preserving its history, allowing a changed policy to take effect without discarding the conversation context.
For an active local session, /sandbox on and /sandbox off can change the sandbox state for that session. These commands create session-specific behavior and do not change the project default for other sessions.
This distinction is important operationally. A project may have a restrictive default, while a particular session can still present an option to run a disallowed operation outside the sandbox. Depending on the choice presented by the app, a user may cancel the operation, run it once outside the sandbox, or disable sandboxing for the remainder of that session. An enterprise owner can prevent users from running tools outside the sandbox, although the supplied documentation does not describe the complete administrator deployment procedure.
Fail-closed behavior and platform limits
Local sandboxing depends on the host being able to enforce the requested policy. When the host cannot enforce it, the sandboxed shell fails with an unsupported-platform or unsupported-policy error instead of running unsandboxed. On Windows, the documentation also states that a denied path that cannot be guaranteed by the active sandbox capabilities causes the command to fail rather than exposing the path or bypassing the sandbox.
The supplied material does not establish a complete operating-system support matrix or the exact Copilot-specific Windows editions, architectures, and build requirements. Those details should be treated as undocumented rather than inferred from the feature announcement.
There is also a Linux-specific limitation for local-network controls. The setting cannot independently constrain local-network access for all spawned processes, including shell commands and local MCP or LSP servers. It does apply to in-process web requests and remote MCP connections. Projects that depend on local services should therefore test their workflows instead of assuming that one network setting covers every process.
What the sandbox protects—and what it does not
Local sandboxing is intended to reduce the potential impact of unintended agent-invoked commands. It is not described as a complete security guarantee. The supplied broader sandbox documentation characterizes the implementation as operating-system-level isolation powered by Microsoft eXecution Container technology, rather than a separate virtual machine or container.
When sandboxing is disabled, agent-run commands can access the files, networks, and credentials available to the user account. Restricting credentials may prevent authenticated Git operations or GitHub CLI actions. Network restrictions can also interrupt dependency installation, API calls, preview servers, and other development tasks that require connectivity.
In practice, the policy is a trade-off between reducing access and preserving the workflow needed by the project. A tightly restricted configuration may be appropriate for sensitive repositories, but it should be tested against the commands and services developers actually use.
Implications for developers and administrators
Developers should treat filesystem, network, and credential settings as part of the project’s development configuration. A sandbox that denies access to credentials may prevent a Git push or pull-request-related action. A policy that blocks network access may interfere with package installation or a local preview workflow. These are expected consequences of the restrictions, not evidence that the sandbox is malfunctioning.
Administrators should also account for the difference between a project request and the effective policy. Enterprise-managed settings may be more restrictive, and users may be prevented from choosing to run tools outside the sandbox. Because the app’s controls are project-specific, teams should document their intended policy rather than assuming that enabling sandboxing in one project changes another.
Local sandboxing is separate from Copilot CLI sandbox configuration. Settings for the GitHub Copilot app and Copilot CLI do not change one another, and the two surfaces do not expose identical controls. Teams using both should configure and evaluate them independently.
What you should do
- Select the project in the GitHub Copilot app and enable Sandbox new sessions for projects where local agent actions should be constrained.
- Review filesystem access. Add only the read/write and read-only paths required by the workflow, and use denied paths for sensitive folders.
- Review network access. Decide whether outbound internet and local-network access are necessary, especially for projects that install dependencies, call APIs, or run local services.
- Review credentials. Confirm whether Git credentials and GitHub CLI credentials need to be available inside the sandbox.
- Restart existing sessions after changing the project policy. Use
/restart-sessionwhen preserving session history is useful. - Test unsupported-policy behavior on the hosts used by your team. The documented behavior is to fail rather than run the requested shell unsandboxed when the host cannot enforce the policy.
- Set expectations for exceptions. Decide whether users may run individual tools outside the sandbox, and confirm whether enterprise policy restricts that option.
Availability and caveats
Local sandboxing is in public preview and may change. The supplied GitHub documentation states that the Copilot app is available across Copilot plans, while the broader sandbox documentation says local sandboxing is included in the standard Copilot seat at no additional cost. Those availability and pricing statements should be read as documentation claims, and the exact supported Windows matrix remains unspecified.
The feature is for local repository and working-tree sessions in the Copilot app. It does not apply to cloud sandbox sessions or remote-host sessions. Developers should also remember that a working tree separates branches and files but does not, by itself, restrict command access elsewhere on the machine; local sandboxing supplies that additional policy boundary when the host can enforce it.
