DEV Community

Ahab
Ahab

Posted on Originally published at indieseek.co

GitHub Copilot app local sandboxing: a least-privilege rollout checklist

GitHub Copilot app local sandboxing: a least-privilege rollout checklist

Quick answer

GitHub released local sandboxing for the GitHub Copilot app on September 23, 2026. It can restrict the files, network resources, and Git or GitHub CLI credentials available to agent-run tools in local repository and working-tree sessions. The feature is a public preview, is off by default, and must be configured per project.

Do not treat the switch as proof that a project is safe. A working tree separates branches and files, but it is not a security boundary. Test the policy against the folders, services, destinations, and credentials your workflow uses. Start with denied secrets and disabled credentials, then grant only what a reproducible task needs.

Who this is for

This guide is for developers and small teams using the GitHub Copilot app locally, especially when a repository sits near personal files, production credentials, sibling projects, databases, or internal services. GitHub documents Copilot CLI settings separately; app settings do not configure the CLI. Cloud and remote-host sessions also use different boundaries.

What changed and what did not

The Copilot app now exposes a project policy with three control groups:

Control What the app can restrict Default documented behavior
Filesystem Extra read/write folders, extra read-only folders, and denied folders Workspace and current working directory are writable
Network Outbound internet and local network access Both are allowed
Credentials Authenticated HTTPS Git and GitHub CLI access Both are available

The policy applies to agent-run tools inside local repository and working-tree sessions. It does not turn the app into a virtual machine; GitHub describes it as operating-system-level containment.

Two lifecycle details matter. First, Sandbox new sessions affects newly created local sessions, not sessions already running. Second, changes to filesystem, network, or credential rules take effect after a new session starts or an existing session restarts. For one active session, /sandbox on enables the sandbox without changing the project default.

When the host cannot enforce the requested policy, the app should fail closed with an unsupported-platform or unsupported-policy error instead of silently running without isolation. Test this on every supported operating system.

Build a least-privilege policy

Start from the task, not from convenience. Use this matrix before changing project settings:

Resource Default decision Grant only when
Repository workspace Read/write The task needs to edit or build the project
Sibling repositories Deny A named dependency cannot be vendored or mocked
Home, documents, downloads Deny A specific file is required and can be copied into a safer staging folder
Dependency cache Read/write or read-only The package manager demonstrably needs it
Outbound internet Off for replay tests Installation or a documented API call is part of the task
Local network Off The task must reach a specific local dev server or database
Git credentials Off The task must fetch or push over authenticated HTTPS
GitHub CLI credentials Off The accepted workflow must create or inspect GitHub resources

Prefer an additional read-only path over read/write access. A more-specific denied child remains denied even when its parent is readable. Keep secrets outside the workspace.

A six-case rollout canary

Run this acceptance set in a disposable branch or working tree without production secrets.

  1. Allowed write: ask the agent to create and remove a fixture inside the repository. It should succeed, and git status should show only the expected path.
  2. Denied read: place a harmless marker in a denied folder and ask the agent to read it. The command must fail, and the marker must not appear in logs or chat output.
  3. Read-only write: expose a fixture folder as read-only, verify that listing works, then verify that modification fails.
  4. Network split: with outbound internet disabled, test an external URL; with local network disabled, test a local preview server. Record each result separately because the settings protect different destinations.
  5. Credential split: run unauthenticated Git operations, authenticated HTTPS Git, and gh auth status as separate cases. A failure to push does not prove GitHub CLI credentials are unavailable.
  6. Policy lifecycle: change one rule, confirm the running session retains its old policy, restart with /restart-session, and rerun the case. This catches false confidence caused by editing settings without restarting.

For every case, record requested policy, command, result, and unexpected access. A passing build is insufficient; denial cases must fail for the intended reason.

Promotion and exception workflow 

Can the task finish with workspace-only filesystem access?
  yes -> keep sibling and personal folders denied
  no  -> grant one named path, preferably read-only

Does the task need a network connection?
  no  -> disable outbound internet and local network
  yes -> enable only the required network class and replay the canary

Does the task need to publish or create a pull request?
  no  -> keep Git and GitHub CLI credentials unavailable
  yes -> enable the required credential, perform the bounded action, then retest

Does the app ask to run outside the sandbox?
  yes -> cancel first, inspect the exact command and missing capability,
         then prefer a narrow policy change over disabling the sandbox
Enter fullscreen mode Exit fullscreen mode

Depending on enterprise policy, the app may offer a one-time bypass or disable the sandbox for the session. Treat this as an exception: record command, reason, reviewer, and result, then restart the session.

Common mistakes

  • Assuming a working tree prevents commands from reading other locations on the machine.
  • Turning on the project default and forgetting that an already-running session keeps its current state.
  • Granting the home directory because one dependency cache was missing.
  • Leaving local-network access enabled when tests should use a mocked service.
  • Enabling both Git and GitHub CLI credentials when only one workflow requires authentication.
  • Treating an unsupported-policy error as a reason to run unsandboxed instead of fixing or changing the environment.
  • Applying Copilot CLI documentation to the app without checking the product boundary.
  • Calling the preview a complete security boundary without denial tests and review.

Make your Mac notch useful with SuperNotch—22 native tools for music, clipboard, focus, screenshots, system controls, and more.

FAQ

Will the app silently run without a sandbox if enforcement fails?

GitHub documents fail-closed behavior for the app: a sandboxed shell returns an unsupported-platform or unsupported-policy error rather than running unsandboxed. Verify that behavior on your supported hosts.

Do these settings configure Copilot CLI too?

No. GitHub documents the app and CLI as separate configuration surfaces. Test and manage each one independently.

Sources

Originally published on IndieSeek.

Top comments (0)