9 min read - GitHub Copilot Local Sandboxing: Test the Policy Before Rollout

GitHub made local sandboxing generally available on 7 October 2026 for Copilot CLI, the GitHub Copilot app and VS Code sessions that use Agent Host. Commands launched by Copilot can now run under policies that restrict file access, network connections, credentials and other system capabilities.

That release gives engineering teams a useful enforcement layer on developer machines. It does not turn every local agent session into an approved environment. GitHub's own documentation describes different defaults by client, settings that apply only to new sessions, operating-system differences and an optional path around the sandbox.

The adoption question for a startup or mid-market team is specific: can you prove the effective policy for the exact client, host and task before the agent touches a real repository? A ten-minute demo cannot answer it. A small acceptance test can.

General availability changes the control available to you

The GitHub release announcement says local sandboxing covers Copilot CLI, the Copilot app and VS Code Agent Host sessions. It also separates model execution from tool isolation: the selected model can change without changing the sandbox policy applied to tools.

Microsoft eXecution Container (MXC) provides the cross-platform layer. Its public repository lists different native backends: ProcessContainer on Windows, Bubblewrap on Linux and Seatbelt on macOS. A shared policy model is helpful, but the host still matters because each backend relies on different operating-system mechanisms.

Treat the product release as permission to run a controlled pilot, not as evidence that a policy has already been chosen. A managed setting can require the sandbox; a local user setting can leave it off. Those states need different approval decisions.

Read the defaults before writing a policy

GitHub's local configuration guide documents several defaults that should appear in a risk review:

The saved settings are not the whole story. App and CLI configuration are separate, and a change does not alter a running session until it restarts. GitHub also says the app's configured-policy summary does not prove that the sandbox is active or display every effective restriction. In the CLI, /sandbox policy shows the combined policy after automatic grants and managed settings are applied.

Write the approval against that effective policy. “Copilot sandbox enabled” is too vague for an engineer to follow or an auditor to reproduce.

Start from the task, then grant access

Suppose a team wants the agent to fix tests and prepare a pull request. This is a hypothetical pilot, not a report of an Exceev or client deployment. The agent needs the repository, the package registry, the test runner and perhaps permission to create a branch. It does not need cloud production credentials, unrelated checkouts, a password manager or the office network.

Turn that task into a short access contract:

• For files, grant read and write access to the disposable checkout. Deny nearby client exports, personal directories, SSH material and cloud CLI configuration. Review automatic developer-tool access because caches and registry configuration can contain tokens.
• For network access, allow only the source host, package registry and any update endpoint the build uses. Keep local-network access off unless the test needs a local service, then name that service and port in the test record.
• Begin without Git and GitHub CLI credentials. Add a task-scoped credential only if branch push or pull-request creation belongs inside the agent session.
• Inventory local MCP and language servers. GitHub's managed settings can require local MCP and LSP processes started by the session to run inside the sandbox; remote MCP servers remain outside that local execution boundary.

This contract will break some convenient workflows. That friction is useful during the pilot because each failure reveals an implicit dependency. Grant the missing capability after reviewing it instead of opening the policy until the build turns green.

Prove the effective policy with harmless probes

Use a disposable repository on one supported operating-system version and one Copilot surface. Put random, non-sensitive markers in four places: an allowed file in the checkout, a denied file outside it, an environment variable standing in for a credential and a local HTTP endpoint. Use a controlled remote endpoint for the egress test; do not send real secrets.

Record the installed client version, host version, policy revision and session identifier. Then run these probes:

1. Read and modify the allowed marker. The test should succeed and produce an expected diff.
2. Try to read and overwrite the denied marker. Both operations should fail without exposing its contents.
3. Request one allowed remote host and one blocked host. Capture the destination, result and policy rule that explains each outcome.
4. Attempt local-network access, Git authentication, gh authentication and a sandbox-bypass request. Each result must match the written contract.
5. Start every approved local MCP or language server, then repeat the relevant file and network probes through that tool.
6. Restart the session and inspect the effective policy again. This confirms that the saved change reached a new session rather than remaining a configuration-screen promise.

A blocked command is only a useful result when the ordinary task still works. Keep a positive control for dependency installation, tests and the intended code edit. Otherwise a broken environment can look secure only because it cannot do anything.

For enterprise-managed deployments, GitHub's managed-settings reference adds two settings worth testing together. enabled: true requires sandboxing by default, while failIfUnavailable: true blocks model and tool execution if the client cannot validate or enforce the policy. allowBypass: false prevents commands and sessions from leaving the sandbox through the normal bypass path. These are controls to evaluate, not a universal configuration prescription.

Test each platform instead of assuming parity

The same policy text can produce different operational behaviour. GitHub's platform prerequisites currently require recent Windows 11 builds for local sandboxing and Bubblewrap plus slirp4netns on Linux. Unsupported denied paths on Windows fail rather than running with weaker access.

Network enforcement has another platform distinction. GitHub's managed network settings documentation says host rules in Copilot CLI prevent direct connections on macOS and Linux. On Windows, those rules depend on programs honouring proxy settings, so they do not provide the same protection against direct connections. That difference belongs in the acceptance result and the residual-risk record.

Do not approve “Windows, macOS and Linux” after testing one laptop. Approve the tested combination of client, client version, host version and policy. Add another combination after it passes the same probes.

Keep repository authorization and review outside the sandbox claim

A sandbox limits what a process can reach. It does not decide what an injected GitHub token may do in an allowed repository, prove that a dependency is trustworthy or make an agent-authored diff correct.

OWASP's Secure Coding with AI cheat sheet advises teams to treat issues, pull requests, comments and repository instructions as untrusted agent input. It also recommends tool allowlists, egress controls, task-scoped credentials and review of every changed file. Its guidance is independent of GitHub and does not certify Copilot's implementation.

Keep three controls beside the sandbox:

• repository rules and a credential that cannot bypass them;
• a full diff review, with named owners for CI, deployment and agent-instruction files;
• logs that connect the source request, effective policy, tool calls, bypass decisions and final commit.

Our Copilot content-exclusion test covers a different boundary: which repository content the assistant may use as context. The secure coding-assistant procurement guide helps compare product-level controls. Neither check replaces runtime containment; the sandbox does not replace them.

Make the rollout decision from evidence

A practical pilot can fit into four stages. First, inventory the intended tasks, clients, host versions, MCP servers and credentials. Next, write the minimum policy and prepare synthetic markers. Run the probes on every supported combination, then let a small engineering group use only the accepted task class. Review blocked operations, bypass requests, unexpected diffs and policy changes before adding users or capabilities.

Proceed when the team can reproduce the effective policy, explain every grant, detect failure to start the sandbox and keep production credentials outside the session. Pause when a required workflow depends on broad local-network access, shared long-lived credentials, unreviewed MCP servers or routine bypass.

The release is useful because it moves local-agent controls closer to the operating system. The rollout still succeeds or fails on the policy you can prove, not the checkbox you can show.

Sources and limitations

We opened and reviewed every source below on 8 October 2026.

• GitHub's 7 October release announcement establishes general availability, covered clients, policy areas, MXC use and the separation between model selection and tool isolation.
• GitHub's local sandbox configuration guide documents prerequisites, client-specific settings, defaults, effective-policy inspection, credential access, bypass behaviour and platform network differences.
• GitHub's enterprise managed-settings reference defines minimum managed restrictions, fail-closed behaviour, bypass control, MCP and LSP settings, credential controls and platform limits.
• Microsoft's MXC repository documents the policy model and native containment backends used across Windows, Linux and macOS.
• OWASP's Secure Coding with AI cheat sheet supplies independent guidance on untrusted repository content, tool access, runtime isolation, credentials and diff review.

We did not test Copilot, MXC or an enterprise policy, inspect GitHub's internal implementation, attempt a sandbox escape or measure developer productivity. Product behaviour, supported hosts and documentation can change after the review date. The probes are a proposed acceptance exercise, not a certification, legal opinion or claim about an Exceev or client environment.