Local sandboxing in the GitHub Copilot CLI

There's a moment in every agentic workflow where you pause and think: wait, what exactly is Copilot allowed to touch right now?

For a long time the answer was: pretty much everything under your working directory and whatever shell commands it decides to run to get the job done. That was fine when Copilot was mostly suggesting code. It's a different story when it's running tools, executing scripts, and modifying files on your behalf.

As of June 2026, GitHub has an answer: local sandboxing, now in public preview. It doesn't replace good judgment about what you ask Copilot to do, but it does put a real isolation boundary between the agent's tool execution and the rest of your machine.

Let’s explore this feature…

Why do we need this?

The Copilot CLI has evolved significantly since GA. What started as a smart terminal assistant now has Autopilot mode, /plan, fleet parallelism, rubber duck, and a full agentic harness underneath. When you run Copilot in Autopilot mode on a refactoring task, it will read files, write files, and execute shell commands — potentially dozens of them — without stopping to ask each time.

That's the whole point. But it means the trust surface is no longer "can it read my README." It's "can it reach my ~/.ssh directory, hit external APIs, or run rm -rf on something it misunderstood."

Local sandboxing addresses this by isolating the shell command execution that Copilot initiates on your behalf. The agent still runs on your machine, still has access to the files you give it permission to use, but the sandbox enforces boundaries around what its spawned processes can actually reach.

The underlying technology is Microsoft MXC, the same isolation layer that runs across macOS, Linux, and Windows. This gives you a consistent experience regardless of platform. No Docker required, no VM overhead.

Enabling the sandbox

Inside any active Copilot CLI session, it's a single command:

/sandbox enable

That's it. From that point forward, shell commands that Copilot executes run inside the isolated environment. The setting persists across sessions via settings.json, so you don't have to re-enable it every time.

To disable it again:

/sandbox disable

If you want to check the current state or fine-tune the configuration, just run /sandbox on its own. This opens the interactive configuration interface.

The /sandbox configuration interface

Running /sandbox drops you into a three-tab TUI. Use Tab to switch between tabs, Esc to save and close.

General tab

This is the top-level on/off switch and the place to configure general sandbox behaviour. The Sandboxing enabled toggle here is exactly what /sandbox enable and /sandbox disable control. You can flip it from the config interface too.

Notice that you can decide if the MCP servers and LSP servers should also run in the same sandbox.

Use the arrow keys to navigate between settings and hit enter to change a setting.

Filesystem tab

By default, the sandbox restricts filesystem access: processes spawned by Copilot can't freely read or write outside your project directory. The Filesystem tab lets you add explicit path rules to extend that boundary where needed.

Key bindings in this tab:

Key	Action
A	Add a new path rule
Enter	Edit an existing path rule
D	Delete a path rule

When adding a rule, you specify the file or directory path and the permission level — read-only or read/write. This is useful for giving Copilot access to shared tooling or config outside the repo, without opening up your entire home directory.

Network tab

By default, the sandbox restricts outbound network connections. The Network tab lets you define per-host allow/block rules.

Same key bindings as Filesystem:

Key	Action
A	Add a new host rule
Enter	Edit an existing host rule
D	Delete a host rule

For each host you add, you set whether to allow or block access. This gives you a whitelist-style model: block everything by default, explicitly allow the registries or APIs your workflow actually needs.

Remark: At the moment, the Windows sandbox cannot block or allow specific hosts.

Where settings live

All sandbox configuration is stored in settings.json under the sandbox key in your Copilot CLI configuration directory. On most systems that's ~/.copilot/settings.json. You can set a different location via the COPILOT_HOME environment variable.

The structure looks roughly like this:

{
  "sandbox": {
    "enabled": true,
    "addCurrentWorkingDirectory": true,
    "sandboxMcpServers": true,
    "sandboxLspServers": true,
    "userPolicy": {
      "filesystem": {
        "readwritePaths": [],
        "readonlyPaths": [
          "C:\\Users\\user\\.nuget\\packages"
        ],
        "deniedPaths": [],
        "clearPolicyOnExit": true
      },
      "network": {
        "allowOutbound": true,
        "allowLocalNetwork": false,
        "allowedHosts": [
          "api.nuget.org",
          "registry.npmjs.org"
        ],
        "blockedHosts": []
      }
    }
  }
}

You can edit this file directly if you prefer, rather than going through the TUI each time. Useful for scripting a baseline config across machines or committing a team-level starting point.

 

Remark: If you're running Copilot in an org context, there's an enterprise-grade layer on top of this: local sandbox policies can be centrally configured and enforced via Microsoft Intune and other MDM platforms. This means administrators can lock down what Copilot's processes can touch on managed devices, without relying on individual developers to configure it themselves.

Each session inherits the org's sandbox policy, so the security controls you've already defined in your Intune baseline apply to Copilot execution on day one.

Conclusion

If you're using Autopilot mode or letting Copilot run multi-step tasks with shell access, enabling the local sandbox should be your default posture. It's one command, it persists, and it gives you configurable control over what the agent's processes can actually reach on your system.

The fact that it's built on MXC — rather than requiring Docker or WSL or any container runtime — means there's genuinely no excuse not to have it on. It costs you nothing and it draws a real line around what Copilot can touch.

/sandbox enable

Run that now, then tune the filesystem and network rules to match what your workflow actually needs. Future you will thank present you the first time Autopilot goes rogue on a find | xargs rm command.

More information

About cloud and local sandboxes for GitHub Copilot - GitHub Docs