Copilot's local sandboxing is GA. Here's what it actually restricts

GitHub announced on October 7 that local sandboxing for Copilot is generally available, across the Copilot CLI, the Copilot app and VS Code sessions that use Agent Host. It runs on Windows, macOS and Linux, and it’s included with Copilot at no extra cost . The changelog is short on detail, so the useful part is in the docs.

It’s off by default. Until you turn it on, shell commands Copilot runs can reach whatever your user account can reach .

What you get once it’s on

In the CLI, run /sandbox enable in a session, or start one with copilot --sandbox. The choice is saved as sandbox.enabled in ~/.copilot/settings.json. Sandboxing applies to the current session immediately. Other open sessions need a restart or their own /sandbox enable.

The defaults are deny-by-default for the filesystem:

Writable: the working directory, temp folders, and some package and build caches. In a Git repo, .git is writable, and the rest of the repo is readable but not writable.
Not granted: your home directory.
Network: outbound internet is on, local network access is off.
Credentials: sandboxed tools get placeholder Git and gh credentials. A local proxy swaps in the real ones only for approved HTTPS destinations, and gh credentials work only for github.com, api.github.com and uploads.github.com.

That last one is the clever part. A prompt-injected command that tries to read your token finds a placeholder, and one that tries to send it elsewhere gets nothing useful.

Tightening it

Path rules come in three levels: read/write, read-only and denied. Denied wins over everything, and for overlapping rules the more specific path wins . So a read-only /project/secrets inside a writable /project stays read-only. The docs excerpts I read don’t show the settings-file syntax for rules, so use /sandbox config to set them.

Then check your work before trusting it:

/sandbox policy
/sandbox policy npm install

The first prints the effective paths, network settings and capabilities. The second previews what a specific command would get, without running it. Do this after every rule change. A running process keeps the policy it launched with, so restart dev servers after editing rules.

Teams get the bigger lever. Enterprise-managed settings can require sandboxing, and then /sandbox disable is refused unless the policy allows bypass, and --no-sandbox can’t override it.

Where it doesn’t reach

It isn’t a VM or container. It restricts what a process can read, write and reach, using Seatbelt on macOS, bubblewrap on Linux and the BaseContainer tier on Windows.
Copilot CLI’s built-in file read and edit tools run in-process, so the OS can’t enforce the policy on them. They check it in software, on a best-effort basis. Shell commands and grep/glob run as sandboxed child processes and get real enforcement.
Remote MCP servers run off your machine, so the filesystem policy doesn’t constrain them.
Denied paths that don’t exist get created as directories. A missing .env becomes an empty folder, and it stays there after the process exits. Don’t be surprised when git status shows it.
Tools that use HTTP/2, certificate pinning, client certificates or request signing may fail behind the credential proxy.

Setup has prerequisites on two platforms. Linux needs bwrap 0.5.0 or later and slirp4netns on your PATH. Windows needs a recent Windows 11 build (the docs name specific KB updates), so check the page before rolling it out to a team.

One inconsistency to know about: the GA changelog covers the CLI, but a docs concept page I read still described CLI sandboxing as experimental, needing --experimental. The how-to page didn’t label it. If /sandbox doesn’t appear in your CLI, update it and try again, and run /sandbox status to see whether it’s active.

If you run Copilot’s agent against repos with secrets in them, turn it on, deny the secrets directories explicitly, and read the /sandbox policy output once. Ten minutes, and the worst-case blast radius shrinks to the working directory.