GitHub announced local sandboxing in the Copilot app on September 23, 2026. The public preview is designed to reduce the impact of unintended commands by limiting what an agent can access on a project-by-project basis: files, network resources, and credentials used by Git or the GitHub CLI.
Project settings can define additional read/write folders, additional read-only folders, and denied folders. Network controls cover outbound internet and local-network access. Credential settings cover Git credentials for authenticated HTTPS operations and GitHub CLI credentials. That is closer to real development governance than a single machine-wide switch because repositories can carry different trust boundaries.
GitHub says these settings describe the policy requested when a sandboxed session starts, while enterprise-managed settings can make the effective policy more restrictive. The most important failure behavior is fail-closed: if the operating system cannot enforce the requested policy, the sandboxed shell fails instead of silently running without a sandbox. That prevents a dangerous assumption that the agent is still contained.
Local sandboxing is off by default. A user enables Sandbox new sessions in the app settings for a selected project; the setting applies to new sessions rather than retroactively resetting an existing one. An active session can also be switched on with `/sandbox on`, while changes to filesystem, network, or credential policy generally take effect in a new session or after a restart.
The local sandbox does not apply to cloud sandbox sessions or remote hosts, and the Copilot app and Copilot CLI manage their sandbox settings separately. That boundary matters for enterprises: a control configured in one surface should not be assumed to follow an agent into another execution environment without a separate review of location, network paths, and credentials.
From a governance perspective, sandboxing isolates execution; it does not solve model judgment. It narrows the impact of a bad command, but it does not replace code review, version control, least privilege, secret rotation, or approval for high-impact actions. Permission to write to a folder is not evidence that every resulting change is safe.
A sensible rollout starts with a test repository that has no production credentials. Teams can restrict external network and sensitive folders, observe what the agent asks to access, and widen the policy only when the workflow justifies it. If sandbox enforcement fails, the right response is to fix the deployment or policy rather than bypass the boundary.
For local coding agents, security is not only about whether the model refuses a dangerous request. It is also about what the system can touch when a request is accepted. GitHub’s project-level filesystem, network, and credential controls, combined with fail-closed behavior, move the agent workflow closer to an auditable engineering system instead of a black box with access to the whole machine.
