GitHub Ships Copilot Local Sandboxing: Lock Credentials First

GitHub has moved local sandboxing for Copilot to general availability this week, covering the CLI, the Copilot app and VS Code Agent Host sessions.

The detail comes from a developer write-up published on Dev.to on 8 October rather than from a vendor page, so treat the specifics below as that author's reading of the announcement. What the post describes is straightforward: "Commands the agent starts run with restricted access to files, network and credentials, based on a policy you set."

Three things the policy controls

The write-up breaks the decision into files, network and credentials, and it is worth keeping them separate because they fail differently.

• Files. The author's rule is that the agent should see the repo it is working on and nothing else: "My home folder has SSH keys, cloud configs and old project stuff. None of it helps the agent fix a failing test."
• Network. Most agent tasks need package installs and little else, so the post argues for allowing the package registry and blocking the rest — "rather than find out later that some script phoned home."
• Credentials. This is the one the author flags as the real worry.

Check the credential setting first

The reasoning is blunt: "If the agent can use my Git credentials, it can push." According to the post, GitHub's sandbox lets you control access to Git and GitHub CLI credentials specifically, and that is "the setting I'd look at first."

That ordering makes sense. A file-scope mistake leaks what the agent can read; a credential mistake writes to a remote that other people pull from.

What it costs you

Friction, mostly. The post is direct that some installs and tests will fail inside a sandbox and you will spend time loosening the policy, with an expectation of tweaking it "a few times in the first week."

The recommended sequence is to start strict and open only what breaks, explicitly skipping the attempt to write a perfect policy up front. For teams already letting agents run commands with no boundary at all, that is a week of tuning against an unbounded blast radius — an easy trade.

Model choice stays separate

One detail the author singles out from the announcement: model execution and tool isolation are treated separately, so the policy applies whichever model you pick. If that holds, switching the agent's backing model does not silently reset your containment.

If you are not on Copilot

An independent project published the same day makes the underlying argument more sharply: "Prompt instructions alone are not an operating-system security boundary."

AegisExec is an experimental Linux CLI that brokers agent actions — a client submits a versioned JSON request, a trusted policy admits or denies it, and Python runs through Bubblewrap in a network namespace with no host interfaces or outbound connectivity. It accepts three operations: read_text, list_dir and run_python. Its author reports 69 tests passing with no skips in Ubuntu 22.04 CI on Python 3.10, including 17 sandbox execution tests.

The same author is unusually clear about where it stops. It is "not a production-certified sandbox," it only works when every agent operation goes through the broker because "An agent with a separate host shell can bypass it," approval-required operations are disabled in v0.1, and Windows and macOS cannot run the Linux sandbox at all. The bundled React policy explorer is a simulation; the CLI is the authoritative implementation.

What to watch

Two questions decide whether this GA matters in practice. First, how many real repos survive a strict default policy without a week of exceptions. Second, whether the file, network and credential controls stay this granular once teams start pushing org-wide policies at them.