GitHub Copilot Local Sandbox - What Can It Access on Your Machine?

AI coding agents can do much more than generate code. They can read project files, run commands, install packages, execute tests, inspect logs, and make changes to a codebase.

That makes them useful, but it also raises an important security question:

What can GitHub Copilot actually access on your computer?

GitHub Copilot CLI provides local sandboxing to restrict the filesystem, network, credentials, and other system capabilities available to commands that Copilot runs on your behalf. The goal is to let developers use agentic workflows without giving every command unrestricted access to the machine.

Local sandboxing is currently an experimental capability and its behavior can change as GitHub continues developing it.

This article explains how the local sandbox works, what it can access by default, what it cannot access, and how developers can inspect and tighten those permissions.

What Is GitHub Copilot Local Sandboxing?

A sandbox is an isolated execution boundary that limits what a program can access.

With GitHub Copilot CLI, local sandboxing runs commands and tools invoked by Copilot inside an operating-system-level sandbox. The commands still run on your own machine, but their access to files, networks, credentials, and system capabilities can be restricted.

This is different from running Copilot in a completely separate virtual machine.

The local sandbox uses operating-system isolation mechanisms rather than placing every command inside a traditional virtual machine or container. GitHub describes the implementation as using Microsoft eXecution Container technology with platform-specific isolation backends.

The important point is that sandboxing changes the permissions available to the commands Copilot executes.

For example, suppose your project is located at:

C:\Projects\InventoryApi

If you start Copilot from that directory and enable local sandboxing, the working directory can normally be given read/write access while unrelated locations on your machine can remain restricted.

What Can Copilot Access by Default?

The exact policy depends on the current sandbox configuration, operating system, and project location.

By default, GitHub documents the working directory as having read/write access. Temporary directories and certain developer-tool locations can also be available so that normal development commands continue to work.

A simplified view looks like this:

These are defaults, not a guarantee that every installation will have exactly the same effective policy. GitHub provides /sandbox policy so developers can inspect the policy for the current environment.

Can Copilot Read Files Outside Your Project?

This is one of the most important questions when using an AI coding agent.

Without appropriate restrictions, commands executed by Copilot can potentially access files available to your user account. GitHub specifically notes that when local sandboxing is disabled, shell commands run with the same access as the user account.

With local sandboxing enabled, access is controlled by the sandbox policy.

For example, imagine your machine contains:

C:\Projects\InventoryApi
C:\Projects\CustomerPortal
C:\Personal\Documents
C:\Secrets

You launch Copilot from:

C:\Projects\InventoryApi

The sandbox is intended to keep Copilot's command execution scoped to the permitted paths instead of automatically giving it unrestricted access to every directory on the machine.

However, developers should not assume that sandboxing makes every sensitive file automatically safe.

GitHub describes some path handling as heuristic and recommends checking the effective policy rather than assuming that a particular file is protected.

What Happens Inside a Git Repository?

Git repositories receive some additional handling.

When the current working directory is inside a Git repository, the sandbox can provide read/write access to the .git directory while allowing read access to repository content above the current directory.

For example:

C:\Projects\InventoryApi
│
├── src
├── tests
├── docs
├── .git
└── README.md

If Copilot starts inside src, the current directory can be writable, while other parts of the repository can be readable.

This allows an agent to understand the wider codebase while keeping write access more focused.

Git operations also depend on access to the .git directory. GitHub notes that removing access to .git can cause operations such as git status, git add, git commit, and git diff to fail.

Can Copilot Access Your GitHub Credentials?

Yes, local sandboxing can make Git and GitHub CLI credentials available to sandboxed commands.

GitHub currently enables Git authentication and GitHub CLI authentication by default in the local sandbox, although these settings can be disabled.

This matters because authentication is different from filesystem access.

For example, a developer might restrict filesystem access but still allow:

git push
gh pr create

to work.

That can be convenient, but it also means credential permissions should be considered when defining a security policy for an AI agent.

If your workflow does not require authenticated Git or GitHub CLI operations, disabling those credentials can reduce the agent's available privileges.

Can Copilot Access the Internet?

Local sandboxing does not automatically mean "offline."

GitHub documents outbound internet access as allowed by default, and local network access is also configurable.

This is important for projects that run commands such as:

npm install

or:

dotnet restore

or:

pip install -r requirements.txt

These commands may need network access to retrieve packages.

At the same time, unrestricted network access can increase the security impact of an incorrectly generated command or a compromised dependency.

For sensitive development environments, network permissions should therefore be reviewed instead of assuming that sandboxing blocks all network traffic.

How to Check the Current Sandbox Policy

One of the safest habits is to inspect the actual policy before relying on it.

Inside Copilot CLI, use:

/sandbox policy

This lets you inspect the effective filesystem permissions and other access granted to the current environment. GitHub's documentation specifically recommends this command for understanding the resolved policy.

You can also open the sandbox configuration with:

/sandbox

The configuration interface includes areas for general settings, authentication, filesystem permissions, and network permissions.

A practical workflow is:

1. Open Copilot CLI from the project directory.

2. Enable local sandboxing.

3. Run /sandbox policy.

4. Review read/write paths.

5. Review authentication settings.

6. Review network access.

7. Run your build and tests.

8. Tighten permissions if the project does not require certain access.

How to Enable Local Sandboxing

GitHub currently documents local sandboxing as an experimental feature in Copilot CLI.

You can enable the experimental functionality and then enable sandboxing from the CLI:

/experimental on

Then:

/sandbox enable

GitHub also supports enabling sandboxing for a single CLI session with:

copilot --sandbox

This can be useful when you want to test an agent workflow without changing the default behavior for every session.

How to Restrict Access to Specific Files

You can add explicit filesystem rules through the sandbox configuration.

For example, imagine your application needs access to:

C:\Projects\InventoryApi
C:\Projects\SharedSchemas

but should not access:

C:\Personal
C:\Secrets

You can configure allowed and denied paths through the Filesystem settings.

GitHub supports read-only and read/write path permissions, along with deny rules for files and directories outside the normal working-directory scope.

This follows a useful security principle:

Give the agent only the access it needs to complete the task.

A Practical Example

Consider a .NET application:

InventoryApi/
├── src/
│   ├── Api/
│   ├── Services/
│   └── Data/
├── tests/
├── appsettings.json
├── appsettings.Development.json
└── .git/

You ask Copilot:

Run the tests, find the failing test, fix the implementation,
and run the tests again.

The agent may need to:

1. Read source files
2. Read test files
3. Modify source code
4. Run dotnet test
5. Read compiler and test output
6. Possibly access NuGet resources during restore

It does not necessarily need access to your entire home directory.

A sensible sandbox policy would therefore keep the project writable while limiting unrelated filesystem access.

This is much safer than launching an agent from a broad directory such as your entire home directory.

What About Secrets in Configuration Files?

Sandboxing does not automatically make secrets inside your project safe.

For example:

{
  "ConnectionStrings": {
    "Default": "Server=...;Password=..."
  }
}

If this file is inside an accessible project directory, an agent that can read the file may be able to read its contents.

The sandbox controls access to the file. It does not automatically understand that a particular string is a password.

For production projects, keep secrets outside source control and use appropriate secret-management mechanisms.

Also avoid asking an AI agent to inspect directories containing unrelated credentials simply because the agent may be able to access them.

Common Mistakes

Starting Copilot From the Home Directory

Running an AI coding agent from a very broad directory can unnecessarily increase the scope of files available to the workflow.

Start from the actual project directory instead.

Assuming Sandbox Means Full Isolation

Local sandboxing is operating-system-level containment, not the same thing as running the entire workload inside a dedicated virtual machine.

GitHub itself distinguishes local sandboxing from cloud sandboxing, where the complete session runs in an isolated cloud environment.

Leaving Credentials Enabled Without a Need

Git and GitHub CLI authentication can be useful, but not every workflow needs them.

If an agent only needs to analyze code, consider whether authenticated operations are necessary.

Ignoring Network Permissions

A sandbox can restrict files while still allowing network communication.

For security-sensitive workflows, review both filesystem and network permissions.

Using Broad Allow-All Options

Copilot CLI provides options that can widen permissions. GitHub warns that broad permissions can allow actions such as modifying files outside the intended repository.

Use broad permissions only when the workflow genuinely requires them.

Troubleshooting Local Sandbox Problems

Build Command Cannot Find a Tool

A sandboxed command may need access to an installed SDK, compiler, package manager, or related directory.

Check:

/sandbox policy

GitHub Copilot CLI can automatically identify certain toolchain directories and provide read-only access so installed development tools continue to work.

Git Commands Fail

Check whether .git is accessible.

If the working-directory permission was removed, Git operations may fail because the repository metadata is no longer available to the sandbox.

Package Restore Fails

Check network access and developer-tool permissions.

For example:

dotnet restore

may require network access to retrieve packages.

Similarly:

npm install

requires access to the package registry.

A File Cannot Be Read

First check whether the file is outside the allowed filesystem paths.

If it is required by the task, add the smallest necessary path permission instead of granting access to an entire drive.

Advantages of Local Sandboxing

1. Limits filesystem access
   The agent can be restricted to relevant directories.

2. Reduces accidental changes
   Commands are prevented from freely modifying unrelated parts of the system.

3. Supports development workflows
   Builds, tests, package managers, and Git operations can continue to work when the required permissions are available.

4. Provides configurable network controls
   Network access can be adjusted according to the workflow.

5. Keeps execution local
   Developers can use local tools and services while applying sandbox restrictions.

Disadvantages and Limitations

1. It is not complete machine isolation
   Local sandboxing uses operating-system-level controls rather than a full virtual machine.

2. Configuration can affect developer workflows
   Overly restrictive rules can break builds, Git operations, or package installation.

3. Permissions require review
   Default settings may provide more access than a highly restricted environment needs.

4. Behavior can change
   GitHub currently describes local sandboxing as experimental/public preview.

5. Network access is not automatically blocked
   Developers must configure network restrictions when their security requirements call for them.

Best Practices for Developers

When using GitHub Copilot as an agent on a local machine, follow these practices:

1. Start Copilot from the specific project directory.

2. Enable local sandboxing for agent workflows that execute commands.

3. Run /sandbox policy and review the effective permissions.

4. Give write access only where changes are expected.

5. Keep sensitive files and credentials outside the agent's working scope where practical.

6. Disable Git or GitHub CLI authentication when it is not required.

7. Review network permissions for sensitive projects.

8. Avoid broad allow-all permissions unless there is a clear reason.

9. Test builds and package restores after tightening permissions.

10. Treat sandboxing as one security control, not a replacement for secure application configuration and secret management.

Local Sandbox vs No Sandbox

The main difference is not that Copilot suddenly becomes unable to interact with your machine. The difference is that the commands it executes operate under an additional access policy.

Conclusion

GitHub Copilot local sandboxing is useful when you want an AI coding agent to work with your local project without giving its commands unrestricted access to the rest of your machine.

The most important thing to understand is that sandboxing is about controlling permissions, not making the agent completely disconnected from your computer.

A typical development workflow may still allow access to the project directory, developer tools, Git credentials, and network resources. Those permissions can be configured based on what the project actually needs.

Before using an agent on a sensitive codebase, inspect the effective policy with:

/sandbox policy

Then review filesystem, network, and authentication settings.

For everyday development, the safest approach is straightforward: start the agent from the project directory, keep its permissions narrow, avoid unnecessary credentials, and verify the effective sandbox policy instead of assuming what the agent can or cannot access.

As GitHub continues developing local sandboxing, developers should also check the current Copilot documentation before relying on a specific preview behavior or configuration option.