Introduction

Copilot cloud and local sandboxes are the execution platform powering secure sandboxed experiences for GitHub Copilot CLI, both locally and in the cloud. As Copilot takes more actions on your behalf—running tools, executing commands, and modifying files—sandboxing provides the isolation, portability, and policy controls needed to adopt agentic workflows safely.

Sandboxing currently applies to Copilot CLI sessions. You can also choose to use cloud sandboxing when you start a new session in the GitHub Copilot app. For more information, see Working with agent sessions in the GitHub Copilot app.

With sandboxing, you can choose where Copilot runs:

• Local sandboxing: Run Copilot securely on your own machine. The commands that Copilot runs have restricted access to your filesystem, network, and system capabilities. You can use local sandboxing at no extra charge.
• Cloud sandboxing: Run the entire Copilot CLI session remotely, inside a fully isolated, ephemeral Linux environment hosted by GitHub. Cloud sandboxing is billed based on usage.

Local sandboxing

Local sandboxing lets Copilot run in a sandboxed environment directly on your machine, with restricted access to your filesystem, network connectivity, and system capabilities.

Local sandboxing is turned off by default. Until you enable it, the shell commands that Copilot runs execute directly on your machine with the same access as your user account: they can read, write, and delete wherever you can, reach any network your machine can reach, and use your credentials without restriction. Enabling local sandboxing constrains this access to a policy that you control.

How local sandboxing works

Local sandboxing is powered by Microsoft eXecution Container (MXC), a cross-platform technology that provides a common interface to the isolation mechanisms available on each operating system. Copilot CLI declares the sandbox policy it wants to enforce—which paths are readable or writable, whether network access is allowed, and so on—and MXC applies that policy using the appropriate isolation backend for your operating system.

Isolation technologies exist on a spectrum, from strong isolation such as full hypervisors or containers, to lighter-weight isolation such as OS-level process and filesystem containment. Local sandboxing currently sits at the lighter-weight end of this spectrum: it restricts what a process can read, write, and reach on the network, but it does not run your commands inside a separate virtual machine or container. If you want to evaluate whether this level of isolation meets your security requirements, see the microsoft/mxc repository for implementation details.

For more information, see Understanding filesystem policies for local sandboxing in GitHub Copilot CLI.

Enabling local sandboxing

To enable local sandboxing inside a Copilot CLI session, run:

/sandbox enable

/sandbox enable

After you enable local sandboxing, the commands and tools that an agent runs on your behalf—shell commands, file search, and, by default, the MCP and language (LSP) servers the CLI starts—run inside an operating-system-level sandbox, limiting their access to your system. The CLI continues to use local sandboxing whenever you use the CLI in future—for programmatic as well as interactive use—until you run /sandbox disable to disable it. If enterprise managed settings require sandboxing, ordinary settings, startup options, and /sandbox disable cannot turn it off. If the effective policy permits sandbox bypass, you can still explicitly disable sandboxing for the rest of the current session from an active bypass permission prompt.

The CLI's built-in file tools—first-party commands that are part of the CLI, rather than shell commands like sed—run in-process in the CLI. Because the CLI itself is not sandboxed, the operating-system sandbox never sees the file operations these tools perform and cannot constrain them. Instead, the built-in tools are coded to check the sandbox policy themselves and honor your configured settings on a best-effort basis.

For more information, see Using local sandboxing.

Configuring local sandboxing

You can use the default local sandboxing behavior, or you can modify what Copilot can access. When you configure local sandboxing, you can control several dimensions of access:

• Filesystem: Grant read-only or read/write access to specific paths, or deny paths.
• Network: Allow or block outbound internet access and local network access independently.
• Credentials: Choose whether your Git and GitHub CLI (gh) credentials are made available inside the sandbox.
• Subprocesses: Choose whether local MCP servers and language servers also run inside the sandbox. Remote MCP servers are never sandboxed.
• Keychain (macOS): Choose whether the system keychain is reachable from inside the sandbox.
• Per-command exceptions: Allow or prevent individual commands from running outside the sandbox when they need broader access.

For more information, see Configuring local sandbox settings.

Cross-platform support

Local sandboxing is available on macOS, on Linux, and on recent Windows 11 builds. Each operating system uses a different isolation backend, so the requirements are different:

• macOS uses the Seatbelt backend. Copilot CLI applies a process-scoped profile to each sandboxed command. Use macOS 15 (Sequoia) or later. Copilot CLI does not block an older macOS, but the backend is not tested there.
• Linux uses the bubblewrap backend. Install bubblewrap 0.5.0 or later, and make sure bwrap is on your PATH. If /sandbox reports that your bwrap is too old, upgrade the package.
• Windows uses the BaseContainer tier of the ProcessContainer backend. Copilot CLI does not use the AppContainer fallback tiers. If your Windows build cannot supply BaseContainer, Copilot CLI reports that sandboxing is not supported. To find the supported Windows versions, see Windows OS support for Copilot sandboxing.

Proxy support

The sandbox proxy operates differently on each operating system:

• macOS: Copilot CLI does not give the proxy to Seatbelt. It sets HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY in the sandboxed environment instead. Only programs that obey these variables use the proxy. A program that ignores them connects directly.

• Linux: bubblewrap enforces the proxy. The sandbox gets a private network namespace, and only the proxy endpoint is permitted. This mode has more requirements. You must have:

  • slirp4netns on your PATH.
  • unshare and nsenter from util-linux 2.35 or later, with --map-current-user and --keep-caps support.
  • iptables and ip6tables. Use the nf_tables backend. The legacy backend also operates, but only if you can write to /run/xtables.lock.

  Two more limits apply on Linux. The proxy must have an IPv4 address, because Copilot CLI refuses a proxy that only IPv6 can reach. The proxy URL must not contain credentials, so give the credentials to the proxy itself.

  Also on Linux, bubblewrap cannot control local network access independently of outbound access. Your local network setting therefore does not have a separate effect there.

• Windows: the proxy is not available. Do not use denied paths on Windows either. Copilot CLI cannot enforce these settings, and the sandboxed command fails with an error.

If your host does not support local sandboxing

Copilot CLI turns the sandbox off for the session and shows a notice. Shell commands and sandboxed services then run without a sandbox, and your sandbox.enabled setting does not change. If your enterprise enforces sandboxing through device-managed settings, the session fails closed instead: sandboxed commands do not run.

Enterprise policy enforcement

Enterprises can require local sandboxing and enforce its configuration through server-managed, MDM-managed, or file-based managed settings. See Configuring enterprise-managed settings.

Cloud sandboxing

Cloud sandboxing lets you run Copilot CLI sessions inside fully isolated, ephemeral Linux environments hosted by GitHub. Each cloud sandbox session is isolated from your local environment and from other sessions.

Cloud sandboxing is built on Azure Container Apps Sandboxes, with GitHub providing the identity, policy, and billing layer.

Starting a cloud sandbox session

To start a cloud-backed session, run the following command:

copilot ‑‑cloud ‑‑experimental

copilot ‑‑cloud ‑‑experimental

The ‑‑cloud command line option launches an interactive Copilot CLI session inside a cloud sandbox. You can prompt Copilot to perform tasks, run shell commands, and iterate on code, the same way you would in a local session. The commands that Copilot runs execute in the cloud environment, not on your local machine.

Running copilot ‑‑cloud starts a single Copilot CLI session in a cloud sandbox. It does not affect future Copilot sessions. Each time you want to run a new session in a cloud sandbox, you must start the CLI with the ‑‑cloud option.

Continue sessions across devices

Because cloud sandbox sessions run in GitHub-hosted infrastructure, you can pick up a Copilot session on any device, regardless of where the session was originally started. This enables more flexible workflows without needing to copy files or reinstall dependencies.

Offload compute-intensive workflows

You can run multiple Copilot tasks in parallel in the cloud without consuming local resources. This keeps your local environment lightweight and responsive while scaling agent-driven work.

Unified governance

Cloud sandbox policies share the same configuration as Copilot cloud agent policies, extending existing security controls to cloud sandboxed execution without additional setup.

Session lifecycle

A cloud sandbox session has three main states:

• Active: The session is running, and you are interacting with it from Copilot CLI.
• Stopped: The session is not currently running, but its state is saved. When you resume it, your files, environment variables, and in-progress work are restored.
• Deleted: The session and its saved state are removed and cannot be recovered.

When you stop a session, the cloud sandbox creates a snapshot of its state so you can pick up where you left off later. When you delete a session, both the running environment and the snapshot are removed.

Authentication and access

Sandboxing uses your existing Copilot CLI authentication. If you can sign in to Copilot CLI and have access to Copilot, you can use sandboxing. You don't need to configure a separate cloud provider, manage API keys, or set up infrastructure.

An organization or enterprise owner must enable the Cloud Sandbox access policy in the organization or enterprise settings before members can use cloud sandboxes.

For information about enabling or disabling cloud sandboxes for members of your organization, see Enabling or disabling cloud sandboxes for your organization or enterprise.

Billing

Local sandboxing is included in the standard GitHub Copilot seat at no additional cost.

Cloud sandboxing is billed based on usage. GitHub measures cloud sandbox usage across three meters:

For more information about how cloud sandbox usage is measured and billed, see Billing for cloud and local sandboxes for GitHub Copilot.

Further reading

• About GitHub Copilot CLI
• Using local sandboxing
• Configuring local sandbox settings