Claude-3p + Bedrock: managed-settings allowedDomains not honored, sandbox pinned to 4 hosts

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?

When CLAUDE_CODE_USE_BEDROCK=1 is set (either directly or via the Claude-3p enterprise desktop app), the embedded Claude Code binary enforces a sandbox network allowlist limited to ~4 hosts. Both user-level ~/.claude/settings.json and managed-settings sandbox.network.allowedDomains: ["*"] are silently ignored. No CLI flag, env var, or inline settings payload we could find overrides it. This makes the product effectively unusable for engineering workflows under a Bedrock deployment (no GitHub, no internal APIs, no private registries, no generic curl/git/npm install).

Environment
OS: macOS (Darwin 25.4.0, Apple Silicon)
Claude Code version (embedded): 2.1.128
Binary path: ~/Library/Application Support/Claude-3p/claude-code/2.1.128/claude.app/Contents/MacOS/claude
Host app: Claude-3p (enterprise desktop), deployed via Kandji MDM
Inference: AWS Bedrock, us-east-1, per-user bearer token
Env vars set by host app include:
CLAUDE_CODE_USE_BEDROCK=1
CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST=1
CLAUDE_CODE_ENTRYPOINT=claude-desktop-3p
AWS_REGION=us-east-1, AWS_BEARER_TOKEN_BEDROCK=<token>
HTTPS_PROXY=http://localhost:514xx, ALL_PROXY=socks5h://localhost:514xx (the sandbox's own proxy)
Observed behavior
Inside any agent session (or inside a session launched by invoking the embedded binary directly), the sandbox proxy only permits:

bedrock-runtime.us-east-1.amazonaws.com
api.anthropic.com
.sentry.io, .ingest.us.sentry.io
Any other host returns HTTP 403 from the local proxy:

$ curl https://github.com
curl: (56) CONNECT tunnel failed, response 403
Underneath, macOS seatbelt blocks raw DNS / sockets, so the proxy can't be bypassed from a subprocess:

$ env -u HTTPS_PROXY -u ALL_PROXY dig @1.1.1.1 github.com
bind: Operation not permitted
The per-call dangerouslyDisableSandbox tool parameter reports "disabled by policy" and has no effect.

Expected behavior
sandbox.network.allowedDomains in user and/or managed-settings should be honored under Bedrock mode — same as it is for the standard (cloud) Claude Code client. Choosing Bedrock as the inference backend should not implicitly lock the client sandbox's network allowlist for commands the agent runs.

Configuration attempted (all ignored)
User settings — ~/.claude/settings.json:

{
"sandbox": {
"network": {
"allowedDomains": ["*"],
"deniedDomains": [],
"allowedHosts": ["*"],
"deniedHosts": []
},
"allowUnsandboxedCommands": true
},
"skipWebFetchPreflight": true
}
Managed settings — ~/Library/Application Support/Claude-3p/claude-code/managed-settings.json:

{
"sandbox": {
"network": {
"allowedDomains": ["*"],
"deniedDomains": [],
"allowedHosts": ["*"],
"deniedHosts": []
},
"allowUnsandboxedCommands": true
},
"skipWebFetchPreflight": true
}
Reproduction (launching the embedded binary directly)
The restriction persists even when bypassing the host app. Two minimal repros:

1) Launch embedded binary with host-managed env var unset:

CLAUDE_BIN="$HOME/Library/Application Support/Claude-3p/claude-code/2.1.128/claude.app/Contents/MacOS/claude"

env -u CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST -u CLAUDE_CODE_ENTRYPOINT \
CLAUDE_CODE_USE_BEDROCK=1 AWS_REGION=us-east-1 \
AWS_BEARER_TOKEN_BEDROCK="$AWS_BEARER_TOKEN_BEDROCK" \
"$CLAUDE_BIN" --print --permission-mode bypassPermissions \
--model us.anthropic.claude-haiku-4-5-20251001-v1:0 \
'Run: curl -sS -o /dev/null -w "HTTP_CODE=%{http_code}\n" https://github.com'
Result: curl: (56) CONNECT tunnel failed, response 403 / HTTP_CODE=000.

2) Same, with --bare --dangerously-skip-permissions + inline --settings:

env -u CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST -u CLAUDE_CODE_ENTRYPOINT \
CLAUDE_CODE_USE_BEDROCK=1 AWS_REGION=us-east-1 \
AWS_BEARER_TOKEN_BEDROCK="$AWS_BEARER_TOKEN_BEDROCK" \
"$CLAUDE_BIN" --print --bare --dangerously-skip-permissions \
--model us.anthropic.claude-haiku-4-5-20251001-v1:0 \
--settings '{"sandbox":{"network":{"allowedDomains":[""],"allowedHosts":[""]},"allowUnsandboxedCommands":true}}' \
'Run: curl -sS -o /dev/null -w "HTTP_CODE=%{http_code}\n" https://github.com'
Result: identical 403.

What we ruled out
❌ User sandbox.network.allowedDomains: ["*"] — ignored.
❌ Managed-settings allowedDomains: [""] (and allowedHosts: [""])- ignored.
❌ allowUnsandboxedCommands: true- no effect.
❌ dangerouslyDisableSandbox tool param- "disabled by policy."
❌ Unsetting CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST- still blocked.
❌ Unsetting CLAUDE_CODE_ENTRYPOINT- still blocked.
❌ --bare --dangerously-skip-permissions with inline --settings- still blocked.
❌ Bypassing HTTPS_PROXY in a subprocess- seatbelt blocks raw DNS/sockets underneath.
The 4-host allowlist therefore appears to be enforced inside the binary when CLAUDE_CODE_USE_BEDROCK=1, not configurable at any surface available to admins.

Support channel history
Front-line Claude Code support confirmed the behavior is undocumented, said the standard sandbox configuration "should respect wildcards like ["*"]," and was unable to confirm whether Bedrock mode overrides allowedDomains or whether an admin-deployable workaround exists. They advised filing this issue.

Ask
Confirm whether the 4-host allowlist in Bedrock mode is intentional or a bug.
If intentional: expose an MDM-deployable way for enterprise admins to extend or disable it (env var, managed-settings key, signed policy, CLI flag — anything). Right now an admin has no lever.
If unintentional: please honor sandbox.network.allowedDomains from managed-settings when CLAUDE_CODE_USE_BEDROCK=1, matching the standard client's behavior.
Either way, document the Bedrock-mode network policy in the sandboxing / server-managed-settings docs so admins can reason about deployments.

What Should Happen?

sandbox.network.allowedDomains from user settings (~/.claude/settings.json) and managed-settings (~/Library/Application Support/Claude-3p/claude-code/managed-settings.json) should be honored when CLAUDE_CODE_USE_BEDROCK=1 is set — matching the standard (cloud) Claude Code client's behavior.

Concretely:

Setting "sandbox": {"network": {"allowedDomains": ["*"]}} in managed-settings should permit outbound connections to any host from inside the agent sandbox, not just the 4 Bedrock/Anthropic/Sentry hosts.
If there are hosts that must always remain reachable in Bedrock mode (e.g. bedrock-runtime.*, api.anthropic.com), those should be implicit additions to the admin-configured allowlist, not a replacement for it.
allowUnsandboxedCommands: true and the per-call dangerouslyDisableSandbox escape hatch should work in Bedrock mode, same as in the standard client.
MDM admins should be able to extend or disable the allowlist via managed-settings without needing access to internal Anthropic infrastructure.
Expected result of the repro: curl https://github.com from inside the agent should succeed (or at minimum not be blocked by the sandbox proxy), because the admin has explicitly set allowedDomains: ["*"].

Error Messages/Logs

$ curl https://github.com
curl: (56) CONNECT tunnel failed, response 403

Steps to Reproduce

*

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude 1.6259.1 (5095e7) 2026-05-06T03:26:09.000Z

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_