GitHub Copilot CLI can help developers investigate code, fix bugs, run tests, install dependencies, and automate development tasks directly from a terminal. These capabilities make it useful for working on large projects, but they also introduce a security concern: an AI agent can execute commands on your computer.
Consider a simple request such as:
Find the cause of the failing tests,
fix the problem, and run the test suite again.
To complete this task, Copilot may inspect source files, modify code, execute dotnet test, and run additional commands. Some commands may also access the internet, read configuration files, or modify files outside the intended project.
Running an agent with unrestricted access increases the potential impact of an incorrect command or an unexpected instruction.
GitHub addresses this problem with local sandboxing for Copilot CLI. It provides an operating-system-level security boundary that restricts which files, network resources, and credentials agent-run commands can access.
Local sandboxing became generally available across supported GitHub Copilot surfaces in October 2026. This article explains how to enable it in Copilot CLI, configure filesystem and network permissions, inspect the effective security policy, and run development commands with fewer risks.
What Is Local Sandboxing in GitHub Copilot CLI?
Local sandboxing runs most commands and tools initiated by Copilot inside a restricted environment on your computer.
Instead of allowing every command to use the full permissions of your user account, the sandbox applies rules that control access to specific resources.
These restrictions cover several areas:
Security area | What it controls |
|---|
Filesystem | Which files and directories commands can read or modify |
Network | Which external hosts and local network resources commands can reach |
Credentials | Access to Git and GitHub CLI authentication |
MCP servers | Execution and network access for supported local MCP servers |
Language servers | Access available to supported local language servers |
For example, suppose you open Copilot CLI inside a .NET project.
The agent may need to read source files, modify application code, restore NuGet packages, and run tests. It does not normally need permission to modify your SSH configuration, access unrelated projects, or read private files elsewhere on your computer.
Local sandboxing helps enforce these boundaries.
GitHub uses Microsoft eXecution Container (MXC) to translate sandbox policies into operating-system controls across supported platforms.
The model and the execution environment are separate concerns. Changing the AI model does not remove the restrictions applied to commands running inside the sandbox.
Check the System Requirements
Local sandboxing has different operating-system requirements.
Operating system | Requirement |
|---|
macOS | Supported macOS environment with the required sandbox support |
Linux | Bubblewrap version 0.5.0 or later and slirp4netns |
Windows | Windows 11 version 25H2 with update KB5124010 or later, or Windows 11 version 26H1 with update KB5124006 or later, with BaseContainer support |
On Linux, verify that the required tools are installed:
bwrap --version
Check slirp4netns:
slirp4netns --version
If either command is unavailable, install the missing dependency using your Linux distribution's package manager.
For example, on Ubuntu:
sudo apt update
sudo apt install bubblewrap slirp4netns
The exact package versions depend on the distribution. Confirm that the installed Bubblewrap version meets the minimum requirement.
On Windows, verify the Windows version and required update before enabling sandboxing. The feature depends on operating-system support, not just the Copilot CLI version.
If the operating system cannot enforce the requested sandbox policy, Copilot should fail the sandboxed operation rather than silently running it without protection.
Enable Local Sandboxing in Copilot CLI
Local sandboxing is disabled by default unless an organization has configured a managed policy.
You can enable it directly from an interactive Copilot CLI session.
Step 1: Start Copilot CLI
Open a terminal in your development project and start Copilot:
copilot
For example, navigate to an ASP.NET Core application:
cd ~/projects/OrderManagement
copilot
Copilot starts an interactive session in the current working directory.
The directory matters because the sandbox determines its default project access based partly on where the session starts.
Step 2: Enable sandboxing
Inside the Copilot CLI session, run:
/sandbox enable
Sandboxing starts immediately for the current session.
The setting is also saved for future Copilot CLI sessions unless you change it or an organization-managed policy controls it.
If you already have other Copilot sessions open, enabling sandboxing in one session does not automatically update those existing sessions. Enable it separately in each active session or restart them.
Step 3: Verify the current status
Run:
/sandbox status
Copilot reports whether local sandboxing is active.
This is important because a saved preference does not always describe the effective security state of an already-running session.
For example, an organization may require sandboxing through managed settings. In that case, the CLI reports the enforced state.
Do not assume that a session is protected simply because you enabled sandboxing in an earlier session.
Understand Filesystem Permissions
The filesystem policy determines which directories Copilot can read, modify, or access.
The sandbox uses three permission levels.
Permission | Meaning |
|---|
Read/write | Commands can read and modify files |
Read-only | Commands can inspect files but cannot modify them |
Denied | Commands cannot read or modify the specified path |
The default behavior depends on the current working directory.
When you start Copilot inside a Git repository:
The current working directory is writable.
Temporary directories required by commands can be writable.
Git metadata is writable.
Other parts of the repository are generally readable but not writable.
Unapproved locations outside the repository are restricted.
For example, consider this project:
OrderManagement/
│
├── src/
│ ├── Api/
│ └── Services/
│
├── tests/
│ └── Api.Tests/
│
├── .git/
└── README.md
If Copilot starts inside OrderManagement/src/Api, it can work in that directory while reading the rest of the repository.
It should not automatically receive write access to every directory on your computer.
This behavior is useful when working on a specific application component, but it also means that the directory from which you start Copilot affects the available permissions.
Configure the Sandbox Settings
The /sandbox command opens an interactive configuration interface.
Run:
/sandbox
The configuration interface contains four main sections:
General
Credentials
Filesystem
Network
Use the Tab key to move between sections. Press Esc to save changes and close the interface.
General settings
The General section controls whether sandboxing is enabled and how the agent handles restricted commands.
Important options include:
Enable sandbox: Runs supported commands inside the sandbox.
Allow sandbox bypass: Allows Copilot to request approval for a command that needs broader access.
Sandbox MCP servers: Runs supported local MCP servers inside the sandbox.
Sandbox LSP servers: Runs supported language servers inside the sandbox.
For a development environment containing sensitive files, consider disabling sandbox bypass unless the team has a clear reason to allow it.
With bypass disabled, a command blocked by the sandbox remains blocked. Copilot must use another approach or request that you adjust the configuration.
Filesystem settings
The Filesystem section allows you to add directories with different permission levels.
For example, a .NET project may need read-only access to a shared configuration directory.
You can add its absolute path and select Read-Only.
On macOS or Linux, a path might look like:
/Users/developer/shared-config
On Windows:
C:\Users\developer\shared-config
The available permission choices are:
Read/Write
Read-Only
Denied
Adding a directory grants access to its entire subtree. Wildcards are not supported.
Use Denied for sensitive locations that must remain inaccessible even when a broader directory has been granted access.
Credentials settings
The Credentials section controls access to authentication information used by tools.
For example, Git commands may require authenticated HTTPS access, while GitHub CLI commands may use the credentials managed by gh.
Restrict these credentials when the task does not require them.
A build or test task usually does not need GitHub authentication. A task that creates a pull request does.
Avoid exposing personal access tokens through environment variables or command-line arguments when a supported credential integration is available.
Network settings
The Network section controls outbound internet and local network access.
A developer may need internet access to restore NuGet packages, but the agent does not necessarily need access to every external host.
Configure network access according to the tools used by the project.
For example, an application may need access to:
api.nuget.org
A team using an internal package feed may also need to allow its approved package server.
Restrict access to unnecessary destinations, particularly internal systems containing sensitive information.
Inspect the Effective Sandbox Policy
One of the most useful features in Copilot CLI is the ability to inspect the permissions that actually apply to the current session.
Run:
/sandbox policy
Copilot displays the effective policy, including filesystem access, network settings, and available capabilities.
This is more useful than looking only at saved configuration because the effective policy also considers automatic permissions and organization-managed restrictions.
You can also inspect the permissions required by a particular command without executing it.
For example:
/sandbox policy dotnet restore
This previews the access that dotnet restore would receive.
It does not run the restore operation.
Similarly, you can inspect the permissions for a test command:
/sandbox policy dotnet test
This helps identify missing directory or package-cache permissions before running a potentially expensive operation.
Pay attention to the following details:
Which directories are writable?
Which locations are read-only?
Are sensitive paths explicitly denied?
Can the command access the required package registries?
Is sandbox bypass enabled?
Are local MCP servers and language servers sandboxed?
The policy report should be part of the initial setup process for repositories that contain sensitive information.
Run a .NET Project Safely
Let's use a practical example.
Assume you are working on an ASP.NET Core application and want Copilot to inspect the code, restore dependencies, and run tests.
Start by opening the project:
cd ~/projects/OrderManagement
Launch Copilot CLI:
copilot
Enable sandboxing:
/sandbox enable
Verify the policy:
/sandbox status
/sandbox policy
Now ask Copilot to inspect the project:
Inspect the OrderManagement solution.
Identify the API projects, service classes,
and test projects.
Do not modify any files.
Do not access directories outside
the current repository.
After reviewing the project, ask Copilot to run the build:
Restore and build the solution.
Use the existing project configuration.
Do not change package versions
or modify project files.
Report any build errors.
The agent may execute commands such as:
dotnet restore
dotnet build --no-restore
Next, run the tests:
Run the existing test suite.
Do not modify test files or source code.
Show the failing test names and
the relevant error messages.
Copilot may execute:
dotnet test --no-build
The sandbox limits the resources available to these commands according to the effective policy.
If a required package registry or directory is blocked, inspect the policy before granting additional access.
Do not immediately disable sandboxing just to make a build succeed.
Understand Package Manager and Developer Tool Access
A sandbox must allow development tools to run without giving them unrestricted access to the machine.
Copilot CLI can automatically identify tools such as:
Git
.NET SDK
Node.js
Python
Java
Package managers
When developer-tool access is enabled, the sandbox grants appropriate read access to tool directories and selected write access to package caches and build locations.
For example, a command such as:
dotnet restore
needs to read the .NET SDK and download packages into the NuGet package cache.
Similarly:
npm install
needs access to package registries and writable cache or dependency directories.
The sandbox accounts for common development requirements, but the exact permissions depend on the detected tools, project, and configured paths.
You can inspect the relevant access using:
/sandbox policy npm install
Or:
/sandbox policy dotnet restore
This is useful when a package installation fails because of filesystem or network restrictions.
Remember that package-manager caches may contain registry configuration and credentials. Allowing developer-tool access can expose selected configuration files to commands running inside the sandbox.
If you need tighter control, disable automatic developer-tool access and explicitly grant only the paths required by your project.
Understand Sandbox Bypass Requests
Sometimes a command cannot complete because the sandbox blocks a required operation.
For example, a build may need to download a package from a registry that is not allowed by the current network policy.
When sandbox bypass is enabled, Copilot can request permission to retry the command with broader access.
The approval prompt describes the command and the proposed retry.
You can choose to:
There is an important security distinction here.
An approved bypassed command runs with the ordinary environment of your user account. It can therefore access resources that were previously hidden by the sandbox, subject to the operating system's normal permissions.
Credential masking and the sandbox network proxy are also skipped for the bypassed command.
For this reason, do not approve a bypass request simply because Copilot says a command failed.
First check:
Which command is requesting broader access?
Which file or network destination does it need?
Is that access necessary for the task?
Can you solve the problem by adding a specific permission instead?
For example, if dotnet restore needs access to an approved NuGet feed, adding the correct network rule is generally preferable to running the entire command outside the sandbox.
You can also disable bypass requests in the sandbox configuration.
Use Local MCP Servers With Sandbox Restrictions
MCP servers allow Copilot to communicate with external tools and services.
A local MCP server may provide access to a database, monitoring system, or internal development service.
Local sandboxing can also restrict supported local MCP server processes.
The General section includes the Sandbox MCP servers setting, which is enabled by default.
When enabled, supported local MCP server processes run within the sandbox and are subject to the relevant filesystem and network policies.
Remote MCP servers are different. They run outside your computer, so the local filesystem sandbox cannot restrict their server-side access. Their connections from Copilot CLI can still be affected by the applicable network policy.
This distinction matters when an MCP server has access to production databases or other sensitive systems.
Do not assume that enabling local sandboxing automatically restricts every operation performed by a remote MCP server.
Use narrowly scoped credentials and configure each MCP integration according to its actual permissions.
Configure Enterprise-Wide Sandbox Policies
Organizations can enforce sandbox settings for developers using GitHub Copilot.
For example, a security team may require local sandboxing and prevent developers from disabling it.
Managed settings can control:
Whether sandboxing is required.
Whether sandbox bypass is allowed.
Which filesystem locations are accessible.
Which network destinations are permitted.
Whether MCP and language servers must run inside the sandbox.
Managed settings appear as locked options in the configuration interface.
If an organization requires sandboxing, ordinary settings and the --no-sandbox command-line option cannot override that requirement.
If the organization permits bypass, a user may still be able to disable sandboxing for the current session through an approved bypass workflow. This does not change the saved organization policy.
This approach is useful for organizations that want developers to use AI agents while maintaining consistent security boundaries across machines.
Common Mistakes to Avoid
Starting Copilot from the wrong directory
The working directory influences default filesystem permissions. Starting Copilot from a parent directory may give the agent a broader read scope than necessary.
Open the project directory before starting the session.
Assuming sandboxing protects every operation equally
Child processes are restricted by operating-system controls. Some built-in CLI operations enforce the same policy in software rather than through a separate operating-system process boundary.
Understand which tools are covered by the sandbox.
Approving every bypass request
A bypass can expose the command to credentials and files available to your normal user account. Investigate the blocked operation before approving it.
Allowing unnecessary network access
A build may need a package registry, not unrestricted internet access. Add specific destinations rather than weakening the entire network policy.
Forgetting that MCP servers have different execution models
Local and remote MCP servers do not share the same security boundary. Review their authentication and network access separately.
Assuming settings are shared across Copilot products
Copilot CLI and the GitHub Copilot app maintain separate sandbox configurations. Enabling sandboxing in one does not automatically enable it in the other.
Summary
GitHub Copilot CLI local sandboxing provides a way to run AI-assisted development commands with restricted access to files, networks, and credentials on your computer.
Developers can enable it with /sandbox enable, inspect the active state with /sandbox status, and review permissions with /sandbox policy.
The most important practice is to grant only the access required by the current task. Keep sensitive directories denied, restrict unnecessary network access, review bypass requests, and treat MCP integrations as separate security boundaries.
For .NET, Node.js, Python, and other development projects, local sandboxing makes it possible to use Copilot for builds, tests, and code changes while reducing the impact of unintended commands.
It does not replace code review, endpoint security, or credential management. It provides an additional execution boundary that should be part of a secure development workflow.
Join the conversation! Your thoughts help the community grow.