GitHub Copilot local sandboxing: what it protects

GitHub made local sandboxing for Copilot generally available on October 7, 2026. The release covers Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host. It matters because coding agents increasingly run shell commands, inspect repositories, call local tools and interact with credentials. A model's instruction to 'be careful' is not a permission boundary; the environment that executes its tools needs one.

What changed

Local sandboxing lets a developer or organization restrict the commands and tools Copilot runs on a machine. GitHub uses Microsoft eXecution Container (MXC) to translate a common policy into operating-system controls on supported Windows, macOS and Linux systems. The sandbox can limit file access, network connections and credential availability. Organizations can also require managed policies rather than relying on each developer to remember a safe configuration.

What a local sandbox can restrict

• Filesystem: allow reading or writing only the project paths required for a task; deny unrelated directories.
• Network: constrain internet and local-network access or use host rules where the operating system supports them.
• Credentials: decide whether Git and GitHub CLI credentials are available to the agent's tools.
• Local subprocesses: apply sandbox controls to local MCP and language servers where supported; remote MCP servers are outside that local process sandbox.
• Organization policy: enforce sandbox settings centrally and restrict developer override where the effective policy allows it.

Three caveats that change the security decision

1. Local sandboxing is not a full virtual machine. GitHub describes lighter-weight OS-level containment; it should not be treated as complete isolation from the host.
2. In Copilot CLI, built-in file tools execute inside the CLI process, so the operating-system sandbox cannot intercept those operations. GitHub says these tools check policies themselves on a best-effort basis. Assess this difference when your threat model requires strict enforcement.
3. Enforcement varies by platform and configuration. GitHub documents different requirements and network-control behavior for macOS, Linux and Windows. Unsupported features may fail or require explicit fail-closed policy rather than silently providing equivalent protection.

Local sandbox versus cloud sandbox

These are different risk and cost choices, not interchangeable labels. A local sandbox can reduce accidental access to unrelated host resources while preserving a familiar developer setup. A cloud sandbox can separate the execution environment from the developer's machine, but adds a hosted session, billing and organization-access considerations.

A practical rollout checklist

1. Confirm the Copilot surface and operating system meet the documented local sandbox requirements.
2. In Copilot CLI, run /sandbox enable; in the Copilot app, configure local sandboxing in project settings. These settings are separate across surfaces.
3. Start with the smallest useful read/write directory scope, and deny access to unrelated repositories and private folders.
4. Block network destinations and credentials the task does not need. Test the policy with harmless denied-access attempts before delegating real work.
5. Check local MCP and language-server behavior, platform-specific enforcement limits and any allowed sandbox bypass paths.
6. Keep human review for destructive operations and verify outputs. Reassess whether a cloud sandbox is more appropriate for higher-risk tasks.