GitHub Copilot Local Sandboxing Is GA: Defaults, Limits and Team Rollout

On October 7, 2026, GitHub made local sandboxing generally available across Copilot CLI, the Copilot app and VS Code sessions using Agent Host. The release gives developers and platform teams policy controls for agent-run tools on their own machines. Those controls apply independently of the model selected in Copilot.

Teams can use local sandboxing to restrict access to files, networks and credentials before granting coding agents more autonomy. Our recommendation: start with scoped edits, builds and tests in a known repository, then expand permissions only when the workflow needs them.

GA does not mean enabled by default. GitHub says local sandboxing remains off until enabled or required by policy. The Copilot CLI 1.0.93 release notes confirm general access to command sandboxing; that is an availability milestone, not evidence that every control is new.

What the local boundary covers

GitHub describes the MXC-backed implementation as operating-system process containment, not a separate VM or container. It limits what supported operations can access on the execution machine. If a task requires stronger separation from the host, evaluate a separately isolated environment against that requirement.

The enforcement path matters. In the CLI, shell commands and searches run as restricted subprocesses; local MCP and language-server processes do so by default. Built-in file reads and edits instead check policy inside the unsandboxed CLI process, without an OS backstop. Remote MCP servers are outside the local process boundary. These distinctions are explicit in GitHub’s filesystem-policy guide.

The default CLI workspace is broader than one folder’s contents: the working directory and Git metadata are writable, while the enclosing repository is readable. Developer-tool grants can expose registry configuration containing tokens and make selected shared caches writable. A repository subdirectory is therefore not a confidentiality boundary. Review automatic grants as well as custom path rules.

Check the client before copying a policy

The VS Code guide still marks Windows support Experimental and managed sandbox enforcement Preview. For connected remote Agent Host sessions, the relevant OS, paths and dependencies belong to the remote execution host, not the laptop displaying the session.

Use the matching client prerequisites: GitHub’s CLI/app instructions and VS Code’s Agent Host guide list different Windows updates and Linux dependencies. The GA announcement does not establish one universal Windows minimum for all clients.

Review network reach and credentials together

GitHub’s network configuration documentation describes a consequential platform difference. On macOS and Linux, host filtering forces connections through the local proxy. On Windows, it depends on programs honoring proxy settings; direct connections can evade those host rules. Linux subprocesses cannot directly reach the host’s localhost, although eligible proxy-mediated requests can. Do not treat identical settings as identical enforcement.

The CLI credential documentation says commands receive placeholder Git/gh credentials, with real credentials substituted by a proxy for approved HTTPS destinations. On Windows, that path requires supported host-loopback access and enabling local networking, which also permits private-network access.

Protecting a credential’s value does not remove the authority it grants. A build may still use authenticated operations or readable registry configuration. For dependency installation, review package sources, cache writes and account permissions together; for offline edits, remove unnecessary network and authentication grants.

Resource containment also does not authorize a consequential action. VS Code distinguishes sandboxing from approvals: a reachable service may accept writes as well as reads. Keep decisions about pushing code, merging changes or deploying separate from the decision to permit a connection.

Make mandatory enforcement explicit

A saved enablement preference is not proof of protection. GitHub says an unsupported CLI host can disable an ordinary user preference for the current session with a notice. Administrators requiring containment should review three separate managed controls:

• sandbox.enabled: true requires sandboxing rather than leaving it as a user preference.

• sandbox.failIfUnavailable: true, together with enablement, blocks model and tool execution when the policy cannot be enforced.

• sandbox.allowBypass: false prevents individual-command bypass and session-wide opt-outs.

These are documented enterprise settings, not interchangeable switches. Enabling sandboxing alone can still leave session exceptions available when bypass is permitted. The following is a managed-settings fragment to review, not a complete filesystem, network or credential policy:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowBypass": false
  }
}

Check every intended client version and effective policy. GitHub’s managed-settings reference places VS Code Agent Host support at 1.138.0+, with session-toggle protection added in 1.140.0. It also documents Windows learning mode: "allow" records but permits filesystem/process access that would otherwise be blocked. It is not normal enforcement.

The rollout implication is straightforward: decide what happens when enforcement is unavailable and who, if anyone, can approve an exception before granting unattended execution. A locked toggle alone does not answer either question.

A practical adoption sequence

• Known repository, bounded edits: begin with only the required writable paths. Keep changes as reviewable diffs before merge or deployment.

• Builds and dependency restoration: inventory registries, local services, package credentials and shared caches. If the required grants are too broad for the code’s trust level, change the environment rather than approving every blocked operation.

• Unattended work: require a supported host and verified managed-policy receipt. Define an owner for failures and exceptions before increasing autonomy.

• Hostile code or stronger isolation needs: evaluate a separately governed VM, container or remote environment. Moving execution elsewhere still requires decisions about credentials, network access and external actions.

For a CLI pilot, use these documented inspection commands after enablement:

/sandbox status
/sandbox policy
/sandbox policy npm install

The last command previews access for npm install; it does not install packages. Treat the report as configuration evidence, then validate the permitted and denied operations your rollout depends on. These are proposed checks, not tests performed for this article.

In the app, filesystem, network and credential changes need a new or restarted session. A saved settings summary is not confirmation that the running session uses those restrictions.

For workflows that also drive browsers or desktops, see our Claude SDK toolsets guide for the related distinction between SDK checks, runtime restrictions and action approvals.

Cost and reporting basis

Local sandboxing adds no sandbox charge to a standard Copilot seat. Cloud sandboxing is a separate usage-metered product, so do not apply its compute, allocated-memory or snapshot charges to local sessions. See GitHub’s sandbox billing documentation.

Methodology: AI-assisted reporting and decision analysis based on GitHub and VS Code primary sources, rechecked on October 7, 2026. No hands-on security, compatibility or performance tests were performed. Recommendations interpret documented behavior; they are not a security certification.