GitHub Copilot Local Sandboxing: Setup, Defaults and Limits

When a coding agent can run shell commands on your computer, a separate Git worktree does not limit what those commands can reach elsewhere on the machine. GitHub has begun rolling out local sandbox controls for the Copilot app, with a separate experimental setup in Copilot CLI. This guide explains how to enable each one, what access remains allowed by default, and which settings are worth checking before you hand an agent a task.

Source check: 27 September 2026. This is a documentation-based guide, not a hands-on test or security certification. Local sandboxing is in public preview; labels and behavior can change. AI tools assisted with drafting, and an editor checked the cited official documentation.

What local sandboxing changes

Local sandboxing runs agent-invoked tools inside an operating-system sandbox whose policy can limit filesystem, network and credential access. It adds a boundary around tool execution; it does not move a local session into the cloud, and it does not make every command or code change trustworthy. GitHub describes the feature as a way to reduce the potential impact of unintended commands, not a guarantee that an agent cannot cause harm. The September 23 release note introduced the app’s project-level controls in public preview.

The first distinction matters: a working tree keeps branches and files for concurrent sessions separate, but by itself it does not restrict what a command can access elsewhere on your machine. A sandbox adds configurable access controls. The GitHub Copilot app and Copilot CLI have separate settings, so enabling one does not enable the other.

Enable sandboxing in the Copilot app

For new local repository or working-tree sessions, open the app’s settings, select the project, and turn on Sandbox new sessions under Sandbox. This is off by default. The project default applies to new sessions; it does not silently change a session already running. Follow GitHub’s app configuration guide if labels differ in your build.

To enable it for an active local session, use /sandbox on. In the app, that changes the active session without changing the project default. If you alter filesystem, network or credential rules, start a new session or restart the current one before assuming the revised policy is in force.

App sandboxing applies to local repository and working-tree sessions, not cloud-sandbox sessions or sessions running on a remote host. Enterprise-managed settings can make the effective policy stricter than the project settings. GitHub says that if the operating system cannot enforce the requested policy, the sandboxed shell fails rather than running without a sandbox.

Review these defaults before the first task

The useful question is not only “Is the sandbox on?” but “What can tools still reach while it is on?” GitHub’s app configuration guide describes these starting permissions:

These controls are practical, but broad defaults are still broad. For a documentation edit, for example, consider denying unrelated folders and removing credentials the task does not need. For a dependency update that must fetch packages, outbound access may be useful; local-network access may not be. Choose permissions around the job instead of treating one preset as right for every repository.

On Linux, GitHub documents an important caveat: local-network restrictions cannot be enforced independently for spawned processes such as shell commands and local MCP or language-server processes. The setting still applies to in-process operations such as web requests and remote MCP connections. Check the platform-specific documentation before relying on a network rule as a hard boundary; GitHub explains this in its app configuration guide.

Copilot CLI uses a different setup

Do not copy the app’s command into CLI instructions. GitHub’s CLI usage guide currently describes sandboxing as experimental: start Copilot CLI with --experimental, or enter /experimental on during a session, then enable the sandbox with /sandbox enable. Use /sandbox status to confirm the session is sandboxed and /sandbox policy to inspect effective access.

copilot --experimental
/experimental on
/sandbox enable
/sandbox status
/sandbox policy

Those slash commands are for an interactive CLI session; the first line is a shell command. GitHub’s current CLI documentation says local sandboxing on Windows requires a Windows Insiders build. CLI defaults also allow outbound and local/private-network access and keep authenticated Git and GitHub CLI operations available unless you change the settings. Read the CLI configuration page rather than assuming the app’s project controls carry over. GitHub’s overview explains how its cloud and local options differ.

Treat bypass prompts as security decisions

If a tool needs access the policy blocks, the app can ask to run it outside the sandbox. Read the command and requested scope; approve only when you understand why it needs broader access. Depending on the effective policy, the prompt may also let you turn sandboxing off for the rest of that session. An enterprise administrator can restrict bypass. A green status indicator alone is not enough: after changing settings, check the session’s effective policy and confirm the task is running locally, not in a cloud or remote session.

For CLI, GitHub likewise documents a possible request to run a single command outside the sandbox. You can decline and ask the agent to continue within the policy. The ability to bypass is configurable, and managed enterprise rules can limit it. If your task handles production credentials, customer data or other high-impact material, use a tighter environment and human review; do not treat local sandboxing as a substitute for those controls.

A cautious setup for everyday coding

1. Start with a low-risk repository. Read the policy screens before running an agent on code beside sensitive files.
2. Enable the correct product. Set the app’s project default for future local sessions, or separately enable the CLI feature in the CLI session.
3. Remove unnecessary access. Deny unrelated folders and turn off network or credential access the task does not need.
4. Verify the active session. Restart when policy changes require it; in CLI, inspect /sandbox status and /sandbox policy.
5. Review exceptions. Read any request to bypass the boundary as you would a privileged command approval.

This is one layer in a wider secure-development workflow. For a separate example of reducing stored publishing credentials in CI, see our guide to staging npm releases with GitHub Actions. Neither feature removes the need to review what code and automation are allowed to do.

The useful outcome is narrower, visible access—not “agent-proof” development. Enable the product-specific sandbox, tune it to the work, then verify the effective policy before trusting it with anything sensitive.