Locking down Claude Code sandbox egress with strictAllowlist

One hostname is not enough

This is the part I could not grasp by reading docs alone.

I had naively assumed that "to push to GitHub, allow github.com; to call the Anthropic API, allow api.anthropic.com" would be enough. The recon results said otherwise.

A single "operation" fanned out to several hosts. That npm serves tarballs from a different host, and that git sometimes reaches codeload.github.com, were things I only noticed by watching the connections directly.

In short, the very premise of "one host per service" was wrong. Had I written the allowlist under that assumption, that midnight stall would have reproduced indefinitely.

Resisting the wildcard temptation

Adding a host every time something leaks is tedious. It is tempting to settle it with a broad wildcard like *.amazonaws.com.

I started to write exactly that. Then my hand stopped. Allowing an entire cloud that happens to host a CDN's tarballs also opens a path to countless unrelated buckets and endpoints. The one line dilutes the reason you added strictAllowlist in the first place.

In the end I chose to accept the occasional miss over a broad wildcard. Fill the allowlist with concrete hostnames, and when it grows, re-run recon and add the diff. I strongly recommend this over convenience wildcards: a decision not to trade away the "safe default" intent for operational ease.

Three steps before you enable it

Rather than switching the setting on in a hurry, this order cut down on accidents.

1. Run the pipeline once through egress-recon.sh without strictAllowlist, recording every destination
2. Drop the recorded hostnames into the allowlist and enable strictAllowlist
3. Watch each run with guard-run.sh, and fail loudly the moment an unexpected connection appears

Just inserting these three steps replaces "stalls silently in production" with "observed once up front and eliminated."

Config, and making the deny observable

Put the discovered hosts into config. Confirm the exact key names against your version's settings schema (strictAllowlist is new, so the details may still change). I keep this in .claude/settings.json.

// .claude/settings.json (example)
{
  "sandbox": {
    "network": {
      "strictAllowlist": true,
      "allow": [
        "api.anthropic.com",
        "github.com",
        "codeload.github.com",
        "registry.npmjs.org"
      ]
    }
  }
}

On top of that, add observability so a deny is not mistaken for a network outage. Wrap the pipeline once with a thin harness that records, on every run, whether it reached a host outside expectations.

#!/usr/bin/env bash
# guard-run.sh — reconcile hosts touched during a run against the allowlist
set -euo pipefail
ALLOW_FILE="${1:?pass an allowlist file}"; shift
SEEN="$(mktemp)"; trap 'rm -f "$SEEN"' EXIT
 
# use egress-recon.sh inside, collecting destinations
./egress-recon.sh "$@" | awk '{print $1}' | grep -vE '^\(' | sort -u > "$SEEN"
 
# report only destinations not on the allowlist
UNKNOWN="$(comm -23 "$SEEN" <(sort -u "$ALLOW_FILE") || true)"
if [ -n "$UNKNOWN" ]; then
  echo "⚠️ detected connections outside the allowlist:" >&2
  echo "$UNKNOWN" >&2
  # in automation, prefer a loud failure over a silent one
  exit 1
fi
echo "✅ all destinations were within the allowlist"

Once this was in place, I could state in a single log line whether a stall was "the network's fault" or "a gap in the allowlist." The disappearance of pointless re-runs was the change I felt most in my body.

Judgment calls that paid off

A few situational lessons that stuck after a few weeks of running it.

The tighter the lock, the quieter the failure. That is exactly why two things became the crux: observing the hosts you really touch before you lock, and making the deny clearly visible after you lock. The effort before and after the switch is worth more than the single line that enables it.

I am still learning as I run this. If it spares someone taking automation toward a safer default one detour, I would be glad. Thank you for reading.