GitHub Copilot App Adds Local Sandboxing, Off by Default, to Contain Unintended Agent Commands

Overview

GitHub has added an opt-in, operating-system-level sandbox to the standalone GitHub Copilot app, giving developers a way to limit the file, network, and credential access available to agent-invoked commands during local coding sessions, according to a GitHub Changelog post published September 23, 2026. GitHub says the feature “helps reduce the potential impact of unintended commands by limiting access to files, network resources, and credentials on your machine.”

The feature, called local sandboxing, is configured per project for local repository and working tree sessions inside the GitHub Copilot app, the standalone desktop program GitHub introduced in technical preview earlier this year for agent-driven development.

What We Know

Local sandboxing works by running an agent’s invoked tools inside an operating-system sandbox rather than directly on the host machine. Per GitHub’s documentation, the feature “runs the tools that an agent invokes on your behalf inside an operating-system sandbox” to “reduce the potential impact of an unintended command by limiting access to files, network resources, and credentials on your machine.”

The policy is broken into three configurable categories, according to the changelog post:

• Filesystem — “Additional read/write, additional read-only, and denied folder lists.” The documentation adds that “a more-specific denied folder remains denied when a broader parent folder has read or write access.”
• Network — “Outbound internet and local network settings.” On Linux, the docs note a limitation: “the sandbox cannot control local network access independently for spawned processes, such as shell commands and local MCP or LSP servers.”
• Credentials — “Git credentials for authenticated HTTPS git operations, and GitHub CLI credentials for GitHub CLI authentication.”

Once turned on, the default policy is permissive enough to cover routine work: the documentation states it “allows common development tasks such as installing dependencies, connecting to a local development server, pushing a branch, and creating a pull request.”

The feature enforces a fail-closed design rather than silently falling back to unsandboxed execution. According to the changelog, “if your operating system cannot enforce the requested policy, the sandboxed shell fails with an error rather than running without a sandbox.” The documentation describes this more specifically: “the app accepts sandbox settings before checking whether your operating system can enforce them. Support is checked when the first sandboxed shell starts,” and if enforcement fails, “the shell fails with an unsupported-platform or unsupported-policy message and does not run unsandboxed.”

Local sandboxing is off by default. GitHub’s changelog instructs users to “open the app settings, select your project, and turn on Sandbox new sessions under ‘Sandbox’” to enable it, noting that “this applies to new sessions in the project, not sessions already running.” Settings changes take effect for new sessions or when an existing session restarts, which the documentation says can also be triggered with a /restart-session command. Within an active session, users can flip the setting immediately with a slash command: “to enable sandboxing for an active local session, enter /sandbox on.” According to the documentation, that command and its /sandbox off counterpart create “a persistent override for that session and applies it immediately,” without changing the project-level default.

Enterprise administrators can tighten the policy further. Both sources note that “the effective policy can be more restrictive when enterprise-managed settings apply,” and the documentation adds that “an enterprise owner can prevent users from running tools outside the sandbox.” When a tool call would otherwise be blocked, the documentation says the app can surface a “Run outside the sandbox?” prompt, letting a user cancel, run once outside the sandbox, or disable sandboxing for that session.

The scope is limited to local sessions. GitHub’s changelog specifies that “local sandboxing does not apply to cloud sandbox sessions or sessions running on a remote host,” and that “GitHub Copilot app and Copilot CLI sandbox settings are configured separately” — meaning the toggle covers only the standalone desktop app, not GitHub’s other Copilot surfaces. GitHub says the feature is “in public preview and subject to change.”

Context

The rollout extends a run of security controls GitHub has layered onto the Copilot app and its sibling surfaces since the desktop client entered technical preview in May. In August, GitHub shipped enterprise-wide allow/deny lists for MCP servers reachable through Copilot, enforced fail-closed across the app, CLI, and VS Code — a separate control aimed at which external tools an agent can call rather than what a locally invoked command can touch on the machine itself.

What We Don’t Know

GitHub has not said when local sandboxing will move out of public preview or whether it will eventually ship on by default. The company also has not disclosed adoption figures, a timeline for bringing an equivalent toggle to Copilot CLI or the VS Code extension, or how the feature interacts with the app’s cloud-agent and remote-host sessions beyond stating that those session types are out of scope.