What does your agent's sandbox actually contain?

A coding agent needs to fix a parser, fetch dependencies, run tests and leave a patch for review. It does not need your unrelated files, another project's credentials or permission to publish the repository elsewhere.

A sandbox could let it do the useful work without asking you to approve every compiler invocation. The design question is which resources you place inside that freedom—and what authority remains available through the services you permit.

Anthropic's October 20, 2025 account describes local Bash containment and a separate cloud Git proxy. Historical engineering account Do not infer a local credential arrangement from a cloud design.

We will use those contexts to examine three different events: reading a protected file, contacting a forbidden destination and sending the wrong material through an allowed service. A boundary can prevent one while permitting another.

Read access and write access answer different questions

The local documentation checked on September 15, 2026 describes broadly allowed reads, including credential files unless restricted, and narrower writes covering the working directory, added directories and session temporary storage, with exceptions. Bash subprocesses inherit environment variables by default. Built-in file tools have separate permission controls. Local documentation, “Filesystem isolation” and “Scope”; checked September 15, 2026

This distinction changes the review. Preventing a process from modifying a credential file does not establish that it cannot read the credential. Preventing writes to a neighboring project does not establish that its source code is invisible.

Diagram 1 — Local Bash boundary: current documented scope, simplified. Path exceptions and settings must be inspected for a real session. The network-proxy arrangement is described in the historical report. Local scope, network architecture

Open full-size diagram

• Bash and descendants → host files: reads are broad unless restricted.
• Bash and descendants → workspace and other permitted paths: configured writes.
• Bash and descendants → network proxy → permitted remote domains.
• Built-in file tools → separate permission controls.

For the parser task, a proposed policy could allow reads of the checkout and required toolchain, writes to the checkout and build scratch space, and dependency retrieval through selected endpoints. Unrelated private documents would be excluded explicitly. This is our design proposal, not the product's default or a tested configuration.

The goal is to preserve compilation and debugging while removing irrelevant exposure. Denying every file outside the checkout would be an incomplete prescription if the compiler or package cache lives elsewhere. Identify the legitimate resource before adding its exception; do not assume every failed command requires unrestricted execution.

A remote operation has another boundary

The reported cloud proxy checks Git requests, including the configured push branch, using a scoped credential from the sandbox. It supplies downstream authentication; sensitive Git credentials and signing keys remain outside. Historical cloud section

Diagram 2 — Cloud Git path reported in October 2025, not the local CLI configuration. Source

Open full-size diagram

1. The sandboxed Git client holds a scoped credential.
2. The Git proxy checks the requested interaction.
3. The proxy uses a downstream credential held outside the sandbox to reach GitHub.

This describes the reported October 2025 cloud design, not the local CLI configuration.

The useful distinction is between possessing a general credential and being able to request a restricted operation through an intermediary. A proxy can provide an enforcement point beyond deciding which hostname is reachable.

But two further questions remain: which operation does it permit, and what information may that operation carry? The diagram does not establish a content-review policy or a complete list of current checks. We should not infer either from the word “proxy.”

Keeping a credential outside the agent's process can reduce opportunities to copy that credential. It does not, by itself, prevent misuse of operations the intermediary deliberately exposes. Those are different objectives, requiring different evidence.

Follow three possible requests

The following cases are conditional analysis, not probes against Claude Code.

1. Read an unrelated private file. Suppose the parser task encounters instructions asking it to include a personal document in a debugging bundle. If the relevant read is denied across the tools the agent can use, that route stops before the data reaches the bundle. A write-only restriction cannot establish the same result. Nor can blocking a disk path remove a copy already present in the conversation.

2. Send the bundle to an unapproved server. Suppose the file was legitimately available for another reason. If all relevant outbound routes enforce the destination restriction, a request to that server is denied. The agent may still produce a bad local artifact. Containment of transmission and correctness of work are separate findings.

3. Put the bundle in an allowed repository operation. Suppose the destination and operation are permitted, but the bundle contains unrelated private material. Domain, repository and branch checks could all succeed while the content violates the user's intended task. That is a counterexample to treating route approval as approval of everything carried along it; it is not a claimed bypass of the reported cloud service.

The runtime's own documentation distinguishes domain filtering from traffic inspection and warns about broad allowed services. Its repository is a separate implementation reference, not proof of a particular installed client's behavior. Runtime README, “Security Limitations,” pinned revision

The third case matters because no escape is necessary. The process can stay inside every assumed machine boundary and still make an inappropriate permitted request.

Preserve the patch workflow

For our narrow task, the initial deliverable could be a local patch and test evidence. If remote delivery is necessary, a proposed policy could restrict it to a designated review branch in the task repository. The receiving audience and actual diff belong in that decision. A branch in a private repository and a branch in a public repository are not interchangeable disclosure destinations.

Consider a rigorous counterexample to “just review the diff”: the approved commit changes a harmless line, but another transferred commit or generated artifact contains private data. Reviewing one representation is sufficient only if it covers the actual transfer. Establish the relationship between the inspected artifact and what is sent, including any intervening changes. A reviewer cannot approve content they were never shown.

This does not imply every local test needs human review. It suggests putting human judgment where the task genuinely requires interpretation of an external effect, while allowing bounded local iteration. The cost is extra work at that boundary; measure it before prescribing the same process for every job.

A legitimate cross-repository dependency update changes the policy. The agent may need to inspect two repositories and prepare coordinated changes. Restricting it to one would prevent completion. A useful alternative is explicitly scoped access to both, with separate delivery destinations and a decision about what information may move between them. “More access” must describe the added work, not merely remove an inconvenient restriction.

Complete the boundary review

Here is the review for the proposed parser workflow. These entries are design choices and required evidence, not settings claimed to be active.

A blocked action is useful evidence about one path under one configuration. A completed test is evidence about the tested behavior. Neither alone establishes that the entire agent session is contained or that its output is appropriate to publish.

Start by deciding what successful work requires. Then inspect where every additional capability comes from. The sandbox can make room for useful autonomy; the permitted services determine how far that autonomy reaches beyond the machine.

Source versions, claim boundaries and refresh requirements: supporting dossier.