Local sandboxing for GitHub Copilot went generally available on 7 October in the Copilot CLI, the Copilot app and VS Code sessions that use Agent Host, at no extra cost. It wraps the shell commands the agent runs in a boundary the operating system enforces, and enterprise settings can make it mandatory.
GitHub's own docs say the CLI process is not inside that boundary. The built-in file tools run in-process, so the operating system never sees what they read or write, and they check the policy themselves on a "best-effort basis."
It is off by default. On a machine that can't enforce it, a server-managed requirement is declined and commands run without a sandbox, unless you also set sandbox.failIfUnavailable.
What shipped
The GA post describes a secure execution boundary on the developer's own machine. Copilot-initiated commands run with restricted access to the filesystem, the network and credentials, according to a policy the developer or the organization sets. Microsoft eXecution Container, or MXC, maps one policy onto the native isolation on each OS: Seatbelt on macOS, bubblewrap on Linux, a process container on recent Windows 11 builds.
The policy has four parts. Filesystem rules say which paths are read/write, read-only or denied. Network rules say whether outbound internet and the local network are reachable, with host allow and deny rules on top. Credential rules decide whether git and the GitHub CLI can authenticate from inside the sandbox. Sandboxed tools get placeholder tokens, and a local proxy swaps in the real credential only for approved HTTPS destinations. Local MCP servers and language servers run inside the sandbox too, by default.
Copilot CLI 1.0.93 shipped the same day with one line in the changelog: command sandboxing is available to all users via /sandbox and --sandbox. The word in that line is command.
The boundary is around the shell, not the agent
Every sandboxed shell command gets its own process-scoped profile. When Copilot runs npm install, rm, curl or a test suite, the kernel holds the line. A denied path stays denied no matter what the command tries.
The agent's own tools are a different story. Reading a file, searching the tree, editing a file: those happen inside the CLI process, and the CLI process is not sandboxed. GitHub's concept page says the OS sandbox cannot see or constrain those operations, so the tools apply the policy to themselves, on a best-effort basis. The same denied path that stops a shell command cold stops the edit tool only if the tool's own check catches it.
There is a smaller detail from the 4 September CLI release that shows how the two halves relate. Sandboxed file tools now read the same developer-tool paths as sandboxed shell commands, including token-bearing registry config such as ~/.npmrc. That grant comes from the dev tool access setting, which is on by default. The policy extends reach over token-bearing files to the tools that sit outside the kernel's enforcement.
Remote MCP servers are never sandboxed. Nothing in this release touches them.
None of this is a GitHub quirk. Claude Code's sandbox page says the same thing in one sentence: the sandbox covers shell commands only, and the file tools, MCP servers and hooks run outside it. It is also off by default, and on native Windows it does nothing at all. This is the shape of the product category. The vendors say so in their docs, and the launch posts talk about a secure boundary on your machine. Both are true. The boundary is around the shell.
What the defaults let through
Turn it on in the CLI and this is the effective policy before you change anything. Outbound internet is allowed. The local network is blocked. There are no host rules. Git and gh authentication are on, through the proxy. Dev tool access is on, so the sandbox can read tool configs and caches. Bypass is allowed. In the Copilot app the defaults are looser: outbound internet on, local network on, both credential types on.
Since CLI 1.0.92 on 5 October, sandboxed shells withhold an ambient GITHUB_TOKEN unless you configure it, which closes one obvious leak. What remains is an agent whose shell can reach any host on the internet, authenticated to GitHub, with read access to your working tree and your package registry config. What it can't do is write outside the working directory and the shared build caches, read a path you denied, or reach services on localhost.
When the proxy blocks a destination, the sandboxed command offers a bypass prompt. With sandbox.allowBypass at its default of on, one approval runs that command outside the sandbox. Enterprise settings can turn bypass off, and that is the setting to look at first if you are rolling this out.
When the host can't enforce it
Windows needs Windows 11 25H2 with KB5124010 or later, or 26H1 with KB5124006 or later. Linux needs bubblewrap 0.5.0 or later and slirp4netns on PATH. macOS 15 is the tested floor.
On a host that doesn't qualify, the CLI turns a saved sandboxing preference off for the session, prints a notice that commands will run without a sandbox, and refuses /sandbox enable. If your organization requires sandboxing through server-managed settings, that request is declined on an unsupported host unless sandbox.failIfUnavailable is true. With both set, the CLI blocks model requests and tool execution for the session rather than running open. Settings delivered by MDM or a managed settings file behave differently: they can require sandboxing even on unsupported hosts, and commands fail instead of running unsandboxed.
So a "require sandboxing" policy pushed from the server is a request an unpatched Windows laptop can decline. If you want the fail-closed behavior, you set it yourself.
Windows has a second gap even when it qualifies. Network rules there depend on programs honoring the proxy settings. A program that ignores them connects directly. On macOS and Linux the sandbox restricts outbound connections to the proxy, so that route is closed.
What to do with this
Turn it on. The CLI and the app are configured separately, so do both. Add host allow rules for the registries and APIs your builds need, because once one allow rule exists every unmatched host is blocked, and that is the posture you want.
If you require it through managed settings, set sandbox.failIfUnavailable to true and sandbox.allowBypass to false. Without the first, an unsupported host runs open. Without the second, a blocked command is one approval away from running outside the sandbox.
Treat the file tools as governed by the policy check inside the agent, not by the kernel. Keep real secrets outside the working tree and in denied paths, and set sandbox.allowDevToolAccess to false if the token-bearing config files in your home directory matter more than cache speed.
Remote MCP servers get nothing from any of this. Govern them where they run.
The GA post says sandbox policies apply regardless of which model Copilot uses. That is correct, and it is also the whole scope: any model, shell commands only. The tool that rewrites your files is the one you were worried about, and it is standing next to the fence.