Coding · Source-backed update

Copilot local sandboxing is GA and off by default

General availability adds a supported execution boundary. You still need to establish which policy is actually active in the surface you use.

Edited by Clinton FeyisitanEvent Published

Review scope: The GA announcement and current sandbox documentation.

What became generally available

GitHub’s 7 October announcement makes local sandboxing generally available in Copilot CLI, the Copilot app and VS Code sessions using Agent Host. Tool and command access can be limited by developer or organization policies covering files, network, credentials and other capabilities.

The default and the boundary matter

The current sandbox documentation says local sandboxing is off by default, and CLI and app settings are configured independently. Enabling one does not enable the other. Local sandboxing has no additional sandbox charge; the separate cloud sandbox is usage-billed and in public preview.

GitHub describes local isolation as OS-level process and filesystem containment, rather than a separate VM or container. It also distinguishes shell commands from built-in file tools: those in-process tools enforce the policy in their own code on a best-effort basis. Remote MCP servers are outside the local sandbox.

A file-access trial with a result you can inspect

A useful first check should make the expected permission boundary explicit. The following fixture design is proposed; it has not been run in Copilot by Fewertools.

  1. Prepare disposable evidence. Create a scratch project, one output folder intended to be writable and a second disposable fixture outside the permitted area. Use invented text only. Record their starting contents and paths.
  2. Capture the effective configuration. Note the operating system, client version, active surface and policy shown by that client. Record any organization requirement or per-command exception that changes the boundary.
  3. Separate the access paths. Request a harmless write inside the allowed output folder. Then test access to the outside fixture through a shell command and through the client’s built-in file tool as distinct cases.
  4. Compare the artifacts. Retain the permission prompt, tool result and actual before/after file state for each case. A denied command message and an unchanged file are separate observations worth preserving.

Record a bypass request as a bypass request, rather than treating an approved exception as proof of containment. Stop the trial if the configured boundary is unclear. This is a narrow permission check, not a penetration test or a guarantee about every tool an agent can call.

Keep model hosting separate

Where a model receives prompts is another question. A restricted local command does not by itself tell you where inference runs. Our local model discovery report covers provider selection and offline mode. The Copilot profile holds the wider product record. No sandbox setting or account policy was changed for this source-based report.

Sources and scope

Official sources read 10 October 2026. Facts above are attributed to the provider; the evaluation worksheets are proposed checks. This article does not report a native product test or assign a tool score.

More dated tool changes · How Fewertools records evidence