GitHub Copilot is getting a new security control for local development: project-level sandboxing. GitHub announced local sandboxing in the Copilot app on September 23, 2026, describing it as a way to reduce the possible impact of unintended commands by limiting what a local AI-assisted session can access.
The change is important because coding assistants can work with real files, network resources and developer credentials. Sandboxing creates an extra policy layer around those capabilities, allowing a project to define what the Copilot environment is allowed to touch rather than treating the entire local machine as equally available.
What local sandboxing controls
GitHub's new settings are organized around three areas: filesystem access, network access and credentials. For files, developers can specify additional read/write locations, additional read-only locations and folders that should be denied.
Network controls define whether outbound internet access and local-network access are permitted. The credential settings cover access related to Git credentials used for authenticated HTTPS operations and GitHub CLI credentials. Together, those controls allow a project owner to define a narrower operating boundary for AI-assisted sessions.
Sandboxing is off by default
One of the most important details is that local sandboxing is off by default. GitHub says developers can enable it from the app settings by selecting their project and turning on Sandbox new sessions. The setting applies to new project sessions rather than sessions that are already running.
GitHub also documents a command-based option for active work: entering /sandbox on can enable sandboxing for the current local session. Changes to filesystem, network and credential settings apply when a new session starts or when an existing session restarts.
Why this matters for AI coding workflows
AI-assisted programming is different from a traditional autocomplete tool because a capable agent can perform sequences of actions instead of only suggesting individual lines of code. That can be useful for repository maintenance, debugging, refactoring and automation, but it also means a mistake can have consequences beyond the code currently being edited.
Local sandboxing addresses part of that problem by limiting the blast radius. A project can reserve sensitive folders, restrict network behavior or control access to credentials instead of allowing an AI session to operate with unrestricted local privileges.
Enterprise policies can be more restrictive
GitHub notes that the effective policy may be more restrictive when enterprise-managed settings apply. That matters for teams where administrators already define security boundaries for developer tools. The project-level policy requested by a user is therefore not necessarily the final policy that becomes effective.
GitHub also says that when an operating system cannot enforce the requested sandbox policy, the sandboxed shell fails rather than continuing without sandboxing. That behavior is significant because silently falling back to an unsandboxed command environment would defeat the purpose of the control.
Public preview and what developers should know
The local sandboxing feature is currently in public preview, so the implementation and controls may change. Developers testing it should treat the settings as part of a broader security strategy rather than a substitute for normal repository permissions, least-privilege credentials and careful review of generated changes.
For everyday Copilot users, the practical takeaway is straightforward: AI coding environments are gaining more explicit boundaries around what they can access. As agent-style development becomes more common, controls over files, networks and credentials are becoming just as important as the model's coding capabilities.
Source
GitHub Changelog — Local sandboxing in the GitHub Copilot app
