GitHub Copilot Sandboxing

Canonical version: GitHub Copilot Sandboxing.

GitHub Copilot Sandboxing is GitHub's answer to the "agent with full shell access" problem: two complementary isolation modes for running GitHub Copilot CLI agent sessions, both in public preview. Local sandboxing wraps the commands an agent runs on your machine in an OS-level sandbox powered by Microsoft eXecution Container (MXC). Cloud sandboxing moves the whole session off your machine into an ephemeral, GitHub-hosted Linux environment built on Azure Container Apps Sandboxes.

Local sandboxing

Runs shell commands, built-in searches, and local MCP/LSP servers as sandboxed child processes, enforced by the OS via MXC's per-platform backends: Seatbelt on macOS, Bubblewrap on Linux, ProcessContainer on Windows (Insiders builds only). Enable with --experimental.

The policy model is deny-by-default with automatic grants assembled per command:

  • The working directory gets read/write (default), the rest of a Git repository gets read-only
  • Tools on PATH (plus GOPATH, CARGO_HOME, PYTHONPATH) get read-only, so commands can't modify their own dependencies
  • System locations and the home directory get read-only; package manager caches get read/write
  • Network: outbound internet and local network are controlled independently
  • Credentials (Git, gh), macOS keychain access, and per-command sandbox exceptions are all configurable
  • Overlaps resolve by specificity ("the more specific path wins"), and user config always beats automatic grants. Enterprise-managed settings (GitHub Copilot Managed Settings) compose in the most restrictive direction: the enterprise sets a floor users can tighten but never loosen

Inspect with /sandbox policy and /sandbox status, configure with /sandbox config.

One big caveat: the CLI's built-in file tools run in-process, and the CLI itself is not sandboxed, so the OS never sees those file operations. They honor the policy in software only, on a best-effort basis. Same class of caveat as MXC's own "not a security boundary yet" warning.

Cloud sandboxing

Each session runs in a fully isolated, ephemeral Linux VM on GitHub's infrastructure (--cloud --experimental). Sessions are snapshotted (files, environment variables, in-progress work) and can be resumed from any device. Also available when starting agent sessions from the GitHub Copilot App. Usage-billed (compute per second, memory per GiB-second, storage per GiB-month) versus local sandboxing which is included in the seat. Interactive sessions only; programmatic use is unsupported. Organizations must enable the Cloud Sandbox access policy.

How it compares

The sandboxing space splits by where the boundary sits:

Option Boundary Where it runs Positioning
Copilot local sandboxing (MXC) OS process sandbox (Seatbelt/Bubblewrap/ProcessContainer) Your machine Policy on the agent's commands, lightest-weight isolation
Copilot cloud sandboxing Hosted ephemeral VM GitHub cloud Remove your machine from the blast radius entirely
Docker Sandboxes microVM per session (own kernel, private Docker daemon) Your machine VM-grade isolation locally, agent-agnostic (works with Copilot too)
Windows Sandbox Hyper-V container-VM hybrid Your machine Disposable full Windows desktop, not agent-specific; also an experimental MXC backend
OpenSandbox Pluggable runtimes (Docker, K8s, gVisor, Kata, Firecracker) Self-hosted Open-source agent execution platform: lifecycle, credential vault, egress policy
Cloudflare Sandbox SDK Cloudflare Containers instance Cloudflare edge Managed sandbox-as-API for agents you build, addressable from Workers
Vercel Sandboxes microVM Vercel cloud Managed sandbox-as-API in the Vercel platform, secrets injected from outside

The key distinction: Copilot sandboxing secures GitHub's own agent for its users, while Docker Sandboxes secures any local agent, and OpenSandbox, Cloudflare, and Vercel are infrastructure for agents you build. And within Copilot itself: local sandboxing is a process-level policy (weaker, free, fast), cloud sandboxing is full machine isolation (stronger, billed, portable sessions).

References


About Sébastien

Ready to get to the next level?

Found this valuable? Share it with someone who needs it.

Join 6,000+ readers. Get practical systems for knowledge & AI. Free.

Subscribe ✨

Free: Knowledge System Checklist

A clear roadmap to building your own knowledge system. Subscribe and get it straight to your inbox.

6,000+ readers. No spam. Unsubscribe anytime.

Subscribe