A locked sandbox setting is not proof of a locked-down coding agent

GitHub added enterprise-managed sandbox policies to Copilot for JetBrains IDEs on September 8, 2026. Administrators can now set central restrictions for sandbox use, filesystem and network access, proxy behavior, developer-tool access, macOS Keychain access, and other local execution capabilities.

The feature closes a specific governance gap, but a locked setting is only configuration evidence. Before a wider rollout, a platform or security team should prove what one agent workflow can read, change, contact, and authenticate to—and what the client does when the sandbox cannot complete the task. This article separates the announced controls from the tests needed to trust their effective behavior.

What changed in JetBrains?

GitHub says managed restrictions take precedence over user settings. When a setting is centrally managed, Copilot locks the affected IDE control and identifies it as managed by the organization. The sandbox settings appear when the organization enables the Editor Preview feature flag or manages the setting that enables or disables the sandbox.

The same release adds enterprise policy diagnostics. GitHub describes them as a way to verify that policies are detected and enforced on a device. Both the managed sandbox and its JetBrains support are in public preview, so teams should expect the interface and behavior to change.

This is narrower than a general claim that local agent execution is safe. A sandbox policy controls a defined set of resources and capabilities. It does not establish that every dependency is necessary, every allowed host is trustworthy, or every operation inside the permitted boundary is correct.

Why is the effective policy different from the saved policy?

A coding agent needs enough local access to inspect a repository, edit files, run tools, and validate changes. GitHub's sandbox documentation shows how much behavior can sit behind a simple enabled state.

By default, local Copilot sandbox configuration grants read/write access to the current working directory. In a Git repository, it also grants read/write access to the repository's .git directory. Developer-tool access is on by default, which can expose package-manager configuration and caches for reading and shared build caches for writing. Outbound internet access and local-network access are also on by default.

Those defaults can be restricted by enterprise policy. The important point is that the effective boundary results from managed restrictions, user configuration, and automatic grants together. A visible policy file or a disabled control does not, by itself, show the final set of readable paths, writable paths, reachable hosts, or available credentials.

GitHub's CLI documentation makes this distinction explicit: saved sandbox settings and the effective filesystem policy are different views. The September JetBrains release adds policy diagnostics for the IDE, but the changelog does not publish independent enforcement results. BaristaLabs therefore recommends treating diagnostics as one item of evidence, not the whole acceptance test.

Which boundaries should a pilot test?

Start with one real but sanitized workflow. List the minimum repository paths, package sources, build tools, local services, external hosts, and credentials it needs. Then turn each requirement into an allowed case and pair it with a nearby denied case.

Filesystem: Let the agent read and edit a disposable repository fixture. Place a harmless marker file outside the allowed tree and ask the agent to read it, then to change it. Record the effective policy, the request, and the refusal. Include .git explicitly in the review because normal agent validation may need Git metadata even when the source working directory is tightly scoped.

Network: Permit only the package registry or test endpoint required by the workflow. Try a sanitized request to that destination, then a request to an unapproved public host and a local-network fixture. Test local access separately: blocking the internet does not prove that services on localhost or the LAN are unreachable.

Credentials: Verify that the workflow can use only the authentication material it needs. Git, GitHub CLI, developer-tool stores, and the macOS Keychain are separate exposure paths in GitHub's configuration model. Use disposable credentials and confirm that a denied credential cannot be retrieved or passed to a child process.

Tools and child processes: Run the compiler, test runner, package manager, MCP server, or language server that the workflow requires. Then try an unapproved executable or service. A sandbox that blocks every useful dependency is secure but unusable; a policy that quietly grants broad tool caches and credentials to make builds pass may be wider than the owner intended.

What should happen when the sandbox blocks required work?

Failure behavior is part of the boundary. GitHub's local sandbox documentation says the user-configured bypass option is on by default. When a command fails inside the sandbox, that setting can let the model request approval to run the command outside it. If bypass is off, the agent stops the task and reports the failure.

An enterprise deployment should decide which outcome is acceptable before the pilot. If the policy permits an escape prompt, test who can approve it, what the prompt reveals, how narrowly the approval applies, and what record remains. If the required posture is fail-closed, confirm that the client stops rather than silently using another execution path.

Do not infer this behavior from a label such as “sandbox enabled.” Ask the agent to perform a harmless operation that the pilot policy deliberately blocks. Preserve the client version, effective diagnostics, action, result, and any approval event. That negative case is stronger evidence than a successful build because it exercises the boundary itself.

When is the JetBrains sandbox ready to expand?

Expand beyond the pilot only when the required workflow succeeds with the minimum intended access and every denied case fails in the expected way. Repeat the checks on each supported operating system in scope because keychain, proxy, and sandbox implementation details differ. Record the exact JetBrains product, Copilot plugin version, policy source, user group, operating system, and test time.

Pause when the effective policy cannot be inspected, an out-of-scope path or host remains reachable, a blocked command can leave the sandbox without the intended approval, or the workflow depends on broad credential access that nobody owns. Public preview status is another reason to rerun the cases after client or policy changes rather than treating one pass as permanent certification.

The September release changes a practical adoption decision. In August, the documented JetBrains managed-settings boundary did not include the sandbox; now GitHub says administrators can manage it centrally and inspect policy diagnostics. That is enough to run a more complete governed pilot. It is not enough to skip one.

BaristaLabs can help review one managed sandbox pilot from required dependencies through positive and negative device tests.

Sources

• GitHub Changelog, “Enterprise-managed sandbox in Copilot for JetBrains”, published September 8, 2026.
• GitHub Docs, “Configuring local sandbox settings”, accessed September 9, 2026.
• GitHub Docs, “Enterprise managed settings”, accessed September 9, 2026.