TL;DR: GitHub shipped local sandboxing for Copilot to general availability on October 7, 2026 — in Copilot CLI, the Copilot app, and VS Code sessions using Agent Host — at no extra cost on every plan. It is off by default, and the default policy still allows outbound internet. Enable it anyway: it is the cheapest insurance against an agent trashing files outside your repo.

	Copilot local sandbox	Cursor run modes + sandbox	No sandbox (status quo)
Best for	Teams that can mandate it via org policy	Solo devs already on Cursor	Nobody running agents on untrusted repos
Cost	$0 extra, all Copilot plans	Included in all Cursor plans	Free until an agent runs rm -rf outside your repo
The catch	Off by default; outbound internet stays open	Two critical CVEs escaped it in 2026 (both patched)	Agent runs with your full user account

Honest take: Turn Copilot’s sandbox on today and leave the network defaults alone until they break something — a contained agent with internet access still beats an uncontained one with internet access. If you manage a team, make it non-negotiable via managed settings; that enforcement knob is the one thing Cursor doesn’t match yet.

GitHub Copilot’s agent can run shell commands on your machine. Until this month, every one of those commands ran with your full user account: read any file your user can read, write anywhere, call any host. Local sandboxing is GitHub’s answer, and after a four-month preview it is now generally available. Here is what it actually does, where it stops, and what it changes in the Cursor vs Copilot decision.

What shipped on October 7, 2026?

GitHub’s changelog entry of October 7, 2026 declares local sandboxing generally available in three surfaces: GitHub Copilot CLI, the GitHub Copilot app, and VS Code sessions that use Agent Host. It is included with every Copilot plan at no additional cost — Free tier included.

The feature confines shell commands the Copilot agent executes on your machine to an OS-enforced policy: which directories it may write, which hosts it may reach, and whether it may use your Git credentials. The GA follows a CLI public preview that started June 2, 2026 and a Copilot app preview (per-project, fail-closed) added September 23, 2026.

Two things the GA announcement does not change:

1. Sandboxing stays off by default. Until you enable it — or your organization requires it through managed settings — agent commands keep running unrestricted.
2. This is the local sandbox, not the cloud one. Copilot’s cloud sandboxes (used by coding agent and agentic autofix) run on GitHub’s infrastructure. Local sandboxing confines code running on your hardware, so your source never leaves the machine for the sandbox to work.

How does the sandbox work under the hood?

Local sandboxing is powered by Microsoft eXecution Container (MXC), a layer that translates one common sandbox policy into each operating system’s native isolation primitives — on Linux that means user namespaces via bubblewrap, on macOS the system sandbox facilities, on Windows a container tier GitHub calls BaseContainer plus a network proxy.

The design is fail-closed: if the host cannot enforce the policy — say, a Windows build without the required update, or a Linux box without bubblewrap — sandboxed commands fail with an error rather than silently running unsandboxed. That is the right default, and it is the opposite of how most “best effort” agent guardrails behaved in 2025.

One honest limitation GitHub documents itself: the CLI’s built-in file tools (the agent’s own read/write operations, as opposed to shell commands it spawns) check the policy in-process, on a best-effort basis, because they execute outside the OS sandbox. The hard OS-level guarantee applies to spawned shell commands.

How do you enable local sandboxing in Copilot CLI?

Inside an interactive Copilot CLI session, one command turns it on:

$ copilot
> /sandbox enable

The change applies to the current session and persists (reported as sandbox.enabled in ~/.copilot/settings.json); other already-open sessions need a restart or their own /sandbox enable. Three companion commands cover inspection and tuning:

• /sandbox status — reports whether sandboxing is enforced right now
• /sandbox policy — prints the effective filesystem and network rules for the current directory
• /sandbox config — opens interactive settings, including the Network tab where you add Allow host rules

In the Copilot app, sandboxing is configured per project in the project’s settings. In VS Code (1.141+), the agent sandbox applies to sessions using Agent Host and is enabled through the Copilot agent settings — note VS Code’s implementation is still marked experimental on Windows even though the CLI and app are GA there.

For organizations: Copilot managed settings can require local sandboxing. When the policy comes from the org, neither local config nor --no-sandbox can switch it off. If you run a team on Copilot Business or Enterprise, this is the setting to flip before the next prompt-injection-shaped incident lands in your dependency tree.

What does the default policy allow and block?

The default policy is pragmatic rather than paranoid. As of the October 2026 GA, per GitHub’s docs:

Resource	Default	Notes
Write: working directory + temp dirs	✅ Allowed	Git metadata of the repo is also writable
Write: repo above the working directory	❌ Blocked	Readable, not writable
Write: rest of the filesystem	❌ Blocked	The core protection
Outbound internet	✅ Allowed	Restrict via Allow host rules in /sandbox config
Local network (LAN)	❌ Blocked	Your NAS and router config are off-limits
Git / GitHub CLI credentials	✅ Via proxy	Real credentials only presented to approved destinations; can be disabled

The credential proxy deserves a sentence: instead of exposing your Git token to every process in the sandbox, Copilot routes git and gh authentication through a proxy that attaches real credentials only for approved destinations. A malicious script can still use your credentials against github.com, but it cannot exfiltrate the token itself to an attacker’s host.

The localhost story differs by OS, and it matters for web developers. On macOS, a sandboxed command can reach your dev server on localhost:5173 when permitted. On Linux, sandboxed processes live in their own network namespace and cannot reach the host’s localhost directly at all — only the built-in proxy can, subject to host rules. Budget a few minutes of confusion if your agent runs integration tests against a local server.

What are the OS requirements?

This is where most enablement attempts will stumble, especially on Windows:

OS	Requirement (Copilot CLI, GA)
Windows	Windows 11 25H2 with KB5124010+, or 26H1 with KB5124006+
macOS	macOS 15 (Sequoia) or later
Linux	bubblewrap 0.5.0+ on PATH; slirp4netns if outbound network is allowed

VS Code’s agent sandbox lists different Windows updates (KB5124008 for 24H2/25H2, KB5124012 for 26H1) and stays experimental on Windows — check the docs page for the surface you actually use, because the KB numbers are not interchangeable.

The most common failure on Linux, per GitHub’s docs and early user reports: /sandbox enable succeeds, but the first sandboxed command errors out because bubblewrap isn’t installed — fail-closed working as designed, an error instead of a silent unsandboxed fallback. The fix is one line on Debian/Ubuntu:

$ sudo apt install bubblewrap slirp4netns

After installing, /sandbox status should report enforcement as active. If you see commands erroring out right after enabling on Windows, check winver first — a 25H2 machine without KB5124010 fails the same way, and Windows Update is the fix, not a Copilot setting.

What does the sandbox NOT protect against?

Four gaps worth naming, because “sandboxed” is doing less work in this sentence than you might assume:

1. Outbound internet is open by default. A prompt-injected agent can still POST the contents of your working directory — which includes your source code and any .env in it — to an attacker’s server. Locking this down means maintaining Allow host lists, which is friction GitHub left to you.
2. Windows network enforcement relies on the proxy being honored. Programs that ignore system proxy settings can route around the network policy on Windows. macOS and Linux enforce at a lower level.
3. The agent’s own file tools are best-effort. The OS-level guarantee covers spawned shell commands; the CLI’s built-in file operations check policy in-process.
4. It does not sandbox judgment. The sandbox contains where code runs, not what the model decides to do with your approved credentials inside the allowed scope. Reviewing diffs before commit is still your job.

None of this makes the feature pointless — a blast radius of “current directory plus internet” is dramatically smaller than “everything my user account touches.” But treat it as a seatbelt, not a roll cage.

Does this change the Cursor vs Copilot decision?

For security posture specifically, Copilot just pulled roughly even on mechanism and ahead on governance — but Cursor has been doing agent sandboxing longer.

Cursor’s model is tiered run modes: in the recommended Auto-review mode, allowlisted commands run immediately, other shell commands run inside Cursor’s sandbox where supported, and whatever can’t be sandboxed goes through a review classifier. Sandboxed-by-default execution predates Cursor 3.0. That maturity cuts both ways: 2026 gave Cursor a real CVE history — CVE-2026-22708 (shell built-ins like export bypassed the allowlist, patched January 2026) and the critical “DuneSlide” pair CVE-2026-50548/50549 (CVSS 9.8; a symlink inside the workspace defeated path canonicalization and allowed writes outside the workspace), patched in Cursor 3.0 this April. Copilot’s MXC sandbox is newer and has no public CVE record yet — which means less battle-testing, not fewer bugs.

Where Copilot now clearly wins is enforcement: an org can mandate local sandboxing through managed settings, and no local flag overrides it. Cursor’s run modes remain per-user choices. For a team lead standardizing a tool for 30 developers who clone third-party repos all day, that single knob is a genuine differentiator, on top of what we covered in the Copilot enterprise reboot.

Verdicts by persona:

• Evaluating AI-suggested shell scripts from untrusted repos: Copilot CLI with sandboxing on, plus Allow host rules. The fail-closed design and credential proxy are built for exactly this.
• Solo dev who wants maximum agent autonomy: Cursor, unchanged. Its sandbox interrupts you less because the allowlist learns your routine commands; the full comparison still applies for features beyond security.
• Team lead with compliance requirements: Copilot, and this GA is the reason. Mandatory sandboxing via managed settings plus data-residency-friendly local execution is a story Cursor can’t tell yet.

If your threat model is “I don’t want my code or credentials near any cloud at all,” neither sandbox solves that — the model API still sees your context. The only full answer is a local model on your own hardware; our sister site covers what runs on which GPU, and for fully open-source agent stacks see Continue.dev vs Cline vs Aider.

FAQ

Is Copilot local sandboxing on by default? No. As of October 24, 2026 it ships disabled. You enable it per surface (/sandbox enable in the CLI, per-project in the app) or an organization requires it via managed settings.

Does local sandboxing cost extra? No. GitHub’s GA announcement states it is included with GitHub Copilot at no additional cost, on every plan including Free.

Does it work on Windows 10? No. The CLI requires Windows 11 25H2 (KB5124010+) or 26H1 (KB5124006+). macOS needs version 15 or later; Linux needs bubblewrap 0.5.0+.

Does the sandbox block internet access? Not by default. Outbound internet is allowed; local-network access is blocked. You can restrict outbound traffic to specific hosts with Allow rules in /sandbox config.

Is this the same as Copilot’s cloud sandbox? No. Cloud sandboxes run agent code on GitHub’s infrastructure. Local sandboxing confines commands executing on your own machine via OS-level controls (MXC), so code never leaves your hardware.

Can developers on my team turn it off if I require it? No. When local sandboxing is required through organization managed settings, local configuration and --no-sandbox cannot override it.

Sources

• Local sandboxing for GitHub Copilot now generally available — GitHub Changelog, Oct 7 2026
• Using local sandboxing — GitHub Docs
• About cloud and local sandboxes for GitHub Copilot — GitHub Docs
• Configuring local sandbox settings — GitHub Docs
• Sandbox Copilot agent sessions — VS Code Docs
• Run modes — Cursor Docs
• CVE-2026-50549 — MITRE
• GitHub Copilot Local Sandboxing Reaches GA: Windows 11 Requirements, Defaults and Security Limits — WindowsForum

Last verified October 24, 2026. GitHub’s official pages were verified via search-indexed copies due to network restrictions in our publishing environment; defaults and requirements were cross-checked against three independent write-ups. Features and policies change frequently — confirm against the GitHub docs before relying on a specific control.

Know which coding tool is worth paying for

Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.

Email address Subscribe