Pimp My IDE / Garage Dispatch
Back to garage
September 23, 2026 | local agents / sandbox policy / session scope

A sandbox setting is a request with a fuse.

GitHub Copilot app can now ask the operating system to limit local agent tools by project. The useful part is the shape of the control. Files, networks, credentials, session lifetime, and escape prompts remain visible instead of collapsing into one safety switch.

The take: Turn the sandbox on, then test the exact policy. A default that still permits internet, local network, and authenticated Git may be right for the job. It is not a narrow boundary until you make it one and restart the session that must inherit it.
Wire the Sandbox Breakaway Panel

The switch starts off.

GitHub released local sandboxing for local repository and working-tree sessions in the Copilot app as a public preview. It is off by default. The project can request extra read and write paths, read-only paths, denied paths, internet access, local-network access, Git credentials, and GitHub CLI credentials.[1]

The host operating system enforces the policy. If the host cannot enforce a requested rule, GitHub says the sandboxed shell fails instead of running without the sandbox. That fail-closed behavior matters more than the paint on the toggle.

The defaults still open useful doors.

A sandboxed session gets read and write access to its workspace and current directory. GitHub's documented default also permits outbound internet, local-network connections, authenticated HTTPS Git, and GitHub CLI authentication.[2]

Those defaults support package installation, preview servers, branch pushes, and pull requests. They also carry more reach than a read-only review task needs. Start with the job. Close every route the job does not require.

The word "sandbox" names the mechanism. The policy says what the mechanism allows.

Policy changes have a clock.

Project changes apply to new sessions or to an existing session after /restart-session. They do not rewrite a session that is already running. The /sandbox on command can change one active local session, but it does not change the project default for other sessions.[2]

That creates two records worth saving. Record the policy you intended. Record the restarted session that received it.

The escape prompt is part of the boundary.

When a tool needs blocked access, the app can offer to cancel, run once outside the sandbox, or disable sandboxing for the rest of the session. Enterprise policy can remove those escape choices.[2]

Do not hide this behind a generic approval rule. Decide which jobs may cross the boundary, who can approve that move, and what evidence the approval must leave.

Coverage stops at the named tools.

Zed's sandbox write-up makes the same broader point through a different implementation. Its operating-system restrictions cover the agent terminal and fetch tools, not every editor tool, language server, MCP server, external terminal, or program that later executes generated code.[3]

A sandbox is one control around one execution path. Test that path. Then list the paths that sit outside it.

Run four negative tests.

  1. Place a harmless canary file in a denied sibling folder. Prove the tool cannot read it.
  2. Block internet access. Prove a request to a disposable public endpoint fails.
  3. Block local-network access where the platform supports it. Prove a local canary service stays unreachable.
  4. Remove Git and GitHub CLI credentials. Prove an authenticated dry-run operation cannot borrow ambient identity.

Save the host, app build, project policy, session restart, command, result, and any outside-sandbox approval. The result is a boundary receipt, not a claim that every tool in the editor is contained.

Interactive makeover / policy and session test card

Sandbox Breakaway Panel.

Traditional purpose replaced: one sandbox checkbox. Better version: four policy breakers, a session-lifetime rail, and one explicit break-glass rule drive the same status panel and copyable test card.

Close only the routes this job does not need

This teaching panel records selections. It does not inspect the app, host, or effective policy. The display mirrors the controls below.

Session state
Break-glass rule
Policy breakers to test
POLICY DRAFT0 / 4 breakers
No negative test is specified.

Choose the routes this job does not need. A running session may still hold the older policy.

Why it is better: policy intent, session inheritance, escape behavior, and test evidence stay separate. The completed panel says TEST CARD READY. It does not say the sandbox passed.

Sources read, not vibes

Open the source log
  1. GitHub Changelog, "Local sandboxing in the GitHub Copilot app": release date, public-preview status, project scope, policy groups, fail-closed behavior, defaults, and session timing.
  2. GitHub Docs, "Configuring local sandboxing in the GitHub Copilot app": default filesystem, network, and credential access; platform limits; restart behavior; session overrides; and outside-sandbox choices.
  3. Zed, "Sandboxing": operating-system enforcement, tool coverage, privilege prompts, platform implementations, known boundary gaps, and defense-in-depth limits.
  4. Visual Studio Code 1.139 release notes: current scan for agent-session and remote Dev Container changes. This source informed the placement check, not the GitHub Copilot app claims.
  5. GitHub Trending, September 23, 2026 and Hacker News front page: discovery scans for current developer-tool and agent signals. Neither verifies the product behavior above.

Source boundary: GitHub documents its own public-preview controls. Zed documents a separate editor and implementation, so it supports only the broader lesson about tool coverage and escape paths. The panel is a planning aid. Real proof requires a pinned build, effective policy, restarted session, and captured negative-test output.