GitHub Copilot Local Sandboxing: A Safer Setup for Client Projects

By SentrailEditorial standardsPublished October 12, 2026Updated October 12, 2026 7 min read
GitHub CopilotAI agentsClient handoffSecurity

GitHub Copilot local sandboxing can reduce the damage an agent-run command can do on a developer's machine—but only after you enable it, configure the boundary, and test the effective policy. For client work, treat the sandbox as one layer in a handoff process, not as proof that generated code is safe.

GitHub made local sandboxing generally available on October 7, 2026 in Copilot CLI, the GitHub Copilot app, and VS Code sessions using Agent Host. The feature can restrict agent-initiated tools and commands from reading or changing files, reaching networks, or using credentials. It is included with GitHub Copilot at no additional cost.

That is useful for freelancers and small agencies because an AI coding session often sits near other client repositories, local credentials, environment files, and authenticated developer tools. A written sandbox policy makes the intended boundary easier to review than a verbal promise to "be careful."

What local sandboxing protects

GitHub's local sandbox uses operating-system controls through Microsoft eXecution Container (MXC). Depending on the Copilot surface and host operating system, you can control:

  • which paths agent-run commands may read, write, or must not access;
  • outbound internet and local-network access;
  • Git and GitHub CLI credentials;
  • selected environment variables, with real values supplied only to approved HTTPS destinations;
  • whether local MCP and language servers run inside the sandbox; and
  • whether Copilot may ask to retry a command outside the sandbox.

The important phrase is agent-run commands. GitHub documents local sandboxing as lighter-weight isolation, not a separate virtual machine or container. Copilot CLI's built-in file tools also run inside the CLI process rather than inside the operating-system sandbox, so those tools enforce policy in their own code on a best-effort basis. Remote MCP servers are not sandboxed by your local policy.

This means the sandbox can reduce unintended access without turning every AI action into a trusted action.

Start with the boundary, not the toggle

Before enabling anything, write down the smallest access the task actually needs. For a client repository, use five questions:

Dimension Minimum-access question Evidence to retain
Files Which repository and temporary paths must the task read or change? Effective readable, writable, and denied paths
Network Which package registries, APIs, or preview services are required? Allowed hosts and whether local-network access is enabled
Credentials Does the task need Git, gh, or another token at all? Enabled credential types and approved injection hosts
Tools Are local MCP or language servers required? Are any MCP servers remote? Tool list and which processes are actually sandboxed
Exceptions Can a blocked command run outside the sandbox? Bypass setting and any approved exception

Do this per project. The Copilot app and Copilot CLI keep separate local-sandbox configurations; changing one does not change the other. In the app, settings are also project-specific and apply to new or restarted local sessions, not automatically to a session that is already running.

Enable it in the surface you actually use

In an interactive Copilot CLI session, run /sandbox enable. Then run /sandbox status to confirm what the current session is enforcing. /sandbox policy shows the effective filesystem, network, and capability rules; adding a command after it previews the extra developer-tool access that command would receive without executing it.

In the GitHub Copilot app, enable sandboxing for new local sessions in the project's settings. For an active local session, /sandbox on changes the current session. Restart an existing session after changing project policy so the new settings take effect.

Do not record a settings-screen toggle as the whole test. GitHub notes that a configured policy summary does not prove the sandbox is running. The current-session status and effective policy are stronger evidence.

Tighten the policy for client work

GitHub's defaults are designed to support common development tasks, so they may be broader than a specific client task requires. In Copilot CLI, outbound internet and Git/gh authentication are on by default; bypass requests are also enabled by default. The Copilot app similarly enables outbound internet, local network, and Git/gh credentials by default.

For a bounded review or bug fix, consider this starting position:

  1. Give read/write access only to the current repository and necessary temporary paths.
  2. Deny known sensitive sibling folders and credential files.
  3. Turn off local-network access unless the task needs a local development service.
  4. Turn off Git or gh authentication if the task does not need to push or create a pull request.
  5. Allow only the external hosts required for package installation, documentation, or the target API.
  6. Keep sandbox bypass off when the work can be completed without exceptions.

Credential masking is useful, but it is not a general secret vault. GitHub says masking covers the variables you configure plus enabled Git and gh authentication. It does not hide secrets in other environment variables, credential files, or remote MCP authentication. An approved command that runs outside the sandbox also skips credential masking and the sandbox proxy.

If a task truly needs broader access, add one narrow permission and record why. Avoid solving every denial by disabling the sandbox for the rest of the session: that gives later commands the developer account's ordinary access too.

Run a harmless allow-and-deny check

Test both what should work and what should fail before giving an agent a meaningful task. Use dummy data and non-destructive operations.

Check Expected result
Read a harmless file in the client repository Allowed
Create and remove a temporary file in the repository Allowed
Read a dummy file in a denied sibling folder Blocked
Write outside the approved workspace Blocked
Reach one required external host Allowed
Reach an unapproved test destination Blocked
Use Git or gh when credentials are disabled Blocked or unauthenticated
Start a local or remote MCP tool Result matches the documented tool boundary

Capture /sandbox status, the relevant /sandbox policy output, and the result of each check. Do not use a real secret as a test value and do not probe customer systems that are outside the authorized scope.

Platform details matter. GitHub documents different backends and prerequisites for macOS, Linux, and Windows. Network host rules are not enforced identically across all three: on supported Windows configurations, proxy controls can depend on programs honoring proxy settings, while macOS and Linux can restrict direct outbound connections to the proxy. If the host cannot enforce a requested rule, treat that as a failed gate—not a reason to silently run without the boundary.

Know what the sandbox does not prove

A passing sandbox test does not show that:

  • generated code is correct, secure, or appropriate for the client's architecture;
  • application authorization, Supabase RLS, or deployment permissions are correct;
  • dependencies are trustworthy;
  • a remote service used by the agent follows the same policy;
  • a command approved outside the sandbox kept credential or network restrictions; or
  • the final diff matches the client's requirements.

Continue with ordinary review: inspect the diff, run tests, review dependency and configuration changes, and verify the deployed result. Sentrail's guide to security-reviewing code you did not write and its pre-launch security checks cover the controls that sit beyond the local execution boundary. If a task needs Supabase management access, scope that credential separately; a local sandbox does not replace a project-scoped Supabase token.

Put the evidence in the client handoff

A useful handoff note should include:

  • the Copilot surface and operating system used;
  • whether local sandboxing was enabled for the actual session;
  • the effective filesystem, network, credential, and tool boundaries;
  • every bypass or temporary exception;
  • the harmless allow-and-deny results;
  • the final commit or diff reviewed;
  • tests and checks run after the AI session; and
  • remaining limitations or unverified areas.

This record is more defensible than saying the agent was "sandboxed." It shows what boundary was intended, what the host enforced, and where human review still carried the risk.

Sources

Disclosure: This article was prepared with AI assistance and reviewed against the linked primary sources. It does not report a Sentrail scan, customer incident, or independent test of GitHub's sandbox implementation.

← All posts