Claude Code Stops One Install From Widening the Whole Job

One dependency install no longer has to widen the network boundary for the rest of a Claude Code job. On September 14, 2026, Claude Code 2.1.271 added command-scoped network access to sandboxed auto mode, so the registry host approved for an install can close again when that command ends.

What actually changed

Claude Code has two different safety layers here, and the change makes sense only when you separate them.

Auto mode decides whether a tool call may run. A separate classifier reviews the action against your request. The older Claude Code auto-mode guide covers that general permission model.

The sandbox decides what a running shell command may touch. It limits file writes and routes network traffic through a proxy that checks the destination host.

Version 2.1.271 connects those layers more tightly. A Bash, PowerShell, or Monitor call can now carry an allowed_domains list in sandboxed auto mode. Claude Code reviews the command and the hosts it needs together. Those hosts open for that command alone, and the sandbox refuses other hosts. The release entry is explicit about that scope.

That snake-case field is not the same thing as sandbox.network.allowedDomains in settings.json.

Before this release, approving a new sandbox host could create a wider grant. A manual approval lasts for the rest of the current session, and a saved approval can persist into later sessions. Auto mode can also cache its decision about a host and port. The new field changes the runtime reach, even when a classifier verdict is reused: the network opening belongs to the current command.

This only affects the combination named in the release: auto mode, sandboxing, and Bash, PowerShell, or Monitor. Manual sessions, unsandboxed commands, built-in file tools, and jobs that never touch the network do not gain this boundary.

The business math is permission scope, not a cheaper plan

No Claude Code seat price changed here. Anthropic did not announce a separate fee, SKU, or performance result for command-scoped domains.

The useful equation is the size of the authorization you must defend:

standing grant = approved host × every later command that can reuse it

command-scoped grant = approved host × the reviewed command

Take a dependency install that needs registry.npmjs.org. The old operational choice was often awkward: stop an unattended job for a network decision, or pre-allow the registry and accept that every later sandboxed command could reach it. Now auto mode can approve that host with the install itself, then close it before the build, test, packaging, and review steps continue.

That changes two budget lines even though it does not change the subscription invoice. Platform teams have fewer standing exceptions to design and clean up. Security reviewers can assess a command-and-host pair instead of treating the host as available to the remaining job.

There is still compute cost in the review path. On Enterprise and usage-metered provider accounts named in Anthropic's permission-mode documentation, classifier checks count toward token usage and add a round trip. The release provides no timing benchmark, and no timed run was performed for this piece, so there is no honest seconds-saved claim to make.

Who can use this tomorrow

A solo founder running a long build job

A founder can let Claude Code restore the locked packages for a SaaS repository, then continue through tests and code review without leaving the public registry open to those later steps. The payoff is a job that keeps moving without turning one necessary download into standing egress for the whole session.

An agency tech lead moving between client repositories

An agency can keep a client's package host attached to the install that needs it instead of saving another project-level exception. That reduces permission cleanup and makes it harder for a command in the next phase of the job to send client code to a host that was opened only for dependency work.

A platform or security lead governing unattended agents

A platform team can keep organization-wide deny rules and managed domain locks in place, while routine commands request narrower access inside that policy. The review record becomes easier to explain: this command needed this host for this action. It is not proof that the host was safe for everything the agent did later.

A build engineer separating install from test

A build engineer can make package restore a networked phase and the test suite an offline phase. If a compromised test or unexpected script tries to call the registry after the install finishes, it does not inherit the earlier command's opening unless another standing rule already allows that host.

A bounded dependency-install setup

The cleanest way to see the change is a repository with a committed package-lock.json and dependencies that resolve through one known registry. npm documents npm ci for clean automated installs: it requires a lockfile, fails when the lock and manifest disagree, removes an existing node_modules, and leaves the manifest and lockfile unchanged. The --ignore-scripts option stops package lifecycle scripts during that install. Those behaviors are documented by npm.

1. 1

   Confirm the Claude Code version

   Run the version check from the changelog:

   claude --version

   Use 2.1.271 or a later build that contains the feature.

2. 2

   Start auto mode inside a fail-closed sandbox

   For one session, combine auto mode with a sandbox that must start successfully and cannot retry a blocked command outside the boundary:

   claude --permission-mode auto --settings '{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}'

   This uses the documented --permission-mode, --settings, failIfUnavailable, and allowUnsandboxedCommands controls. On macOS the sandbox is built in. Linux and WSL2 need bubblewrap and socat; native Windows is not supported by the built-in sandbox. The setup and platform limits are in the sandbox guide.

3. 3

   Give the install a narrow job description

   Send this as the task, replacing the registry host when your lockfile uses a private registry:

   Install exactly the dependencies in package-lock.json with npm ci --ignore-scripts. This command may reach only registry.npmjs.org. Do not save that host to project or user settings. After the install finishes, run the test suite as a separate command with no network access. Stop if the install requires any other host.

   You do not type the allowed_domains field yourself. Claude Code builds the shell tool call, and auto mode reviews the requested host with that call.

4. 4

   Check that the next step starts closed

   Open /sandbox, inspect the resolved Config tab, and make sure registry.npmjs.org is not already present in a standing allowedDomains or saved WebFetch rule. Then let the separate test command run. A network attempt from that later command should need its own reviewed domain set or be refused by the existing policy.

The detail people get wrong is the lockfile. A package lock can point at a private registry, a Git host, or a direct tarball URL. Naming only registry.npmjs.org does not make those dependencies appear there. Review the actual resolved hosts, keep the list exact, and let the command stop when the lock asks for something unexpected.

What this does not solve

Command-scoped network access narrows when a host is reachable. It does not prove that the host is trustworthy, inspect every encrypted request, or make downloaded code safe.

Anthropic's built-in proxy filters by hostname and does not inspect TLS contents by default. Inside the approved command, a process can reach any permitted path on that host. Child processes spawned by the command share the sandbox boundary, which is why npm ci --ignore-scripts is a useful teaching example: it removes package lifecycle scripts from the install step, but it does not audit the packages you download.

Managed policy still sits above the feature. strictAllowlist can deny anything outside the configured list, and allowManagedDomainsOnly can restrict allowed hosts to managed settings. Explicit deny rules continue to block. Per-command domains do not punch through those controls.

The unsandboxed retry is another real edge. Claude Code normally has an escape hatch for commands the sandbox cannot run. Setting allowUnsandboxedCommands to false matters because it prevents a failed install from quietly changing the question from “which host may this command reach?” to “may this command run outside the sandbox?”

What to do on Monday

Act this week if you run Claude Code in auto mode for dependency updates, overnight maintenance, or unattended build jobs and you currently keep package registries in a broad sandbox allowlist. This feature gives you a reason to test whether those standing entries can be removed.

Wait if your organization uses a managed network policy that intentionally pre-approves the registry for every command, or if an outer container or CI runner already enforces a tighter per-process egress rule. The new field may still add defense in depth, but it does not replace the boundary you already operate.

You are unaffected if you do not use auto mode with sandboxing, or if the work never calls Bash, PowerShell, or Monitor over the network.

The Monday move is small: confirm Claude Code 2.1.271 or newer, choose one locked dependency install, start it in auto mode with a fail-closed sandbox, name only the expected registry host, then prove the following test command cannot reuse that network path. Remove a standing registry exception only after that check passes in your own environment.

If you want the next platform change translated into the workflow it changes, join the newsletter.