Claude Code Strict Network Allowlist Sandbox Checklist

Claude Code 2.1.219: lock sandbox network egress with a strict allowlist

Quick answer

Claude Code v2.1.219 adds sandbox.network.strictAllowlist: non-allowlisted hosts can be denied for sandboxed commands without first falling back to a permission prompt. That makes a network policy testable, but it does not make a coding-agent session network-free. Start with a small list of hosts required by one low-risk repository, prove both an allowed install and a blocked destination, then canary the policy. Keep MCP servers, hooks, WebFetch, WebSearch, and unsandboxed commands in a separate threat model.

The release was published on July 24, 2026. v2.1.220, published July 25, contains bug fixes and reliability improvements; it does not replace the v2.1.219 release note as the source for this setting.

Who this is for

This is for an indie developer or small engineering team running Claude Code against repositories that need ordinary package installs or API calls, but should not let sandboxed Bash commands contact arbitrary internet hosts. It is a rollout guide, not a claim that a domain list is a full data-loss-prevention system.

If the repository is untrusted or the agent can read valuable credentials, first use the broader AI coding-agent sandbox checklist. If you are upgrading the earlier Claude Code sandbox changes, keep its filesystem and worktree regressions separate from this network-policy change: Claude Code 2.1.216 sandbox and worktree boundaries.

What changed, and its boundary

Anthropic's v2.1.219 release says that sandbox.network.strictAllowlist denies non-allowlisted hosts for sandboxed commands without prompting. Claude Code's sandbox documentation explains the important contrast: in auto-allow mode, a command that needs a non-allowed host normally falls back to the regular permission flow. Strict allowlisting changes that fallback into a deny for the sandboxed-command path.

That scope matters. Anthropic's own v2.1.219 settings examples show sandbox.network.allowedDomains, and their README says the sandbox property applies only to the Bash tool—not to Read, Write, WebSearch, WebFetch, MCPs, hooks, or internal commands. Treat those surfaces as separate controls. Do not tell yourself that a green Bash deny test proves that an MCP server cannot reach the same host.

Build the smallest useful egress inventory

Start from observed calls in one repository, not a generic list copied from the internet. Separate hosts by why a sandboxed Bash command needs them.

Class	Example question	Default action
Build input	Does `npm ci` need this registry?	Allow only the exact registry host needed by the project
Runtime test	Does one test call a documented staging API?	Prefer a fixture; otherwise allow a dedicated non-production host
Source retrieval	Does a reproducible script download a pinned public artifact?	Allow only for the test that proves its checksum and provenance
Human-only action	Is this a deploy, payment, production admin, or secret rotation endpoint?	Do not add it to the agent's sandbox allowlist
Unknown	Can nobody explain the destination?	Keep it denied and investigate before changing policy

For a compatible v2.1.219-or-newer settings schema, the setting belongs under sandbox.network alongside allowedDomains. Keep the list short and reviewable:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": false,
    "network": {
      "strictAllowlist": true,
      "allowedDomains": [
        "registry.npmjs.org",
        "api.github.com"
      ]
    }
  }
}

This is a policy shape, not a universal host list. Verify the exact settings file and precedence for your installation in the current Claude Code settings reference. If the client warns that a property is unrecognized, stop: an ignored setting is not a security control.

Run a six-case acceptance test

Use disposable credentials or fixtures. Do not test the deny path against a production endpoint.

Version gate. Confirm the client is v2.1.219 or newer and reopen the session after changing settings.
Allowed dependency gate. Run the smallest install or fetch that needs a documented allowed host; record the command, host, exit status, and lockfile result.
Blocked-host gate. Attempt a harmless request to a deliberately non-allowlisted test destination. It must be denied rather than silently switching to a prompt-driven or unsandboxed path.
No-network gate. Run the normal unit-test path with network disabled in the test itself. It should still pass, proving that routine verification does not accidentally depend on the allowlist.
MCP boundary gate. Inventory enabled MCP servers and their network permissions separately. The Bash sandbox result does not cover them.
Rollback gate. Restore the prior reviewed settings in a disposable workspace and confirm the known-good developer workflow returns before widening the canary.

A useful rollout record is deliberately small:

strict_network_canary:
  client_version: "2.1.219 or newer"
  repository: "low-risk, no production credentials"
  allowed_hosts: ["registry.npmjs.org", "api.github.com"]
  proved_allowed: "clean install completed"
  proved_denied: "non-allowlisted test host was denied"
  separate_mcp_review: "complete"
  owner: "named maintainer"
  rollback: "restore prior reviewed settings"
  promotion_gate: "all six cases recorded; no unexplained destination"

Common mistakes

Allowlisting a whole business domain. A broader suffix may cover paths or services your build never needs. Start from one exact required host and add only evidence-backed exceptions.

Using a prompt as evidence of enforcement. The point of the new setting is that the non-allowlisted sandboxed path is denied without the ordinary permission fallback. Record the observed deny result.

Expanding the list to fix a broken test. First identify whether the test can use a fixture, a local registry mirror, or a staging endpoint. A failed external call is not automatically a policy exception.

Confusing the Bash sandbox with every agent action. MCP servers, hooks, and web tools remain outside the sandbox-property boundary documented by Anthropic. Review their credentials and egress independently.

FAQ

Does strict allowlisting block every network request Claude Code can make?

No. The release describes sandboxed commands, and Anthropic's settings examples describe the sandbox property as applying to the Bash tool. It is useful egress reduction for that path, not a complete agent-network boundary.

Should I allow my production API so the agent can run integration tests?

Usually no. Prefer fixtures, a dedicated staging service, or a human-run deployment verification. A production endpoint mixes a network exception with valuable data and side effects.

Can I roll this out with the new nested-subagent defaults?

Keep the changes separate. v2.1.219 also changes nested-subagent behavior; use the subagent concurrency and budget checklist for that operational decision. One canary should change one policy dimension at a time.