[BUG] managed-settings.json sandbox.network.deniedDomains not enforced for Bash tool in VS Code extension

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?

Bash tool commands reach the denied domain successfully. Example:

$ zowe zosmf check status
The user john successfully connected to z/OSMF on 'INTERNAL.EXAMPLE.COM'.
...

Direct curl to both the lowercase and uppercase form of the denied hostname also succeeded (got an HTTP response back), ruling out a case-sensitivity bug in the domain match — the deny list doesn't appear to be applied at all to this execution path.

What Should Happen?

With sandbox.enabled: true, allowUnsandboxedCommands: false, and failIfUnavailable: true, any Bash tool command that tries to reach a host in network.deniedDomains should be blocked (or the command should hard-fail if the sandbox can't be established).

Error Messages/Logs

Inspecting the process tree for the Bash tool's shell shows no sandbox wrapper in its ancestry:

PID 50773  /bin/zsh ...                         <- Bash tool's shell
PID 47475  .../anthropic.claude-code-2.1.273-darwin-arm64/resources/native-binary/claude ...

The shell is a direct child of the extension's native binary with no `sandbox-exec` (Seatbelt) process in between, and no `HTTPS_PROXY`/`HTTP_PROXY`/`ALL_PROXY` env vars are set. For comparison, VS Code's own renderer and network-service helper processes on the same machine do carry `--enable-sandbox`/`--seatbelt-client=N` flags and are genuinely sandboxed by macOS.

This suggests `sandbox.network.deniedDomains` (and possibly other sandbox policy fields) from managed-settings.json is read/parsed correctly but is not actually being enforced for Bash tool commands run from the VS Code extension host — the command executes as a plain unsandboxed process rather than through Seatbelt or a filtering proxy.

Steps to Reproduce

Environment

• Claude Code VS Code extension version: 2.1.273 (darwin-arm64)
• Bundled CLI version (claude --version): 2.1.272 (Claude Code)
• OS: macOS (Darwin 25.6.0)
• gh/CLI not involved — issue reproduced entirely via the Bash tool inside the VS Code extension host

Managed settings (/Library/Application Support/ClaudeCode/managed-settings.json)

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "deniedDomains": [
        "internal.example.com",
        "*.internal.example.com"
      ]
    }
  }
}

**Repro steps**
1. Set the managed-settings.json above (with a real domain) at `/Library/Application Support/ClaudeCode/managed-settings.json`.
2. Fully restart VS Code (confirmed this does not change the result).
3. In a Claude Code chat in the VS Code extension, run a Bash tool command that connects to the denied domain (e.g. `curl https://<denied-domain>` or any CLI that reaches it).
4. Observe the connection succeeds instead of being blocked, despite `failIfUnavailable: true` and `allowUnsandboxedCommands: false`.


### Claude Model

Sonnet (default)

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.272

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

VS Code integrated terminal

### Additional Information

`allowUnsandboxedCommands: false` + `failIfUnavailable: true` is meant to be a hard guarantee — either commands run inside the sandbox with the policy applied, or they don't run at all. Here neither happened: the command ran, unsandboxed, with no error or warning that the network policy wasn't applied. For anyone relying on managed-settings.json to enforce network egress restrictions (e.g. blocking access to a production host from an agent session), this is a silent policy bypass.