GitHub Copilot's Local Sandbox: What It Blocks and What Developers Should Check

AI coding agents write code, run terminal commands, edit files, and call external services. That is useful right up until the agent runs a command you did not intend, or reads something it had no reason to read. The local sandbox restricts the resources those agent-run operations can reach.

It works in four areas. Filesystem: which folders a command can read or write. Network: whether a command can reach the internet, your local network, or specific hosts. Credentials: Git and GitHub CLI tokens, plus any environment variables you choose to mask. Permission requests: what happens when a command needs more access than the policy allows.

The defaults below come from GitHub's documentation for Copilot CLI. Your effective policy can differ by operating system, enterprise policy, and your own settings, so check it with /sandbox policy rather than trusting the defaults table further down.

On Linux, install Bubblewrap and slirp4netns first. Windows and macOS need no extra packages, but Windows must be on a supported build (see the requirements above).

Inside Copilot CLI, run /sandbox enable. The choice is saved as sandbox.enabled in ~/.copilot/settings.json, and the status line shows sandbox enabled. To try it for one session without saving anything, start Copilot with --sandbox. Already-open sessions need a restart (copilot --continue) or their own /sandbox enable.

Sandbox settings live in your personal settings file only. GitHub does not support them in repository-level settings files, so a repo cannot quietly loosen your sandbox. In the Copilot app, the switch is the Sandbox new sessions toggle under Settings > Projects > your project > Sandbox. App and CLI settings are separate.

By default a sandboxed command can write to the current working directory and temp folders. In a Git repository it can also write .git, while the rest of the repo above the working directory is read-only. Your home directory is not granted. Note that /add-dir adds a folder to Copilot's context but does not grant sandbox access to it.

Create a test project and a canary file in your home directory. Start Copilot with --sandbox from inside the test project, then ask it to run: cat ~/sandbox-canary.txt, and then: echo changed > ~/sandbox-canary.txt (on Windows, Get-Content and Set-Content on the same path).

Expected result: both are blocked. Copilot may offer to retry outside the sandbox. Decline for this test. Then, in a normal terminal outside Copilot, check that the file still says original.

In Copilot CLI, outbound internet is allowed by default and local network access is off. Test them as two separate questions.

For local network, start a small web server in a normal terminal, then ask the sandboxed Copilot session to curl it. With the default settings on macOS, the request should fail. Behaviour differs by OS: on Linux, commands can reach servers they start themselves but not your host's localhost, and on Windows the local-network switch also opens private-network access.

For outbound internet, add a host rule on the Network tab of /sandbox config. Once any Allow rule exists, every unmatched host is blocked. Deny beats Allow, and denying example.com also blocks its subdomains. Add an Allow rule for one host, then curl that host and a second one. Only the first should succeed.

Git and gh authentication are on by default. Commands get placeholder credentials, and a local proxy swaps in the real ones only for approved HTTPS destinations. The gh token is delivered only to github.com, api.github.com, and uploads.github.com. Git credentials keep their original host, port, and repository path.

You can mask other variables too. Set a dummy variable before you start Copilot, add it to the sandbox credentials config with the one host allowed to receive it, and restart the session. Inside the sandbox, ask Copilot to echo the variable: it should print a placeholder, not your value.

Then send it in an Authorization header to a header-echo service. The real value should arrive only at the host you listed. Masking works only for HTTPS headers such as Authorization or X-Api-Key, or an HTTP Basic password. Plain HTTP, request bodies, URLs, and signed requests never get the real value.

When a command fails and the failure looks like the sandbox's doing, Copilot can offer to retry it with broader access. You can approve one retry, keep the blocked result, or turn the sandbox off for the rest of the session if policy allows. In the Copilot app, the prompt reads Run outside the sandbox?

Rerun the canary write from Test 1 and look closely at the prompt before answering. The important detail: an approved bypass skips credential masking and the proxy. The command runs with your normal environment, real secrets included. It does not gain admin or root rights, but it gets everything your user account can reach.

On supported Windows hosts the retry is staged. It first relaxes file and process limits while keeping network limits (sandbox relaxed), and only offers a full bypass (sandbox bypassed) if that still fails.

If you would rather blocked commands stay blocked, turn off Allow sandbox bypass on the General tab. Organizations can enforce this with managed sandbox.allowBypass set to false.