Copilot local sandboxing GA: verify denials, not just saved settings
If an agent asked to run tests tries to read an unrelated directory, a carefully worded prompt is a weak description of its execution boundary. GitHub announced local sandboxing GA on October 7. Before increasing autonomous work, a team should verify that its chosen execution surface actually enforces the intended restrictions. The useful outcome is an observed permission boundary, accompanied by enough context for another engineer to reproduce it.
Availability and activation are separate checks
The official documentation says local sandboxing is off by default and that CLI and app settings are separate. Changing the CLI preference therefore does not establish the policy used by a new app session. Distinguish local execution from cloud execution as well. This article proposes an operational verification process rather than changing product settings on the reader's behalf. Record the surface and active session before treating a saved preference as evidence.
Use harmless fixtures instead of secrets
Create a team-owned test folder with three harmless files: one in an allowed read path, one in an allowed write path, and one behind the intended access restriction. Check reads and writes in that session against explicit expectations. Do not use production passwords or customer data as fixtures. Keep only filenames and allow/deny outcomes in the log; for an allowed write, inspect the actual change. A command reporting success without the expected file change is incomplete evidence.
Test destinations and tools separately
Use a team-owned test destination to check network access, and inspect each local MCP tool used in the workflow separately. A passed file test does not establish that every connection or tool shares the same boundary. GitHub distinguishes model execution from tool isolation. Changing the model or adding a warning to a prompt cannot replace execution evidence. Avoid assuming that a tool's availability in the interface describes what its subprocess can reach.
Keep exceptions small and reviewable
When a task is denied, document the required path, destination and operation, then compare them with the actual session error. This article recommends reviewing the smallest necessary operation before widening access. There is a tradeoff: denying legitimate build outputs and package access can make repeated exceptions feel routine. Begin with a narrow test task, then retain results before and after policy changes, the execution surface, check time and responsible reviewer. That makes an exception a concrete engineering decision rather than an unexplained workaround.
The first operational question is which action was denied in which session, rather than whether a setting exists. These tests do not prove complete isolation across every OS and tool. Recheck when the host or execution surface changes, and do not describe a local sandbox as a separate virtual machine.
Official sources and verification date
Official announcement and documentation checked on October 11, 2026. The test process and record format are the author's proposals, not automatic product guarantees or measured performance claims.