GitHub made local sandboxing generally available on 7 October 2026 for Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host. The release addresses a practical concern for teams adopting coding agents: a useful assistant should not automatically inherit unrestricted access to everything on a developer's laptop.
According to the official GitHub release, local sandboxes restrict tool and command execution through policies governing files, networks, credentials and other system capabilities. GitHub says the capability is included with Copilot at no additional cost. That does not mean Copilot subscriptions or unrelated infrastructure become free.
The boundary is around tools, not intelligence
A coding agent can propose a change in text, but making that change often requires a shell command, file write, network request or another tool. Local sandboxing constrains this execution layer. GitHub explicitly separates model execution from tool isolation: the policy applies to tools regardless of the model Copilot uses.
This matters when a team switches models. A different model should not be treated as justification for broader filesystem or network privileges. Conversely, a sandbox does not demonstrate that generated code is correct, that a dependency is safe or that an answer is factually reliable. Review and tests remain necessary inside the permitted boundary.
What administrators can constrain
The release lists control over readable and writable files and directories; internet and local-network access; Git credentials; and GitHub CLI credentials. It also describes applying sandboxing to local tools and services, including local MCP and language servers where supported.
GitHub says enterprise-managed settings can require sandboxing and impose policies developers cannot weaken. The underlying Microsoft eXecution Container translates a common policy into native operating-system controls across Windows, macOS and Linux. A cross-platform policy is useful, but teams should still test their actual operating systems, tool versions and supported agent surfaces.
For an Indian agency serving multiple clients, the immediate question is whether an agent working in one repository can reach another client's checkout, environment files or local service. Project separation should be explicit rather than assumed from which folder is open in the editor.
A useful pilot includes deliberate denials
Start with a non-production repository containing synthetic credentials. Permit the files and services needed to build and test it. Then define several actions that should fail: reading a sibling directory, writing outside the workspace, contacting an unapproved host and accessing credentials that the task does not require.
Record both successful work and denied operations. If the normal build breaks, identify the narrow missing permission instead of removing the entire boundary. If a forbidden action succeeds, stop the pilot and investigate the policy or unsupported execution path before adding real customer code.
The NVIDIA OpenShell pilot evaluation guide describes a related way to test allowed actions, blocked paths and revocation when assessing an agent runtime. A security feature earns trust through a demonstrated workflow, not through its presence in a settings screen.
Plan exceptions without making them permanent
Dependency installation, internal package registries and local test services can create legitimate exceptions. Specify the required destination or resource, the task it supports and who can authorise the exception. Avoid treating a blocked command as an instruction to grant full network access.
Keep enough policy and session context to explain unexpected behaviour later. Timestamps and activity records help distinguish a policy change from a failed command when reconstructing an event. Sandbox denials can be useful diagnostic evidence, but they should not be described automatically as confirmed attacks.
Work through a blocked dependency request
Hypothetical example: an agency asks an agent to update a form component in a test repository. Reading source files and running an existing unit test are allowed. Downloading a missing package is blocked. The immediate temptation is to enable unrestricted internet access so the task can finish.
A better decision starts by asking whether the new dependency is necessary. If an existing library meets the requirement, keep the boundary unchanged. If the dependency is justified, a maintainer can inspect it and decide whether to allow the specific package source through supported policy controls or prepare the dependency through a separately approved process. This is a proposed operating procedure, not a claim that the sandbox evaluates package trustworthiness.
The same agent may then try to use a GitHub credential to push its change. A task authorised only to prepare a patch does not need push authority. Keep the patch available for human inspection and use the team's normal release route. Successfully generating code is not permission to publish it.
Make rollout evidence portable
- Record the operating system, Copilot surface and effective policy for each test, so a pass on one setup is not assumed to cover another.
- Have a second developer repeat the allowed build and forbidden-access cases from the written procedure.
- After an approved exception, rerun the denial tests to check that unrelated resources remain inaccessible.
- Define a safe fallback: pause agent execution and continue through reviewed manual work rather than disabling isolation to meet a deadline.
This approach separates compatibility problems from security failures. Both need resolution, but they should not trigger the same automatic response of granting broader access.
The release makes controlled autonomy more practical. It does not make unrestricted autonomy sensible. The strongest rollout criterion is straightforward: the agent completes the intended development task while attempts to cross the agreed resource boundary remain blocked.
