Copilot app adds local sandboxing: Require it across sessions

On September 23, 2026, GitHub released local sandboxing for the Copilot app in public preview. It is off by default. An administrator can enable the project's sandbox while an older session continues with its previous access, so the rollout needs a session transition as well as a settings change.

The new control restricts filesystem, network, and credential access for local repository and working tree sessions. To make it mandatory, administrators need to block both unsupported execution and outside-sandbox approvals. Verify those restrictions on the actual host: the project screen does not display all the managed rules the runtime enforces.

This guide combines GitHub's documentation with our recommended rollout decisions. General Analysis has not tested enforcement in a Copilot deployment. Use securing coding agents for the wider baseline and managed Copilot permissions for policy delivery and operation approvals.

Require the sandbox before narrowing its access#

For a local project, open app settings, select the project, and enable Sandbox new sessions. GitHub's app configuration guide documents that workflow. A working tree separates branches and files for concurrent work; it does not, by itself, restrict commands elsewhere on the host.

If sandboxing is an enterprise requirement, deploy it through the managed configuration your devices already receive. The following fragment covers enforcement and bypass. It leaves the workload's filesystem and network policy for a separate decision.

Code source: GitHub's managed sandbox reference, adapted to require sandboxing and prohibit bypass.

The first three properties work together:

• enabled: true prevents the project setting and /sandbox off from disabling the required sandbox.
• failIfUnavailable: true, together with enabled, blocks model and tool execution when the runtime cannot validate, compile, or enforce the sandbox policy. It does not enable sandboxing on its own.
• allowBypass: false prevents a command from running outside the sandbox and prevents users from disabling it for the rest of a session through a bypass prompt.

GitHub separately documents that the app's sandboxed shell fails when the OS cannot enforce the requested policy. The managed failIfUnavailable setting establishes a broader startup requirement for model and tool execution. Keep both behaviors in the acceptance record; a failed shell and a blocked session are different observations.

The MCP and LSP settings require local servers started in the session to run inside the sandbox. Remote MCP servers execute elsewhere and retain their own permissions. Review those connections through the MCP server security guide.

Resolve the session state before testing access#

Consider a hypothetical migration: a developer already has two local sessions open when the administrator turns on sandboxing and removes Git credentials. Starting a third session checks the new configuration. It says nothing about the first two until they transition to the new policy.

GitHub's session instructions distinguish several lifetimes:

A temporary bypass does not change the project default or the persistent session override. Consequently, restarting ends that temporary exception but does not by itself establish that the session will be sandboxed: check the underlying default, override, and managed requirement. The same slash commands entered before a session starts change the project default instead of creating an active-session override.

Record the app version, OS version, project, session identifier, policy revision, and restart time together. Keep cloud sessions and sessions running on a remote host outside this local-app rollout. Copilot CLI has separate sandbox settings; a CLI check is not evidence that the app received the same configuration.

Choose which authority the task still needs#

An enabled sandbox still permits useful work. The documented app defaults include workspace and current-directory writes, internet and local-network access, and authenticated Git and GitHub CLI operations. A review-only task may need much less.

For a local code review with dependencies already available, consider denying sensitive sibling folders, disabling network access the task does not need, and removing Git and GitHub CLI credential injection. This is a proposed workload policy, not a universal default. A build that downloads private packages needs a different decision.

Credential controls deserve a closer look. GitHub's managed reference says gitAuth: false and ghAuth: false prevent GitHub token injection for their respective tools. It also exposes allowDevToolAccess: false to prevent automatic access to development-tool configurations, caches, registries, and toolchains. Those locations may hold package credentials. Disabling token injection alone is therefore insufficient evidence that a process cannot read another credential through its allowed paths.

Removing automatic dev-tool access can break package restoration and builds. Grant the required locations deliberately after checking their contents and access mode. Avoid giving back an entire home directory to fix one cache error.

Managed filesystem grants have another surprising property: they constrain user-configured paths by exact path string, not parent/child containment. A managed allowance for /work does not automatically retain a user's separate /work/library grant. An empty managed read/write list removes user-configured grants but does not remove automatically assembled access such as temporary directories or the current working directory. GitHub documents these rules under managed filesystem policy. Do not describe that empty array as a read-only workspace.

Diagnose the failure before widening policy#

The app accepts settings before checking host support. GitHub says the check happens when the first sandboxed shell starts. The managed reference also says the app shows the user's project settings without the full effective managed policy or per-setting managed locks. A permissive-looking toggle may coexist with a stricter runtime decision.

Use a harmless pilot task and separate these outcomes:

The OS distinctions come from the app documentation. On Windows, a saved denied path produces an unsupported-policy error if the active sandbox capabilities cannot guarantee it; the command does not run with that path exposed. Use the documentation's linked Windows support information for the intended host.

On Linux, the sandbox cannot independently control local-network access for spawned processes, including shell commands and local MCP or LSP servers. The local-network setting still applies to in-process operations such as web requests and remote MCP connections. If the task requires public internet while excluding local services from spawned processes, use an execution environment with independently verified network isolation. The app toggle does not establish that separation.

If the app displays Sandbox unavailable, address the reported cause, then use Retry sandbox. Do not turn a required control off merely to make the pilot pass.

Approve a deployment group with observed evidence#

For each supported app/OS combination, ask the pilot owner to record one allowed operation and one denial for every restriction the workload depends on. Use dummy files and owned test services. A denied read should record the tool request and runtime result; an agent deciding not to try the read does not exercise enforcement. These are proposed acceptance checks, not results from General Analysis research.

Also verify that a blocked operation cannot obtain an outside-sandbox approval under the mandatory policy. If the host cannot enforce an essential restriction, leave that deployment group unapproved or move its work to a suitable environment. Keep other groups' evidence separate.

When a build fails later, its owner should be able to find which policy the session loaded and why a required path was excluded. Keep that evidence with the rollout decision so fixing one build does not mean restoring broad workstation access.