[BUG] /sandbox Config shows "Network Restrictions" allowlist that doesn't restrict when autoAllowBashIfSandboxed is true

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Env: Claude Code 2.1.224, Ubuntu 24.04 LTS on WSL2, bubblewrap + socat installed, sandbox enabled.

Summary: With sandbox.network.allowedDomains set and sandbox Mode = auto-allow, /sandbox → Config reports Network Restrictions — Allowed: <domains>, but non-listed domains are reachable with neither a prompt nor a block.

What Should Happen?

Suggested fix (either):

Relabel the Config tab, e.g. Pre-approved domains (no prompt) — other domains: allowed without prompting, or
Surface a warning in /sandbox when allowedDomains is set, auto-allow is on, and allowManagedDomainsOnly is not — since that combination makes the list decorative.

Error Messages/Logs

Steps to Reproduce

• User settings: sandbox.enabled: true, sandbox.network.allowedDomains: "github.com","pypi.org","files.pythonhosted.org","registry.npmjs.org"]
• /sandbox → Mode → auto-allow (writes autoAllowBashIfSandboxed: true)
• Restart Claude Code
• /sandbox → Config displays Network Restrictions — Allowed: <the four domains>
• Have Claude run: curl -sS -o /dev/null -w '%{http_code}\n' --max-time 8 https://www.cloudflare.com

Expected: blocked, or a prompt. Actual: 200, silently.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.224

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

The sandbox is otherwise working — this is not a broken install:

• readlink /proc/self/ns/net inside sandbox ≠ host → network namespace isolation present

curl --noproxy '*' https://www.cloudflare.com → Could not resolve host → direct egress blocked; the proxy is the only exit

• filesystem.denyRead enforced: python3 -c "open('<denied path>').read()" blocked

So egress is genuinely proxy-only, and the proxy permits non-allowlisted hosts.

Root cause (documented, composed): allowedDomains is prompt-avoidance, not a block; autoAllowBashIfSandboxed: true suppresses the prompt. Blocking requires allowManagedDomainsOnly, which is managed-settings-only. Each setting behaves as documented; together they produce an allowlist that permits everything.