Pimp My IDEBack to the garage

Agent safety / 13 Oct 2026

Sandbox policy cutout

A sandbox badge says where a command started. A useful receipt says what it could read, where it could connect, which credentials it could spend, and what happened when enforcement failed.

Local agentsPolicy before autonomyBlocked-action drill

The release worth reading

GitHub made local sandboxing generally available for Copilot CLI, the Copilot app, and VS Code sessions that use Agent Host. The release says sandbox policy can restrict filesystem, network, credentials, local MCP servers, and language servers. It also says model choice and tool isolation are separate concerns.[1]

That last point matters. A smarter model does not create a smaller blast radius. The execution policy does.

Do not ask whether the agent is sandboxed. Ask what the sandbox denies.

Read the defaults, not the badge

GitHub's documentation says local sandboxing is off by default. Without it, shell commands run with the user's access to files, networks, and credentials. The app's default sandbox policy still allows outbound internet, local network access, Git credentials, and GitHub CLI credentials. Copilot CLI starts with local network access off, but outbound connections, Git authentication, GitHub CLI authentication, sandboxed MCP servers, and sandboxed language servers are on by default.[2][3]

The app and CLI keep separate settings. A policy change applies to a new or restarted app session, not the shell that is already running. A configured policy summary is not proof that the sandbox started. GitHub tells operators to inspect the effective CLI policy with /sandbox policy.

Local containment is not a tiny virtual machine

GitHub describes its local sandbox as lighter-weight operating-system containment. It is not a separate virtual machine or container. On macOS it uses Seatbelt. On Linux it uses bubblewrap. On Windows it uses a supported process-container backend. Platform behavior differs, especially around localhost and proxy enforcement.[2]

There is another boundary. GitHub says built-in CLI file tools run inside the CLI process, outside the operating-system sandbox. Those tools check the policy in code on a best-effort basis. Remote MCP servers are never placed inside the local sandbox. Put those facts in the threat model instead of letting the word "sandbox" erase them.

MXC, the open-source system under the feature, exposes several backends and policy types. Its own README warns that audit mode disables sandbox security for the workload being inspected. Diagnostics are useful, but an audit command is not a safe way to run untrusted code.[4]

Hosted and local answer different questions

A current Agent37 launch offers a useful contrast. Its site says each customer workload runs in a gVisor sandbox with a separate filesystem and a public-internet-only egress policy. It also sells persistence, backups, lifecycle controls, and per-sandbox spend limits.[5]

Those are vendor claims, not results we reproduced. They describe tenant separation and fleet operations. A local policy describes what commands can touch on one workstation. Teams may need both, but the controls are not interchangeable.

Make one denial observable

Write a harmless blocked-action drill before granting more autonomy. Try to read a denied fixture outside the workspace. Try an unapproved hostname. Try a placeholder credential against the wrong destination. Record the command, effective policy, denial, operating system, client version, and session restart.

Then test failure behavior. If the host cannot enforce the requested policy, does the run stop? GitHub documents a managed failIfUnavailable setting for the CLI. Without a fail-closed requirement, an unsupported host can leave a saved preference intact while the current session runs without local sandboxing. That is a rollout decision, not an implementation footnote.

Policy cutout

A normal settings panel hides the relationship between permissions and proof. This cutout routes four independent policy records into one review sheet. It does not claim the sandbox ran.

Review-sheet circuits
Filesystem record
Network record
Credential record
Failure record
Review sheetNo sections selected

Select the records this template must request.

Structure incomplete

This control chooses fields for a review sheet. It does not inspect a host or prove enforcement.

Four adoption checks

01

Separate saved from effective

Capture the settings you requested and the policy the current host enforced.

02

Test each surface

App, CLI, local MCP, language server, built-in tool, and remote MCP can cross different boundaries.

03

Exercise the stop

Use a harmless fixture to prove an unsupported policy or blocked action stops instead of widening access.

04

Review every bypass

A per-command retry outside the sandbox is a new execution mode. Log it as one.

Copy this rollout drill

  1. Record the operating system, client version, surface, project, and current session ID.
  2. Save the requested filesystem, network, credential, subprocess, and bypass settings.
  3. Restart the session. Export or capture the effective policy.
  4. Run one denied-path check and one denied-destination check against disposable fixtures.
  5. Remove one host prerequisite in a test environment and confirm the required failure mode.
  6. Keep the commands, exit states, policy output, and review decision under one drill ID.

Sources read

  1. GitHub changelog: local sandboxing generally available. The release names supported surfaces, policy dimensions, MXC, enterprise enforcement, and the split between model execution and tool isolation.
  2. GitHub Docs: cloud and local sandboxes. The documentation describes defaults, platform backends, in-process tools, unsupported-host behavior, and local-versus-cloud isolation.
  3. GitHub Docs: configuring local sandbox settings. The guide documents app and CLI defaults, policy restarts, credential masking, host rules, bypass, and effective-policy inspection.
  4. Microsoft eXecution Container repository. The README documents supported backends, policy types, SDKs, diagnostics, and the audit-mode warning.
  5. Agent37 product and security pages and Launch HN item 50059096. These pages supplied the hosted-sandbox comparison and publisher-reported pricing and architecture claims.

Evidence boundary: this dispatch reads current product documentation and vendor pages. We did not install Copilot, build MXC, or provision an Agent37 sandbox. The cutout produces a review-sheet template. It does not test a host, verify containment, or approve a rollout.