Copilot App Local Sandboxing Limits Agent Files, Network, and Credentials
On September 23, 2026, GitHub put local sandboxing for the GitHub Copilot app into public preview—per-project policies that restrict agent filesystem, network, and Git/GitHub CLI credentials, with fail-closed behavior if the host cannot enforce the policy.
GitHub published a dedicated changelog on September 23, 2026, placing local sandboxing for the GitHub Copilot app into public preview, and reiterated the feature in the September 25 weekly Copilot releases note. The app configures sandboxing per project for local repository and working tree sessions so agents’ commands face restricted access to files, network resources, and credentials on the developer machine. Local sandboxing is off by default. Project settings under Sandbox include additional read/write paths, additional read-only paths, denied folders, outbound internet and local network toggles, and whether Git credentials and GitHub CLI credentials are available inside the sandbox. Enterprise-managed settings can make the effective policy stricter than the project request.
The security model is fail-closed when the operating system cannot enforce what was asked. If the host cannot apply the requested policy, the sandboxed shell errors instead of quietly running unsandboxed—an explicit contrast with “best effort” containment that fails open. Enabling “Sandbox new sessions” applies to new sessions in the project, not already-running ones; filesystem, network, and credential edits likewise apply to new sessions or when an existing session restarts. For an active local session, /sandbox on flips that session without changing the project default. Local sandboxing does not apply to cloud sandbox sessions or sessions on a remote host, and Copilot app settings are separate from Copilot CLI sandbox settings.
GitHub’s conceptual documentation explains the shared platform underneath both surfaces. Local sandboxing uses Microsoft eXecution Container (MXC) as a common interface over OS isolation backends. It sits at the lighter-weight end of the isolation spectrum: process and filesystem containment rather than a full hypervisor or container per command. Built-in CLI file tools that run in-process are called out as a nuance—the OS sandbox may not see those operations, so the tools honor policy on a best-effort basis in code. Cross-platform backends differ: macOS Seatbelt (tested guidance points at macOS 15 Sequoia or later), Linux bubblewrap with additional networking helpers when outbound traffic is allowed, and Windows BaseContainer on supported Windows 11 builds. Proxy behavior also differs by OS; Windows does not offer the sandbox proxy path described for macOS and Linux.
Cloud sandboxing remains the other pole. Entire sessions can run in ephemeral GitHub-hosted Linux environments built on Azure Container Apps Sandboxes, with compute, memory, and snapshot storage billed by usage. Local sandboxing, by contrast, is included in the standard Copilot seat with no extra charge. Enterprises can require local sandboxing through server-managed, MDM-managed, or file-based managed settings; when those policies require sandboxing, ordinary toggles cannot simply turn it off. Organization owners must separately enable cloud sandbox access before members can use hosted sandboxes.
For teams adopting agentic Copilot workflows after a month of supply-chain and history-poisoning headlines, local sandboxing is a product control rather than a CVE patch. It does not replace reviewing which plugins or MCP servers an agent may install, and it does not migrate cloud or remote-host sessions. It does give project and enterprise admins a documented way to shrink blast radius for shell and network actions on the laptop where most coding agents still run. Public preview means the knobs and enforcement details can change; operators should re-check docs when promoting from evaluation to default-on.
Day-two details matter for security reviewers. Project settings expose filesystem extras and denies, outbound internet, local network, and credential availability; the app can still prompt to approve an individual command outside the sandbox when broader access is needed. Whether bypass requests are allowed is not a project-settings toggle in the app the way some CLI exception controls are. On Linux, bubblewrap cannot control local network access independently for spawned processes the same way other platforms do; the app’s local-network setting still applies to in-process operations such as web requests and remote MCP connections. Those asymmetries are why GitHub’s unsupported-platform path fails the shell instead of silently widening access.
The September 25 weekly releases note also bundled related Copilot surface updates—new frontier models in Copilot plans, OpenTelemetry activity tracking for the app, and JetBrains assisted approvals—but local sandboxing is the control that changes the trust boundary for agent shell execution on the laptop. Teams evaluating default-on rollout should pilot one repository first, confirm Seatbelt, bubblewrap, or BaseContainer actually enforces the requested policy on their standard developer images, and decide whether credential passthrough for git and gh is required for the workflows they want sandboxed.
- #GitHub Copilot
- #AI Agents
- #Developer Tools
- #Sandboxing
Author
Raj M
Contributor
AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.