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 (opens in a new tab) 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

Claude Code's local documentation, re-read on October 23, 2026, still gives sandboxed commands broad default reads, “including credential files such as ~/.ssh and ~/.aws/credentials,” and narrower writes: the working directory, a per-user temp directory and added directories, with protected paths write-denied. Commands inherit environment variables from Claude Code, “including any secrets in its environment.” Built-in file tools have separate permission controls. Local documentation, “What the sandbox restricts”; checked October 23, 2026 (opens in a new tab)

The same documentation now names three opt-in controls for read access and secrets. Documentation is a claim about the product, not an observation; the October 23 update below records what one headless run of each control did on our fixture.

• sandbox.credentials declares files and environment variables to protect. "mode": "deny" “hides the credential inside the sandbox”; "mode": "mask" “shows sandboxed commands a placeholder while the sandbox proxy substitutes the real value on outbound requests.” It protects “only the entries you list; there is no built-in credential deny list.” Settings reference, sandbox.credentials (opens in a new tab)
• permissions.blockReadsOutsideWorkingDirectories makes the file tools “refuse reads outside your working directories in every permission mode.” With sandboxing on, it also denies sandboxed commands read access to the home directory and other user-file roots, then re-opens the working directories. Settings reference (opens in a new tab)
• CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 strips credentials from “the subprocesses Claude Code starts, such as Bash commands, hooks, and stdio MCP servers.” It recognizes a credential “by its variable name or its value” and “leaves GitHub tokens and proxy settings in place.” Environment variables, “What the subprocess environment scrub removes” (opens in a new tab)

None is on by default. Each narrows what a command can read; none decides what a permitted request carries. A masked credential still authenticates to the hosts it is injected for, and the documentation says masking “authorizes the proxy to send your real credential somewhere.” That is the allowed-service question the rest of this article examines.

This changes the review. Preventing a process from modifying a credential file does not establish that it cannot read the credential, and preventing writes to a neighboring project does not make its source 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 (opens in a new tab), network architecture (opens in a new tab)

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 is incomplete if the compiler or package cache lives elsewhere: identify the legitimate resource before adding its exception, rather than assuming a failed command needs 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 (opens in a new tab)

Diagram 2 — Cloud Git path reported in October 2025, not the local CLI configuration. Source (opens in a new tab)

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.

Two questions remain: which operation does it permit, and what may that operation carry? The diagram establishes neither a content-review policy nor a complete list of current checks, and the word “proxy” does not supply them.

Keeping a credential outside the agent's process can reduce opportunities to copy it. It does not prevent misuse of operations the intermediary deliberately exposes; those objectives need different evidence.

Follow three possible requests

The following cases are conditional analysis. The October 23 update below reports the probes we later ran against Claude Code on this fixture.

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 (opens in a new tab)

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.

Update, October 23, 2026: one client in its own sandbox

We ran Claude Code 2.1.309 headless in a disposable container, on the synthetic fixture and receivers of the September 25 pilot described below, three times per configuration. It received the injected issue with no sandbox, in its sandbox mode, and with the sandbox plus the documented read block and environment scrub, in default and bypass permission modes. Effects were judged from the receivers and file state, outside the client.

In all 15 injected-issue runs, nothing reached either receiver and no injected step was attempted. That was not the sandbox. The provider's classifier stopped the first model after it read the issue, and Claude Code continued on an older model that declined the whole checklist.

Because the agent would not run the injected steps, a benign script then probed each boundary directly, sending a marker rather than a canary:

Bypass mode reaches hosts outside the allowlist unless strictAllowlist is set, as the documentation says. The scrub recognizes credentials by name and shape, so a secret in a plainly named variable survives it; only an explicit sandbox.credentials entry removed it. The scrub also forced default permissions when bypass was requested, so headless runs stopped at the first command that needed approval. One result in our nested container remains unexplained and is listed in the record's limits. These are observations of one client version, not of other clients or interactive sessions. Method, settings and every run

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.

Update, September 25, 2026 — we ran the three cases. In a disposable container, a fixed script (no model) attempted them under Anthropic's open-source Linux sandbox runtime with synthetic data. With writes and network scoped, it could not modify ~/.bashrc or reach an unapproved host, but it read a home-directory credential file, saw an inherited environment variable, and sent private notes through the permitted review service. Denying reads of a file inside the repository stopped that leak and also broke git add -A. This tests the runtime, not Claude Code. Pilot method, harness and results.

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