Update, October 13, 2026: GitHub made local sandboxing generally available on October 7. Enterprise-managed policies can require it and impose stricter limits.

GitHub added local sandboxing to the Copilot app, but its project setting is off by default. The setting limits what an agent session can touch on your computer.

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. Enterprise-managed settings can require sandboxing and make the effective policy more restrictive.

Why “off by default” is the risk to understand

An unsandboxed session can read files outside your project, reach network addresses, or use stored credentials. A bad instruction, a bug, or manipulative text in a file or web page could prompt it to do so. None of that requires malice on GitHub’s part or a bug in Copilot itself. It is what full access means when an agent issues commands.

Sandboxing restricts access rather than interpreting every instruction. If your policy denies access to SSH keys, unrelated projects or network destinations, agent-run commands cannot use those resources through the sandboxed shell. SSH keys are credentials that let your computer log into other servers without a password.

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.

Local sandboxing covers only sessions working against a repository on your computer. 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.

GitHub also shipped assisted approvals for Copilot in JetBrains. Those decide whether an action needs confirmation. Sandboxing restricts what a command can access when it runs. Approval and containment are separate controls.

What builders should do next

The September 23 launch was a public preview. GitHub made local sandboxing generally available on October 7. 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. Changes to folder, network and credential settings take effect in new or restarted sessions. 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, using a harmless text file you created for this check. Keep that file outside the allowed folders, and never use an SSH key or real credential as the probe.

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 harmless out-of-scope read is blocked and normal work succeeds, those configured boundaries passed this check.

That does not prove every command or network path is contained. If either result surprises you, adjust your folder and network lists before you start relying on it for anything sensitive.

End of article