--- title: "Copilot Local Sandboxing Is GA: What It Limits and a 5-Step Check" description: "GitHub made Copilot local sandboxing GA on Oct 7, 2026, at no extra cost. What it restricts, where it runs, how admins enforce it, plus a 5-step check." url: https://cdnping.org/en/blog/github-copilot-local-sandboxing-ga language: en published: 2026-10-18 category: "Developer tools" tags: ["GitHub Copilot","sandboxing","AI agents","developer security","MXC"] source: cdnping.org license: Free to quote and summarize with a link to the url above. --- # Copilot Local Sandboxing Is GA: What It Limits and a 5-Step Check On October 7, 2026, GitHub announced that local sandboxing for Copilot is generally available (GA). In short: the tools and commands that a Copilot agent runs on your machine can now be confined to a boundary defined by policy. Which files they can reach, whether they can use the network, and whether they can use your Git credentials are all set by you or your organization. GitHub says the feature is included in GitHub Copilot at no additional cost. This article covers what the Copilot sandbox actually restricts, where you can use it, how enterprises manage it, and a self-check to run after you turn it on. Everything below reflects GitHub's official announcement as of October 2026. ## What is the Copilot sandbox, and where does it work? According to [GitHub's announcement](https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/), local sandboxing is currently available in three places: - GitHub Copilot CLI - GitHub Copilot app - VS Code sessions that use Agent Host The underlying technology is Microsoft eXecution Container (MXC). It maps one common sandbox policy onto the native OS controls of Windows, macOS, and Linux, so the same policy works across platforms. The MXC project is [public on GitHub](https://github.com/microsoft/mxc); for implementation details, defer to the project and the official docs. One point is easy to mix up: the sandbox isolates tool execution, not the model itself. The announcement states that the sandbox policy applies to tool execution regardless of which model Copilot uses. ## Why do agents need a sandbox? Unlike autocomplete, an agent decides for itself which commands to run. There are three common worries. These are general risks of how agents work, not cases cited in the announcement: - Command mistakes, such as bulk-deleting or overwriting files in the wrong directory. - Reading things it shouldn't, such as environment variables, key files, or Git credentials. - Sending requests to addresses it shouldn't, carrying code or data out with them. Guarding against these by confirming every command wears people down over time. A sandbox takes a different approach: draw the boundary first, let actions inside it proceed without repeated prompts, and block anything that crosses it. ## What exactly can it restrict? The announcement lists the following capabilities: | Control target | Description | |---|---| | Files and directories | Limits which paths the agent's commands can read or modify | | Network | Controls internet and local network access | | Credentials | Controls access to Git credentials and GitHub CLI credentials | | Local tools and services | Where supported, also applies to local MCP servers and language servers | Note the phrase "where supported": whether a given tool can be brought under the sandbox depends on the official docs. The conceptual documentation is here: [About cloud and local sandboxes for GitHub Copilot](https://docs.github.com/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes). ## How do enterprises and teams manage it? The announcement makes two points. Enterprises can require sandboxing through enterprise-managed settings, and organizations can push policies that developers cannot loosen. If you are an admin, confirm the exact location and fields of the managed settings in the official docs first rather than configuring from memory. ## How do you check it after turning it on? (5 steps) Exact switch and setting names are in the official docs. The checks below are the approach to follow: 1. **Confirm it is active in each entry point.** Verify the sandbox is on in Copilot CLI, the Copilot app, and VS Code Agent Host sessions. The three are independent, so don't check just one. 2. **Tighten the file scope.** Allow only the current project directory, not your entire home directory. `~/.ssh`, cloud provider credential directories, and browser profile directories should not be readable by default. 3. **Restrict the network by default.** Start with nothing allowed. When the agent is actually blocked while fetching dependencies, allow items one at a time at the granularity the official docs support, instead of opening everything up front. 4. **Grant credentials only as needed.** Allow Git and GitHub CLI credentials only for tasks that really need to push or call the API. 5. **Run an out-of-bounds test.** In a test repository, have the agent read a file outside the allowed scope and reach an address you haven't allowed. Confirm both are blocked, and check whether the logs or prompts make that clear. This step tells you whether your policy is enforced or only exists on paper. ## Do other tools do something similar? Yes. Many agent tools offer some form of permissions, sandboxing, or hooks. For example, Codex has its own sandbox settings, and Claude Code has permission rules and hooks. Names, defaults, and capabilities differ quite a bit. I did not verify each one here, so rely on each vendor's official docs and don't carry Copilot's policy over as-is. The [Copilot weekly release notes](https://github.blog/changelog/2026-10-09-github-copilot-weekly-releases-october-5/) from the same week also mention that `/model` in Copilot CLI can now list models from an Ollama instance running on your machine. That is a separate matter from the sandbox, but worth reading alongside it: even with a local model, tool execution still needs a boundary. ## What the sandbox does not solve A sandbox governs what commands can touch, not whether the code is correct. If the agent writes vulnerable code inside an allowed directory or breaks your tests, the sandbox won't stop it. Code review and testing are still necessary. Also, the more permissions you allow, the less the sandbox does, so review your policy periodically. ## Related reading and tools - To see whether Copilot is currently up, check cdnping's [Copilot status page](/en/down/copilot). Official updates are in [Service changes](/en/changes). - Recent Copilot changes: [What GitHub Copilot HydraFusion and the new Max option are](/en/blog/github-copilot-hydrafusion-max), and [GitHub Copilot retires three models on November 16](/en/blog/github-copilot-model-deprecation-nov-16). - If your agent calls third-party APIs, also read [How to judge AI API data privacy](/en/blog/ai-api-data-privacy-policy) and [Is a Claude API relay safe?](/en/blog/is-claude-api-relay-safe) to understand the risks once data leaves your machine. (Relays are third-party gateways, common in China, that resell access to model APIs.) - When a tool can't connect, the layered approach in [Troubleshooting Claude Code connection timeouts and errors](/en/blog/claude-code-connection-troubleshooting) can help. ## Sources - [Local sandboxing for GitHub Copilot now generally available (GitHub Changelog, 2026-10-07)](https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/) - [GitHub Copilot weekly releases: October 5 (GitHub Changelog)](https://github.blog/changelog/2026-10-09-github-copilot-weekly-releases-october-5/) - [About cloud and local sandboxes for GitHub Copilot (GitHub Docs)](https://docs.github.com/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes) - [microsoft/mxc (GitHub)](https://github.com/microsoft/mxc)