Copilot Local Sandboxing: CLI and App Setup, Permissions and Limits

Identify the surface: generally available does not mean enabled

GitHub announced general availability for Copilot local sandboxing on October 7, 2026. Microsoft eXecution Container (MXC) translates policies for files, networks and other system resources into native OS controls. Current documentation says local sandboxing is off by default. Until enabled, agent-run shell commands have the file, network and credential access available to your user account.

The announcement covers Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host. VS Code is a separate surface: its settings and dependencies should not be applied directly to CLI, the app or other agent integrations. The announcement and reviewed concept documentation do not give a common minimum client version.

Enable CLI or app sandboxing, then narrow access

First identify whether you are using CLI or the app, which machine runs the task, and whether your organization supplies managed settings. Local sandbox settings are independent, so enabling CLI sandboxing still leaves the app to be checked separately.

In Copilot CLI, run /sandbox enable within a session. The preference continues into future sessions until /sandbox disable, subject to enterprise requirements and bypass rules. In the app, use project settings to choose the default for new local repository or working tree sessions. Changing an active session does not change that project default.

Next review readable, writable and denied paths, network access, and Git and gh credential permissions for the task. In a hypothetical task confined to one project, begin with access needed for that project, then assess any request for another directory or an external command. The app can ask you to approve a command outside the sandbox, so pay attention to exceptions as well as the main switch.

Check the operating system on the execution host

GitHub documents Seatbelt on macOS and directs users to macOS 15 Sequoia or later. CLI does not block older macOS versions, but the backend is untested there. Windows requires a recent Windows 11 update supporting sandboxing; denied paths, localhost and proxy capabilities also depend on the specific version. The Windows 11 name alone does not establish readiness.

Linux uses bubblewrap 0.5.0 or later, with bwrap on PATH. Allowing outbound traffic additionally requires slirp4netns, unshare and nsenter from util-linux 2.35 or later with the required user-mapping support, iptables/ip6tables and their restore programs, and access to /dev/net/tun. The documentation specifies the nf_tables backend; the legacy backend additionally needs write access to /run/xtables.lock. Check these CLI requirements rather than borrowing another client's dependency list.

Distinguish sandboxed processes from other tools

Local sandboxing provides lighter-weight process and filesystem containment, rather than running commands in a separate virtual machine or container. Supported shell commands, file search and, by default, local MCP and LSP servers can be constrained. Remote MCP servers are not inside this local sandbox.

The CLI itself is not sandboxed. Its built-in file tools run within the CLI process, so the operating-system sandbox cannot see their file operations. These tools check configured policy on a best-effort basis in software; they do not have the same protection as subprocesses constrained by the OS.

Credentials have separate controls. CLI can manage Git and GitHub CLI authentication and mask additional environment variables. Sandboxed tools receive placeholders, while a local proxy supplies real credentials to approved HTTPS destinations. The app exposes a subset of these settings. Enabling sandboxing does not disable every credential; review what remains allowed.

Account for Windows and Linux network differences

CLI host rules and HTTP proxy settings use a built-in local proxy. On macOS and Linux, outbound connections are restricted to that proxy, so a program ignoring proxy settings cannot connect directly instead. Windows relies on programs honoring proxy settings and requires a supporting OS version with Allow local network enabled. It does not provide the same protection against direct connections.

On Linux, bubblewrap cannot independently control local network access for spawned processes such as shell commands and local MCP or LSP servers. The local network setting still applies to in-process web requests and remote MCP connections in both CLI and the app. Identify how an operation runs before assuming one network switch constrains every operation equally.

Read unsupported-host notices and managed policy before continuing

On an unsupported host, CLI can temporarily turn off a saved user preference for sandboxing in the current session, with a notice that commands and services will run unsandboxed. The saved value remains unchanged. If effective managed settings require both sandbox.enabled and sandbox.failIfUnavailable to be true, failure to enforce sandboxing blocks model requests and tool execution. Do not assume every failure automatically blocks execution.

An app session configured for local sandboxing may start normally but fail when it tries to launch a sandboxed process. Enterprises can supply settings through server, MDM or file management and restrict user changes. Per-command bypass also depends on effective policy. Read the actual notice and organizational rules before continuing, rather than relaxing permissions to remove a warning.

Local sandboxing is included in a standard Copilot seat at no additional sandbox charge. This does not make the subscription or model usage free. Cloud sandboxes are a separate public-preview service running sessions in GitHub-hosted ephemeral Linux environments and are billed by usage. Client access, OS capabilities and organizational authorization must still be satisfied separately; these sources do not guarantee availability for every account or country.