GitHub Copilot Local Sandboxing Reaches GA: Windows 11 Requirements, Defaults and Security Limits

The short version: before you give an AI agent a shell on your workstation, you can now control what that shell can reach. Turning the feature on is not the same as locking everything down, though, and the defaults need a careful read.

From June preview to October GA​

The feature has moved quickly. GitHub's June 2, 2026 changelog opened the public preview with this line: "GitHub Copilot can now run inside secure, isolated sandboxes, both locally on your machine and in the cloud." At that stage the scope was narrow: the release focused on isolating shell commands that Copilot started, as groundwork for broader CLI-level isolation later. The June post also said enterprise teams could set and enforce local sandbox policies centrally through Microsoft Intune and other MDM platforms.

The desktop app came later. As WindowsForum reported, GitHub added local sandboxing to the GitHub Copilot app as a public preview on September 23, 2026, with the feature off by default and configured per project. At the time, ByteIota noted that app sandboxing applied only to local repository and working tree sessions, not to cloud sessions, and not yet to VS Code. The GA announcement fills that gap by naming VS Code sessions that use Agent Host.

The GA changelog lists what developers and organizations can now do:

• Limit which files and directories agent-run commands can read or change.
• Control access to the internet, local networks, Git credentials and GitHub CLI credentials.
• Sandbox local tools and services, including local MCP servers and language servers where supported.
• Use enterprise-managed settings to require sandboxing and enforce policies that developers cannot loosen.
• Run more autonomous agent workflows while keeping clear limits on what Copilot can reach.

GitHub also says model execution and tool isolation are separate. Sandbox policies apply to tool execution no matter which model Copilot is using.

Summary: After roughly four months of preview, local sandboxing is generally available across CLI, the app and VS Code Agent Host sessions, at no extra cost.

What MXC is, and how strong the boundary is​

Local sandboxing runs on Microsoft eXecution Container (MXC). GitHub's documentation describes MXC as a cross-platform layer. Copilot declares a policy (which paths are readable or writable, whether network access is allowed, and so on), and MXC applies it through each operating system's own isolation mechanism. Bart Wullems pointed out in his June write-up that this approach means "No Docker required, no VM overhead."

The backends differ by platform:

GitHub is clear about where this sits on the isolation spectrum. The documentation calls local sandboxing lightweight, OS-level process and filesystem containment. It limits what a process can read, write and reach on the network, but it does not run commands inside a separate virtual machine or container. If you need VM-grade separation, this is a different tool.

One caveat deserves attention. The Copilot CLI itself is not sandboxed. Its built-in file tools run inside the CLI process, so the OS sandbox never sees their file operations. GitHub says those tools are coded to check the sandbox policy and honor it on a "best-effort" basis. What the OS actually contains is the child processes: shell commands, file search and, by default, local MCP and language servers. Remote MCP servers are never sandboxed.
Summary: MXC enforces policy through each OS's native containment and adds no VM overhead. The CLI process and remote MCP servers sit outside the OS boundary.

The defaults: "enabled" doesn't mean "locked down"​

These are the defaults GitHub documents for Copilot CLI when sandboxing is on:

• Filesystem: Commands can write to the current working directory and temporary folders. Inside a Git repository, the repo's Git metadata is writable too, and the rest of the repo above your working directory is read-only. Some system and developer-tool locations are readable, and some build and package caches are writable. The home directory as a whole is not exposed, and other paths are blocked unless you grant them.
• Network: Outbound internet access is on by default. Local network access is off.
• Credentials: Git and gh authentication is on by default. Sandboxed commands get placeholder credentials, and a local proxy swaps in the real ones only for approved HTTPS destinations. For gh, those destinations are github.com, api.github.com and uploads.github.com.

Some third-party write-ups don't match these defaults. A daily.dev summary of the preview said the sandbox was blocking outbound network connections by default. GitHub's current CLI documentation says outbound internet access is enabled by default. Go by the official docs and check your own effective policy rather than relying on a blog recap.

The practical point: an agent in a default sandbox can still pull packages from the internet and push to GitHub. If you want an agent that cannot exfiltrate anything, you have to configure that yourself.

Getting started in Copilot CLI​

GitHub documents this workflow:

1. Enable it in an interactive session with /sandbox enable. It takes effect immediately and persists to future sessions through sandbox.enabled in ~/.copilot/settings.json. Sessions already open elsewhere won't use it until you run /sandbox enable in them or restart them (for example with copilot --continue).
2. Verify it with /sandbox status. GitHub calls this the reliable check because it reports what the session actually enforces. The status line also shows "sandbox enabled" by default.
3. Inspect the policy with /sandbox policy. Add a command, such as /sandbox policy npm install, to preview what access that command would get without running it.
4. Adjust it with /sandbox config (or plain /sandbox), which opens the interactive settings for filesystem, network, credentials, subprocesses, macOS keychain access and per-command exceptions.
5. Scope it to one run with --sandbox or --no-sandbox. You can combine these with -p for scripted use, for example copilot --sandbox -p "PROMPT".

When the sandbox blocks a command, Copilot may offer to retry it with broader access. You can approve that one retry, keep the blocked result, or (if policy allows) turn sandboxing off for the rest of the session. GitHub notes that turning it off for the session gives every later command broader access, not just the one that failed. Approve that only if you mean it.

The Copilot app is different​

The app has its own syntax and its own settings, and they don't sync with the CLI:

• /sandbox on and /sandbox off toggle the current session. Plain /sandbox does not open a config screen.
• Project settings set the default for new local repository and working-tree sessions. Changing the default doesn't affect sessions already running.
• The app exposes fewer controls: filesystem paths, internet and local-network toggles, and credentials. It doesn't offer the CLI's subprocess or keychain options.
• A "Run outside the sandbox?" prompt lets you cancel, run the operation once unsandboxed, or disable the sandbox for the session. Enterprise owners can remove those bypass options.
• Local sandboxing doesn't apply to cloud sandbox sessions or remote-host sessions.

Windows-specific notes​

Windows users should check a few things before relying on this:

• Patch level matters. Sandboxing needs the specific Windows 11 25H2 or 26H1 updates listed above. On systems without them, GitHub says sandboxed PowerShell may report a drive root such as C:\ as its current directory, which breaks Set-Location and Git commands. The fix is the September 2026 update or later. As a stopgap, ask Copilot to use absolute paths, for example git -C "C:\PATH\TO\REPOSITORY" status.
• Credential proxying needs loopback. On Windows, the credential proxy only works on versions that support host loopback from the sandbox, and only with Allow local network turned on. That setting also opens private-network access, not just the proxy.
• Host rules are weaker on Windows. On macOS and Linux, outbound traffic is forced through the local proxy. On Windows, the sandbox relies on programs honoring proxy settings, so software that ignores them may connect directly. If host allow/deny lists are central to your threat model, this matters.
• Certificate trust is a system-wide change. To improve tool compatibility, you can install the proxy's certificate authority with /sandbox ca create and /sandbox ca trust. On Windows this needs administrator approval and changes certificate trust for applications outside Copilot too.

Two more quirks apply across platforms. If you deny a path that doesn't exist yet, the CLI creates a directory there, so denying .env before the file exists gives you a folder named .env. Separately, on Linux, Bubblewrap cannot control local-network access for spawned processes on its own.

Enterprise enforcement and fail-closed behavior​

Admins can require sandboxing and lock its settings through server-managed settings, MDM-managed settings (Intune included, per the June announcement) or file-based managed settings. Under a managed requirement, ordinary settings and --no-sandbox can't turn it off. A per-session opt-out still works if the effective policy allows bypass.

What happens on unsupported hosts matters most for compliance teams:

• CLI, unmanaged: A saved preference to sandbox is quietly turned off for that session, with a notice, and commands run unsandboxed. /sandbox enable is refused.
• CLI, managed: If managed settings set both sandbox.enabled and sandbox.failIfUnavailable to true, the CLI blocks model requests and tool execution when it can't enforce the sandbox. A server-managed requirement alone is declined on unsupported hosts unless failIfUnavailable is also set.
• App: Sessions may start normally, but sandboxed processes fail with an unsupported-platform error instead of running unsandboxed.

For fleets where sandboxing must be mandatory, set failIfUnavailable explicitly. Otherwise, an unpatched Windows machine could fall back to unsandboxed behavior without anyone noticing.

The bottom line​

General availability turns a preview into something teams can plan around. The more significant change is that Copilot's three main local surfaces now share the same execution boundary. The design is pragmatic: it uses native OS containment rather than VMs, which keeps overhead low but also puts a ceiling on how much isolation it provides. Outbound internet and Git credentials are available by default, the CLI process sits outside the OS boundary, and Windows proxy enforcement depends on applications cooperating. Turn the sandbox on, check the policy with /sandbox policy, then tighten it. Free as it is, it's a sensible default for anyone letting an agent run commands on their machine.