CybersecurityGitHub Copilot App Local Sandboxing: What the New Security Boundary Does and Does Not Protect
GitHub added per-project local sandboxing to the Copilot app in public preview. The feature can restrict agent-invoked tools from files, networks, and credentials, but it is off by default and does not apply to cloud sandbox sessions or remote hosts.
Accuracy-reviewed by the editorial team
Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers GitHub’s local-sandboxing release for the GitHub Copilot app. The feature is in public preview, so organizations should recheck GitHub documentation before turning this analysis into a permanent control standard.
Agentic developer tools can run shell commands, install dependencies, call services and modify files. That power is useful, but it also expands the consequence of a mistaken instruction, a malicious repository, a compromised dependency or an agent decision that reaches beyond the intended project. GitHub’s new local sandboxing feature for the Copilot app addresses part of that risk by placing agent-invoked tools inside an operating-system sandbox with configurable limits on filesystem, network and credential access.
What GitHub released
Local sandboxing is configured per project for local repository and working-tree sessions. Project owners can allow additional read/write paths, grant read-only access to selected folders, explicitly deny folders, allow or block outbound internet and local-network access, and control whether authenticated Git or GitHub CLI credentials are available inside the sandbox. GitHub says the effective policy may be made more restrictive by enterprise-managed settings.
A particularly important design choice is fail-closed behavior. GitHub documents that if the operating system cannot enforce the requested policy, the sandboxed shell fails rather than silently running without the sandbox. That avoids a dangerous failure mode in which the user believes restrictions are active while the agent is actually executing with the full authority of the local account.
The security boundary this creates
A Git working tree separates branch state and concurrent changes; it is not a security boundary for the rest of the workstation. A command launched from a working tree can normally read other accessible files, connect to local services, reach the internet and reuse credentials available to the user. Local sandboxing adds a separate restriction layer around those capabilities, which is useful when an agent is allowed to execute commands on the developer’s behalf.
The control is most valuable when policy is deliberately narrower than the user account. A repository that only needs package-registry access does not necessarily need the entire local network. A documentation change does not necessarily need GitHub CLI credentials. A project stored next to confidential client data does not need read access to neighboring folders. Least privilege becomes a practical configuration choice rather than a general aspiration.
Important limits and defaults
GitHub’s documentation says local sandboxing is off by default. Enabling “Sandbox new sessions” changes new sessions for the project, not sessions that are already running. An active session can be changed with the /sandbox on command. Policy changes apply when a new session starts or an existing session restarts, so teams should not assume that editing a project policy retroactively changes a process that is already executing.
The feature also has explicit scope limits. It does not apply to cloud sandbox sessions or sessions on a remote host, and sandbox settings for the GitHub Copilot app are configured separately from Copilot CLI sandbox settings. GitHub also documents platform-specific behavior, including limitations around local-network enforcement on Linux for spawned processes. Security teams should test the exact operating system and workflow they intend to rely on rather than copying a generic policy.
Priority configuration for security-conscious teams
Start by enabling sandboxing on repositories where agents can execute tools, then remove capabilities that are not required by the normal workflow. Deny access to password stores, SSH material, cloud credential directories, unrelated source trees and sensitive document folders. Restrict local-network access when the project does not need databases, development services or internal APIs. Disable Git or GitHub CLI credentials in sessions that only need read-and-test behavior.
Use a separate policy for repositories that contain untrusted or externally contributed code. Package hooks, build scripts, test fixtures and generated tooling can execute commands in ways that are not obvious from a code-review prompt. A narrow sandbox reduces the blast radius if an agent follows a repository instruction that was crafted to reach outside the project. It does not make malicious code safe, but it changes what that code can touch.
Approval prompts and escape decisions
GitHub allows a tool blocked by policy to trigger a “Run outside the sandbox?” prompt when the effective policy permits that choice. This is a critical control point, not a convenience dialog. Teams should define when an exception is acceptable, what evidence the developer should review, and which operations must never be approved outside the sandbox. Enterprise owners can prevent users from running tools outside the sandbox, which may be appropriate for higher-risk environments.
A good policy treats escape requests as security-relevant events. If agents frequently require exceptions, the team should decide whether the policy is incorrectly designed or the workflow itself has excessive privilege requirements. Repeatedly clicking through prompts defeats the purpose of the boundary and trains users to authorize commands they have not evaluated.
Verification and monitoring
Test the sandbox with harmless negative cases before relying on it. Confirm that a denied folder cannot be read, blocked network destinations cannot be reached, disabled credentials are not usable and the shell fails when a requested policy cannot be enforced. Repeat those tests after operating-system upgrades or major Copilot app changes because the feature is still in preview.
Record which projects require sandboxing, which capabilities are allowed, who can change the policy and how exceptions are handled. For enterprise environments, combine the sandbox with endpoint monitoring, secret scanning, protected branches and least-privilege repository permissions. The sandbox limits a local execution path; it does not replace code review, identity controls or safe dependency management.
Longer-term security lesson
Agentic development changes the meaning of “developer tooling.” An assistant that can invoke tools is closer to an automation principal operating under the user’s authority. Security architecture should therefore focus on capabilities: which files it can read, which systems it can reach, which credentials it can use and which actions require explicit human approval. Sandboxing makes those capabilities visible and enforceable.
Questions teams should be able to answer
Is local sandboxing enabled automatically?
No. GitHub documents the feature as off by default for local Copilot app sessions. Projects must enable it for new sessions or users can turn it on for an active session with the documented slash command.
Does a Git working tree provide the same protection?
No. A working tree separates Git state for concurrent work, but GitHub explicitly notes that it does not restrict what commands can access elsewhere on the machine. The operating-system sandbox provides the additional access boundary.
Does this cover every Copilot execution environment?
No. GitHub says local sandboxing applies to local repository and working-tree sessions, not cloud sandbox sessions or remote-host sessions, and the app’s settings are separate from Copilot CLI sandbox settings.
Related Zeph Tech guidance
Use the Developer Enablement guide to integrate secure tooling into engineering workflows, the Vulnerability Management Program guide to manage findings, and the risk register to document residual risks such as sandbox exceptions and credential exposure.
Further reading
- Local sandboxing in the GitHub Copilot app — GitHub Changelog
- Configuring local sandboxing in the GitHub Copilot app — GitHub Docs
Continue in the Cybersecurity pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Network Security Fundamentals: Segmentation, DNS, Zero Trust & Monitoring | Zeph Tech
A 2026 practitioner guide to network segmentation, firewall policy, DNS security, remote access, encrypted traffic, monitoring, administration, and zero-trust architecture.
-
Small Business Cybersecurity Survival Checklist
A practical 2026 cybersecurity operating guide for small and medium-sized businesses, organized around NIST CSF 2.0 and current FTC guidance with bounded Verizon DBIR threat…
-
Cybersecurity Operations Playbook
Build a defensible cybersecurity operations program around NIST CSF 2.0, current incident-response guidance, exploited-vulnerability prioritization, evidence capture, and…
Coverage intelligence
- Published
- Coverage pillar
- Cybersecurity
- Source credibility
- 40/100 — low confidence
- Topics
- GitHub Copilot · Local sandboxing · AI agents · Developer security · Least privilege
- Sources cited
- 2 sources (github.blog, docs.github.com)
- Reading time
- 6 min
Further reading
- Local sandboxing in the GitHub Copilot app — GitHub
- Configuring local sandboxing in the GitHub Copilot app — GitHub Docs
Source feedback
Editorial
Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.