sandbox.excludedCommands does not actually exempt listed commands from sandbox network enforcement

Summary

Per the Claude Code sandboxing docs, commands listed in sandbox.excludedCommands should run entirely outside the sandbox with full host access (no proxy, no filesystem restrictions). In practice on macOS, listed commands still have sandbox network enforcement applied — direct (non-proxied) socket connections are blocked, preventing any tool that doesn't honor HTTP(S)_PROXY env vars from working.

Environment

• Claude Code: 2.1.119
• OS: macOS (Darwin 25.3.0, arm64)
• Sandbox backend: Seatbelt

Configuration

.claude/settings.local.json:

{
  "sandbox": {
    "excludedCommands": ["bin/duckdb_query", "./bin/duckdb_query", "duckdb"],
    "network": {
      "allowedDomains": [
        "extensions.duckdb.org", "*.duckdb.org",
        "*.motherduck.com", "motherduck.com", "api.motherduck.com"
      ]
    }
  }
}

~/.claude/settings.json has a sandbox block with enabled: true and filesystem rules but no excludedCommands. Per docs, array settings merge across scopes.

Expected

When running bin/duckdb_query queries/foo.sql (listed in excludedCommands), the command runs fully outside the sandbox. The DuckDB motherduck extension's init call to api.motherduck.com succeeds via a direct connection.

Actual

The command runs without a permission prompt (allow rule matches), but the motherduck extension fails:

Error: unable to open database "md:": Invalid Input Error: Initialization
function "motherduck_duckdb_cpp_init" ... threw an exception:
"Failed to download http://api.motherduck.com/extension_version
(attempt 5): Could not establish connection"

The motherduck extension does not honor HTTP(S)_PROXY env vars, so it attempts a direct socket connection. That fails even though:

1. bin/duckdb_query and duckdb are both in excludedCommands
2. api.motherduck.com is in sandbox.network.allowedDomains
3. curl https://api.motherduck.com/ from the same shell succeeds (via the sandbox's localhost:60263 HTTPS proxy)
4. Unsetting all *_proxy env vars before running still produces the same failure — confirming the sandbox, not env-var confusion, is blocking the connection

Impact

Every sandbox-blocked call forces a fallback to dangerouslyDisableSandbox: true, which by design always prompts the user and cannot be allowlisted. Result: the user approves a sandbox-disable prompt for every invocation of a tool that was explicitly placed in excludedCommands to avoid exactly this.

Reproduction

1. Install DuckDB with the motherduck extension and authenticate.
2. Add "duckdb" to sandbox.excludedCommands in .claude/settings.local.json.
3. From Claude Code, have the assistant run duckdb md: < some_query.sql.
4. Observe the "Could not establish connection" failure.