GitHub Copilot local sandboxing is GA, but network access stays on by default

GitHub announced [general availability for local sandboxing](https://github.blog/changelog/2026‑10‑07‑local‑sandboxing‑for‑github‑copilot‑now‑generally‑available/) in Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host. The feature uses Microsoft eXecution Container to translate a shared policy into native controls on Windows, macOS and Linux. GitHub says it is included with Copilot at no additional cost. The sandbox applies to tools and commands an agent launches. It can restrict filesystem paths, internet and local‑network access, credentials, local MCP servers and language servers. GitHub explicitly separates model execution from tool isolation: choosing another model does not change the sandbox policy. That makes the release an execution‑control change rather than a promise that generated code is safe. Prompt injection, dependency behavior and incorrect edits still need review. The practical benefit is that a mistaken or malicious command can be denied access outside the policy the host actually enforces.

GitHub's [local‑sandbox guide](https://docs.github.com/en/copilot/how‑tos/cloud‑and‑local‑sandboxes/using‑local‑sandboxing) says sandboxed commands can write in the current working directory and temporary folders by default. In a Git repository, Git metadata is also writable, while the repository above the current working directory is readable but not writable. Selected tool locations and caches can be available, but the policy does not grant the full home directory. The working directory therefore matters. Starting an agent at a repository root gives it a broader writable surface than starting inside a smaller project subtree. Additional paths can be granted, but each grant expands the effect of a bad command. Teams should record the launch directory and effective path policy in acceptance evidence. A useful negative test asks the agent to read and then modify a harmless fixture outside the allowed tree. The read and write expectations may differ. Confirm the observed result through `/sandbox policy`, and do not infer containment from a task that simply never attempted the blocked access.

The current CLI defaults allow outbound internet while local‑network access is off. Git and GitHub CLI credentials are available through a proxy for approved destinations unless credential access is disabled. The [configuration reference](https://docs.github.com/en/copilot/how‑tos/cloud‑and‑local‑sandboxes/configuring‑local‑sandbox‑settings) treats internet rules, local network and credentials as separate controls. This means “sandboxed” does not mean “offline.” A package install or API request can still reach allowed internet destinations. Localhost and private‑network services remain a different setting, which matters for development servers, databases and credential brokers. An approved bypass also runs outside credential masking, so its prompt should be reviewed as a real expansion of access. Test each channel independently: one allowed public host, one denied public host, one local service and one authenticated Git read. Keep write operations out of the probe. If the workflow uses an [MCP server](https://opentools.ai/mcp), verify whether it is launched locally and whether its own downstream network calls match the expected policy.

On Linux, GitHub currently requires Bubblewrap 0.5.0 or later and `slirp4netns`. On Windows, the documentation names Windows 11 25H2 with KB5124010 or later, or Windows 11 26H1 with KB5124006 or later, plus BaseContainer support. GitHub's guidance says an unsupported host or policy fails rather than silently running unsandboxed. In CLI, `/sandbox enable` persists the preference for current and future sessions unless policy controls it. Enterprise managed settings can require sandboxing and can prevent ordinary disablement. Existing sessions may need a restart before a saved policy change applies. The Copilot app stores its local setting separately, so changing CLI configuration does not configure the app. Acceptance should record operating‑system version, required helper availability, `/sandbox status`, and the effective policy. A UI toggle alone is weak evidence because support is checked when the first sandboxed shell starts.

A good baseline grants only the project path, required public hosts and the narrow credentials needed for a read or reviewed write. When the sandbox blocks an operation, inspect why before approving a broader retry. The bypass runs with ordinary environment access and may expose values that the sandbox proxy would otherwise mask. For managed teams, require sandboxing first, then test a representative build, package fetch, local server and Git operation. Record every extra path and hostname the workflow needs. That produces a usable policy rather than a blanket allow‑all response to the first failure. GitHub's release expands the places where this control exists; it does not establish that every tool, MCP server or language server is fully contained on every platform. Keep host‑specific negative tests and monitor exceptions. Follow [GitHub's OpenTools organization page](https://opentools.ai/organizations/github) for related releases. *Figure: The separate file, network and credential decisions inside a Copilot local sandbox. Sources: [GitHub's GA announcement](https://github.blog/changelog/2026‑10‑07‑local‑sandboxing‑for‑github‑copilot‑now‑generally‑available/), [sandbox concepts](https://docs.github.com/en/copilot/concepts/security‑governance‑and‑network‑settings/about‑cloud‑and‑local‑sandboxes) and the [local setup guide](https://docs.github.com/en/copilot/how‑tos/cloud‑and‑local‑sandboxes/using‑local‑sandboxing). Figure by OpenTools Team; no third‑party expressive material used.*