Back to wire
Development·Article

GitHub Copilot app adds opt-in sandbox for local agent sessions

GitHub has added an opt-in local sandbox to the Copilot app, letting projects restrict filesystem access, outbound internet, local-network access and Git or GitHub CLI credentials for local agent sessions. The public preview is off by default, fails closed when the requested policy cannot be enforced, and is separate from cloud, remote-host and Copilot CLI sandbox settings.

Published 23 Sept 2026, 18:47

Local sessions get a project-level policy

GitHub added local sandboxing to the GitHub Copilot app on 23 September as a public preview for local repository and working-tree sessions. The setting is configured per project and is off by default. When enabled, it constrains the environment in which the local agent can execute commands instead of giving every session the same access as the developer account running the app.

The project policy can add read-write and read-only filesystem locations, deny folders, control outbound internet and local-network access, and decide whether authenticated HTTPS Git operations or GitHub CLI authentication receive credentials. GitHub says enterprise-managed settings can make the effective policy more restrictive than the project requests, so an organisation can narrow a developer's local configuration centrally.

The requested boundary fails closed

GitHub says the sandboxed shell returns an error if the operating system cannot enforce the requested policy, rather than silently running the command without the sandbox. That fail-closed behaviour is important for agent sessions because a configuration intended to remove filesystem or network access does not degrade into ordinary host execution when enforcement is unavailable.

Changing the project policy affects new sessions and sessions that restart. A developer can also enter `/sandbox on` inside an active local session to enable sandboxing for that session without changing the project default. GitHub does not describe the preview as a complete isolation guarantee, and the effective security boundary still depends on the operating system and the exact policy applied.

Cloud, remote-host and CLI sessions stay outside this setting

The Copilot app setting does not apply to cloud sandbox sessions or sessions running on a remote host. GitHub also configures Copilot app and Copilot CLI sandboxing separately, so enabling the project setting in the app should not be read as a universal Copilot policy across every execution surface.

That scope makes the release most relevant to developers who let the desktop app operate directly on a local checkout. It gives those sessions an explicit containment layer around files, networks and credentials while leaving GitHub's other agent runtimes under their own controls. Teams using several Copilot surfaces still need to review the boundary for each one rather than assuming the local-app policy travels with the repository.

Public preview leaves enforcement details to test

The release establishes the available policy controls, opt-in behaviour and fail-closed path from GitHub's own changelog. It does not publish an adversarial security evaluation, a complete matrix of operating-system enforcement mechanisms or evidence that every tool an agent can invoke is contained equally under every supported host configuration.

For security-sensitive use, the practical next step is therefore to test representative commands against denied directories, network restrictions and credential settings on the operating systems a team actually uses. The preview gives GitHub Copilot a clearer local trust boundary, while its resistance to sandbox escapes and compatibility with complex development tooling remain questions for platform-specific testing.

Source trail

1 source · 1 primary