GitHub Copilot's App Now Sandboxes Your Files and Network. You Have to Turn It On.

GitHub just gave the Copilot app a safety switch most builders don’t know they need until something goes wrong. It’s called local sandboxing, and it limits what a Copilot agent session can touch on your own computer while it works.

Here’s the part that matters most: it’s off by default.

What local sandboxing actually restricts

When you run an agentic session in the GitHub Copilot app, meaning you let it work through a task on its own instead of approving each edit, it’s working directly on a repository on your own computer (a repository is just the project folder that GitHub tracks changes for). The agent doesn’t just edit code. It can run shell commands, the same typed instructions you’d use in a terminal to install software, move files, or launch a program, read any file it can find, and reach out over the network on your behalf. Without a sandbox, it can generally touch anything your own user account on that computer can touch.

According to GitHub’s changelog post, turning on local sandboxing lets you set boundaries in three places:

• Filesystem: you define folders the agent can read and write to, folders it can only read, and folders it’s denied from entirely.
• Network: you control whether it can reach the open internet and your local network.
• Credentials: you decide whether it gets your saved login for pushing and pulling code to GitHub, and your logged-in GitHub CLI session (a separate tool some builders use to manage GitHub from the terminal instead of the browser).

This is a per-project setting. A sandbox policy you set for one repository doesn’t automatically apply to another.

Why “off by default” is the risk to understand

The failure mode here isn’t exotic. If a Copilot session runs a command it shouldn’t, whether from a bad instruction, a bug, or text it picked up from a file or web page that was crafted to manipulate it, an unsandboxed session can read files well outside your project, hit arbitrary network addresses, or use your stored git and GitHub credentials to push or fetch things you didn’t intend. None of that requires malice on GitHub’s part or a bug in Copilot itself. It’s just what “full access to your machine” means when an AI agent is the one issuing commands.

Sandboxing doesn’t stop every bad instruction. It stops a bad instruction from reaching things like your SSH keys (a saved credential file that lets your computer log into other servers without a password), your unrelated projects, or the rest of your network, by refusing the agent permission to go there in the first place.

There’s a fail-safe detail worth knowing too. If your operating system can’t actually enforce the sandbox policy you’ve configured, GitHub says the sandboxed shell fails with an error instead of quietly running the command without protection. That’s the right default: a session that stops is annoying, but a session that silently drops its safety limits is dangerous.

One scope note: this only covers local sessions working against a repository on your own machine. It doesn’t apply to Copilot’s cloud sandbox sessions or sessions running on a remote host, and it’s a separate setting from Copilot CLI’s own sandboxing. Turning it on in the app doesn’t touch the CLI, and vice versa.

This lands two days after GitHub shipped assisted approvals for Copilot in JetBrains, which let Copilot auto-clear some of its own low-risk actions without naming what counts as low risk. Local sandboxing is the opposite instinct: instead of trusting the agent to judge risk, it takes entire categories of access off the table before the agent can act at all. If you use both features, sandboxing is the one that actually limits how much damage a single bad action can do; assisted approvals just reduces how often you’re asked to sign off.

What builders should do next

Local sandboxing is in public preview, so treat it as something to test before you rely on it. In the Copilot app, open your project’s settings, find the “Sandbox” section, and turn on Sandbox new sessions. That applies to new sessions in that project going forward, not sessions already running. If you want to try it on a session you already have open, type /sandbox on in the chat instead. That flips the current session into sandbox mode without changing the project’s default for next time.

Before you trust it for real work, run one deliberate test. Pick a project you don’t mind experimenting in, turn sandboxing on, and ask Copilot to read a file outside that project’s folder, for example a config file in your home directory or an SSH key folder. Then compare two things: whether the read gets denied outright rather than silently succeeding, and whether your normal, in-scope requests (editing files inside the project, running your usual build or test command) still complete without extra prompts for approval. If the out-of-scope read is blocked and your normal workflow is unaffected, the sandbox is doing its job without getting in your way. If either result surprises you, adjust your folder and network lists before you start relying on it for anything sensitive.

The setting is off by default because GitHub is leaving the tradeoff to you: broader access without configuration, or a few minutes spent defining what your Copilot sessions are actually allowed to touch. For anyone running agentic coding sessions against real projects and real credentials, that’s a few minutes worth spending.

End of article