GitHub Copilot CLI Sandboxing Is GA: What Actually Changed

GitHub's changelog confirmed on October 7 that local sandboxing for Copilot, including the CLI, the desktop app, and VS Code sessions using Agent Host, is now generally available, and the default posture flips from trusting the agent to restricting it: commands Copilot runs get limited filesystem, network, and credential access unless you explicitly widen the policy. That is the right default for an agent that executes model-suggested shell commands against a real checkout, and it is overdue, because every competing CLI agent has shipped some version of this for months.

What's actually sandboxed#

The mechanism is Microsoft eXecution Container, MXC, which translates one policy definition into native OS controls on Windows, macOS, and Linux rather than shipping three separate implementations. The scope is tools and commands that Copilot starts: file reads and writes, network calls, and credential access, including Git credentials and the GitHub CLI's own token. Sandboxing also extends to local tools and services Copilot talks to, including local MCP servers and language servers where supported. GitHub's framing is specific: the policy applies to tool execution regardless of which model is driving the session, so it is not a model-safety feature, it's an execution-boundary feature. That distinction matters because it means switching models inside Copilot CLI doesn't change what the sandbox allows.

What you can actually configure#

The controls are the kind you'd expect from a filesystem and network jail, not a content filter. You can scope which directories agent-run commands can read or write, control whether the agent reaches the internet or only local network targets, and decide whether it gets Git or GitHub CLI credentials at all. The enterprise half of the release lets an organization require sandboxing org-wide and enforce a policy developers cannot loosen themselves, which is the detail that actually matters for anyone running Copilot CLI against a shared build box rather than a personal laptop. A policy a developer can opt out of in thirty seconds is a suggestion, not a control.

Here's roughly what a project-level sandbox policy looks like when you want Copilot CLI to run in CI with a tightly scoped footprint:

# .copilot/sandbox-policy.yml
version: 1
filesystem:
  allow_write:
    - ./src
    - ./tests
  deny_write:
    - ./.git
    - ./secrets
network:
  allow:
    - api.github.com
  deny_all_else: true
credentials:
  git: read-only
  github_cli: none

The exact schema is GitHub's to define and will likely shift as the feature matures past GA, but the shape, explicit allowlists over implicit trust, is the right one, and it is the same shape every serious CI secrets policy already takes.

The part nobody should skip: enabling it#

Sandboxing isn't automatically retroactive for every existing session type. The CLI's own documentation describes running /sandbox enable inside a session, and the September changelog entry for the Copilot app still described local sandboxing as a public preview with the usual change-without-notice caveat, even though the October 7 post calls the CLI, app, and VS Code Agent Host surfaces generally available. That gap between "GA" and "docs still say preview" is normal for a fast-moving rollout, but it means you should check your own environment's state rather than assume the feature is on because you read a changelog post.

# inside a Copilot CLI session
/sandbox enable
/sandbox status

Run /sandbox status after enabling it and actually read the output. A sandbox that silently fails open is worse than no sandbox, because it changes your mental model of what's protected without changing what's protected.

The deliberate contrast: not every agent made this choice#

This rollout is worth reading next to a decision Anthropic made the opposite way. Claude Code shipped mods, small TypeScript functions that hook into prompt submission, tool calls, and permission checks, and Anthropic's own documentation says mods run with the same native, unsandboxed permissions as Claude Code itself, by design, because that native access is what lets a mod rewrite a prompt or redact a tool-output secret before anything downstream sees it. We covered why that's a real CI risk in Claude Code mods and the unsandboxed CI risk. Two agents, two answers to the same question: Copilot CLI restricts execution by default and lets you widen it; Claude Code mods extend execution by design and ask you to trust the source. Neither answer is wrong in isolation, but they are not interchangeable, and a team running both in the same pipeline needs separate threat models for each, not one shared assumption about what "the agent" can touch.

Where this fits in a CI decision#

We already laid out the three questions that decide whether any CLI agent belongs in a pipeline, authentication without a human, approved capability, and failure behavior, in AI CLI agents in CI pipelines. Sandboxing GA mostly answers the second question for Copilot CLI specifically: the default capability set shrank, and the enterprise policy lock answers it a second time for anyone who doesn't trust individual developers to leave the default alone.

The decision, concretely#

• Running Copilot CLI on a shared build box today? Enable sandboxing explicitly and verify with /sandbox status; don't assume GA means on-by-default for your existing installation.
• Setting org policy across many repos? Use the enterprise-managed enforcement so individual developers can't quietly widen the policy back to unrestricted.
• Comparing Copilot CLI to Claude Code for a CI job? Treat them as differently shaped risks: one restricts by default, one extends by design through mods, and your pipeline's threat model needs to name which one it's running.
• Relying on a local MCP or language server alongside Copilot CLI? Confirm it's actually covered by the sandbox policy; GitHub says support varies, so don't assume parity with the CLI's own tool calls.

The call we'd make#

Enable Copilot CLI sandboxing now rather than waiting for your organization to mandate it, and set the enterprise policy lock if you manage more than a handful of developers, because a sandbox a developer can disable in thirty seconds protects you from accidents and nothing else. The caveat: verify the feature's actual state in your environment before trusting a changelog post, since GitHub's own docs and the September preview announcement haven't fully caught up to the October GA claim.