GitHub Copilot App Adds Fail-Closed Local Sandboxing Preview

GitHub Copilot app sandboxing adds limits a working tree doesn't​

GitHub's changelog says local sandboxing aims to let you "safely run agent-generated code on your machine through isolated tool execution, without giving Copilot unrestricted access to the filesystem, network, or system." In the app, the sandbox covers local repository sessions and working-tree sessions. It doesn't cover cloud sandbox sessions or sessions on a remote host.

The distinction from working trees is easy to miss. A working tree keeps branches and files apart between sessions running at the same time. GitHub's app documentation says a working tree does not limit what a command can reach elsewhere on the machine. The sandbox adds that limit. When sandboxing is off, commands the agent runs can reach the same files, networks, and credentials your user account can.

GitHub's documentation on cloud and local sandboxes explains the underlying technology. Local sandboxing is powered by Microsoft eXecution Container (MXC), a cross-platform technology that provides a common interface to the isolation mechanisms available on each operating system. GitHub is also clear about how strong that isolation is. It restricts what a process can read, write, and reach on the network, but it does not run your commands inside a separate virtual machine or container. Those MXC details are written in terms of Copilot CLI. The app has its own documentation and settings, so treat the backend description as the general design of Copilot's local sandbox, not an app-specific spec.

This release extends work that started in June. GitHub's June 2, 2026 changelog opened the cloud and local sandbox preview and said local sandboxes are included in the standard GitHub Copilot seat. That release focuses on isolating shell command execution initiated by Copilot. The September item brings that model into the desktop app with a separate, per-project settings screen. GitHub's documentation says the Copilot app itself is available on all Copilot plans.

Filesystem, network and credential settings, one project at a time​

The project's sandbox settings have three groups. GitHub's documentation gives defaults for each, and those defaults are fairly permissive. Turning the sandbox on restricts some things, but it doesn't lock down network access or credentials unless you change those settings.

Denied folders take priority. A more specific denied folder stays denied even if a broader parent folder has read or write access. That's how you protect a sensitive folder next to a project without cutting off the whole tree around it.

Network settings affect more than internet access. GitHub counts loopback and connections to local development servers as local network, and services such as GitHub and package registries as outbound internet. Blocking either one can break package installs, API calls, preview servers, and any other tool that needs a connection.

The credential settings involve the same kind of choice. Turning off Git or GitHub CLI credentials keeps the agent from using your identity. It also means the agent can't push a branch or open a pull request from inside the sandbox. Be deliberate here: you're choosing which parts of the workflow the agent can finish on its own and which ones need you.

The sandbox fails closed when the OS can't enforce the policy​

The most important safety property is what happens when enforcement isn't possible. The app accepts your settings before it knows whether the OS can apply them. It checks support when the first sandboxed shell starts. If the host can't enforce the policy, the shell fails with an unsupported-platform or unsupported-policy error. It does not run without a sandbox.

If the app shows Sandbox unavailable, GitHub's instructions are to fix the reported problem and select Retry sandbox. There's no automatic fallback to unsandboxed execution, and that's the right design. Otherwise a policy could look active in settings while giving no protection.

Windows users are most likely to run into this. The app lets you save a denied path in project settings. If the active Windows sandbox capabilities can't guarantee that denial, the sandboxed command fails with an unsupported-policy message. It doesn't continue with the path left accessible. GitHub's sandbox concepts page gives similar Windows advice for the CLI: the proxy is not available on Windows, and users should not use denied paths there either, because Copilot CLI cannot enforce these settings and the sandboxed command fails.

On Windows, then, a denied-folder list may stop sandboxed commands from running at all, instead of protecting the folder. Setting up protection with read-only and read/write grants, and leaving out denials, is the more likely setup to work there. That's an inference from how GitHub documents the Windows behavior, not a procedure GitHub has published.

Windows 11 support for the Copilot app sandbox has a documentation gap​

Platform requirements are where the documentation is weakest. GitHub's concepts page says local sandboxing is available on macOS, on Linux, and on recent Windows 11 builds. For other platforms it lists the Seatbelt backend on macOS and bubblewrap on Linux, and says to install bubblewrap 0.5.0 or later, and make sure bwrap is on your PATH.

The Copilot CLI how-to page says something stricter: local sandboxing on Windows requires a Windows Insiders build. So GitHub's own pages describe Windows support in two different ways, and both descriptions are about Copilot CLI. The app documentation sends readers to separate Windows support information and doesn't say whether the Insider-build requirement applies to the app. If you run the stable Windows 11 channel, the fail-closed behavior is your safety net. Turn the sandbox on, start a session, and see whether the app reports Sandbox unavailable.

Don't use CLI setup steps in the app. On the CLI side, sandboxing is currently an experimental feature, started with the ‑‑experimental command line option or /experimental on during a session. The CLI also has flags such as --sandbox and --no-sandbox, and it stores the setting in ~/.copilot/settings.json. None of these are the app's documented way to turn sandboxing on. GitHub says the app and Copilot CLI sandbox settings are configured separately, so turning on one doesn't protect the other.

How to turn on local sandboxing in the GitHub Copilot app​

The controls work at two levels, and they apply changes at different times.

Set the project default​

1. Open the Copilot app settings and select the project.
2. Under Sandbox, turn on Sandbox new sessions.
3. Set the filesystem, network, and credential options for the project.
4. Start a new session. The default applies only to new sessions, not to ones already running.

Change a running session​

1. In an active local session, enter /sandbox on to turn sandboxing on, or /sandbox off to turn it off.
2. The change takes effect right away and creates an override for that session only. The project default for other sessions stays the same.
3. To apply changes to the filesystem, network, or credential settings, restart the session. GitHub documents /restart-session for this, and it keeps the session history.

Two timing rules can trip you up. Toggling sandboxing inside a session is immediate, but changes to access settings only apply to new or restarted sessions. And if you enter /sandbox on or /sandbox off before a session starts, it changes the project default that new sessions inherit, not a single-session override.

When the agent asks to leave the sandbox​

If a tool needs access the policy doesn't allow, the app may ask "Run outside the sandbox?" Depending on the effective policy, you can cancel, let that one operation run outside the sandbox, or turn sandboxing off for the rest of the session. If you pick the last option, the app shows Sandbox off for this session with a way to turn it back on. This change doesn't affect the project default or the session override, and it ends when the session restarts or reattaches. Copilot CLI has a similar prompt: you can approve that single command, keep it inside the sandbox, or disable sandboxing for the rest of the current session.

That prompt is where most of the risk sits. Allowing one operation outside the sandbox is a narrow exception. Turning sandboxing off for the whole session removes the boundary for everything after it, which is easy to forget in a long agent run.

Enterprise-managed policy can override what the Copilot app shows​

For IT administrators, the key line in the announcement is that the effective policy can be stricter than the project settings when enterprise-managed settings apply. GitHub's enterprise-managed settings documentation says managed sandbox rules can do the following:

• Require sandboxing and block users from bypassing it.
• Restrict which paths users can grant and add denied paths of their own.
• Turn off Git or GitHub CLI credential injection.
• Stop users from running tools outside the sandbox, which removes the "Run outside the sandbox?" escape entirely.

The June preview announcement described this as a device-management feature. It promised the ability to apply enterprise policy to local Copilot execution by centrally configuring and enforcing sandbox policies through Microsoft Intune and other MDM platforms. Organizations that already manage Windows endpoints through Intune can govern agent execution through the same channel, without relying on each developer to set things up correctly.

The limitation is visibility. The Copilot app shows the user's project settings, not the full effective managed policy, and it doesn't show which individual settings are locked. A developer may see network access allowed in the project screen and still get blocked by an enterprise rule. Nothing in the app explains why. Copilot CLI is ahead here: entering /sandbox policy shows the effective filesystem policy that results once settings, automatic grants, and any managed policy are combined. The app documentation has no equivalent. Administrators who deploy managed sandbox rules should publish them to their developers, or expect help-desk tickets that look like app bugs.

What this means for you​

Developers who let the Copilot app run multi-step agent sessions on local repositories should turn on Sandbox new sessions for those projects. The defaults keep network access and credentials on, so everyday work keeps functioning while the agent's file writes are limited to the workspace. Administrators should decide on a managed policy before rolling this out, because the app won't show users what's enforced. Anyone who relies on cloud sandboxes or remote-host sessions can skip this setting, since it doesn't cover them.

• Local sandboxing in the GitHub Copilot app is a public preview released September 23, 2026. It's off by default and applies only to local repository and working-tree sessions.
• Turning the sandbox on limits file writes to the workspace but keeps internet access, local-network access, Git credentials, and GitHub CLI credentials on unless you change them.
• If the OS can't enforce a requested policy, the sandbox fails closed with an error. On Windows, denied paths are the setting most likely to cause that failure.
• Copilot CLI and the Copilot app have separate sandbox settings, so turning on one doesn't protect the other.
• Enterprise-managed rules can require the sandbox, restrict grants, and block the run-outside-sandbox prompt, but the app shows only the user's project settings.
• Choosing "disable sandboxing for this session" at the prompt removes protection until the session restarts, so allow one operation instead whenever that's enough.

GitHub has moved Copilot's local sandbox from an experimental CLI flag to a per-project setting in its desktop app. The design choices are sound: denied paths override broader grants, unenforceable policies fail closed, and managed rules can close every escape route. What's missing for a preview that affects security is transparency. That means a clear statement of which Windows builds the app supports, and a way for developers to see the policy actually enforced on their machine. Until GitHub adds both, Windows developers should test that the sandbox actually starts on their build, and administrators should document any managed rules they deploy.