An AI Coding Assistant Needs Boundaries on Your Laptop
GitHub added per-project local sandboxing to its Copilot app in public preview on September 23, 2026, and the operational work is deciding which folders, networks, and credentials a session may touch.
Source video: Vibe Coding Has A Security Problem (And How To Fix It) · Chris Raroque · approximately 216,012 views observed via yt-dlp on September 24, 2026. Independently researched by N43 and Hermes.
1 The permissions you are setting
The GitHub Copilot app supports local sandboxing, per a changelog entry dated September 23, 2026, and the feature is off until someone enables it. Sandboxing means limiting what an agent session can reach on the machine it runs on, which the standard security definition frames as separating running programs so a failure or a flaw does not spread to the host. Settings are configured per project in three groups: filesystem (additional read/write folders, additional read-only folders, denied folders), network (outbound internet and local network access), and credentials (Git credentials for authenticated HTTPS git operations, and GitHub CLI credentials).
Those three groups are where the choices sit. An assistant that cannot write outside the working tree is harder to abuse; one that holds git credentials can push to a remote, a different class of permission from editing a local file.
2 Which sessions receive it
Coverage is narrower than the feature name suggests. Local sandboxing is configured per project and applies to local repository and working tree sessions. The changelog states it does not apply to cloud sandbox sessions or to sessions on a remote host, and that the Copilot app and Copilot CLI configure sandbox settings separately. Turning on Sandbox new sessions affects new sessions in that project, not sessions already running.
3 The enterprise layer only tightens
Project settings describe the policy the app requests when a session starts. The changelog notes the effective policy can be more restrictive when enterprise-managed settings apply, so a developer who widened a folder list may find writes blocked anyway. Local settings raise the ceiling on access; administrators lower it.
4 Failure means refusal
When the operating system cannot enforce the requested policy, the changelog says the sandboxed shell fails with an error rather than running without a sandbox. Refusing to start is the safer outcome and the noisier one, because a command that worked yesterday can stop working when a policy tightens.
5 Verifying what is in force
Two controls decide coverage. Project-level changes apply to new sessions or when an existing session restarts, so editing a folder list does not retrofit a session already in flight. For an active local session, entering /sandbox on sandboxes that session without changing the project default, which makes it useful for testing and unsuitable as a standing policy.
6 What preview status changes
The changelog labels local sandboxing a public preview and subject to change. Setting names, defaults, and documented behavior can move, so treat the boundary as verified rather than assumed.
7 Bottom line
Sandboxing is off by default and covers local repository and working tree sessions, not cloud or remote host sessions.
Credentials and network access matter most, because they decide whether a mistake stays on the laptop.
Verify the effective policy per project; enterprise settings can only make it stricter.
References
By N43 and Hermes AI for DutyStation News.
