Sandbox network egress allowlist not consistently enforced (non-allowlisted hosts intermittently reachable)

Title: Sandbox network egress allowlist not consistently enforced (non-allowlisted hosts intermittently reachable)

Body:

Summary

The sandboxed Bash tool's network allowlist (the allowedHosts list shown in the tool's own system description) does not consistently block egress to hosts outside that list. In repeated testing, non-allowlisted hosts returned real HTTP responses (not a blocked/proxy-error response) from inside the default sandbox.

Environment

• Claude Code version: 2.1.238 (native install, macOS)
• Sandbox: default (permissions.sandbox: {enabled: true, failIfUnavailable: true, autoAllowBashIfSandboxed: true} in ~/.claude/settings.json)
• Configured allowedHosts for this session included a fixed short list (e.g. developers.cloudflare.com, downloads.claude.ai, github.com, raw.githubusercontent.com, etc.) — did not include example.com, api.cloudflare.com, or keychecker.trufflesecurity.com.

Repro

From inside a default-sandboxed Bash call:

curl -sS -m 8 -o /dev/null -w "HTTP %{http_code}\n" https://example.com
curl -sS -m 8 -o /dev/null -w "HTTP %{http_code}\n" https://api.cloudflare.com/client/v4
curl -sS -m 8 -o /dev/null -w "HTTP %{http_code}\n" https://keychecker.trufflesecurity.com

Expected

All three requests fail/blocked (connection refused, proxy error, or similar), since none of these hosts are in the sandbox's allowedHosts.

Actual

All three returned real HTTP responses from the actual remote service (200, 404, 200 respectively — not a proxy block page). Traffic appears to route through a local CONNECT proxy; DNS-level tools (dig/nslookup) are separately blocked (raw socket bind denied), but the HTTP(S) CONNECT proxy itself passed every non-allowlisted host tested.

Re-tested in a separate session on the same machine and found the behavior is intermittent, not constant: a single isolated curl to a non-allowlisted host correctly returned a blocked result, but 3 back-to-back calls to non-allowlisted hosts within the same tool invocation all leaked through. This suggests a possible race/initialization-timing issue in how the per-call network filter gets applied, worsening under rapid/batched calls (e.g. inside a browser_batch-style multi-action call).

Impact

Any documentation or workflow that assumes the sandbox's network allowlist is a hard boundary (e.g. relying on it to prevent a sandboxed command from reaching an unintended host, or assuming a non-allowlisted host's unreachability as a feature — such as gating secret-scanning verification calls behind sandbox network restriction) cannot currently rely on that assumption holding consistently.

Additional context

Not filed with any exfiltrated data or security-sensitive specifics beyond what's above — this is a reachability/enforcement-consistency report only.