Local policy

The sbx policy command manages the local policy on your machine. The local policy contains network access rules. Rules apply to all sandboxes on the machine when you use the global scope, or to a single sandbox when scoped by name.

Local policy interacts with organization governance as follows:

• No org governance: the local policy controls what sandboxes can access.
• Org governance active: only organization allow rules grant access, so local allow rules are inactive and can't expand what the organization permits. Local deny rules are still evaluated, so you can restrict access further than the organization policy does. To list inactive rules, run sbx policy ls --include-inactive. See Monitoring.

See Organization policies for how organization governance works.

For domain patterns, wildcards, CIDR ranges, and filesystem path syntax, see Policy concepts.

Default preset

Outbound TCP traffic passes through a proxy on your host, which enforces access rules on every connection. Non-HTTP TCP traffic, including SSH, can be allowed with a hostname rule (for example, sbx policy allow network "myhost:22") or an address-based rule. UDP requires the experimental feature and policy rules described in Allow outbound UDP. ICMP is blocked.

If you haven't chosen a default preset, the CLI prompts you before it runs a sandbox. Running sbx policy reset clears the preset and prompts you to choose again:

Initialize the global network policy for your sandboxes:

  Applies to all sandboxes, current and future — change it later with
  "sbx policy allow/deny/rm". Kits, including built-in agent kits, may
  also add per-sandbox rules.

     1. Open         — All network traffic allowed, no restrictions.
  ❯  2. Balanced     — Default deny, with common dev sites allowed.
     3. Locked Down  — All network traffic blocked unless you allow it.

  Use ↑/↓ or 1–3 to navigate, Enter to confirm, Esc to cancel.

Presets initialize the global policy. Built-in agent kits and other kits can add per-sandbox allow rules, including under Locked Down (deny-all). The preset isn't an explicit deny rule that overrides those allowances. To inspect the rules a kit adds to a sandbox, run:

$ sbx policy ls my-sandbox --source kit --type network --wide

To block a destination allowed by a kit, add an explicit deny rule:

$ sbx policy deny network --sandbox my-sandbox openrouter.ai

Deny rules take precedence over allow rules. See Policy precedence.

The Balanced preset's baseline allowlist is a good starting point for most workflows. Run sbx policy ls to see exactly which rules it includes. As of v0.35.0, the Balanced preset also allows VS Code domains, Azure Blob Storage (*.blob.core.windows.net), and dhi.io over HTTP.

メモ

If your organization manages sandbox policies centrally, organization rules take precedence over the preset you select here. See Organization policies.

Non-interactive environments

In non-interactive environments such as CI pipelines or headless servers, the interactive prompt can't be displayed. Use sbx policy init to set the preset before running any other sbx commands:

$ sbx policy init balanced

Available values are allow-all, balanced, and deny-all.

Managing rules

A rule covers a destination host. It can also name HTTP methods and paths to narrow the match to part of that host.

Network rules

Use sbx policy allow and sbx policy deny to add or restrict access on top of the active preset. Changes take effect immediately. Rules apply to all sandboxes by default:

$ sbx policy allow network api.anthropic.com
$ sbx policy deny network ads.example.com

Pass --sandbox <name> to scope a rule to one sandbox:

$ sbx policy allow network --sandbox my-sandbox api.example.com
$ sbx policy deny network --sandbox my-sandbox ads.example.com

As of v0.38.0, you can also set per-sandbox deny rules at creation time with --deny-network on sbx create or sbx run, instead of adding them after the fact:

$ sbx create --deny-network ads.example.com claude .
$ sbx run --deny-network ads.example.com claude

Pass the flag multiple times to deny more than one host. Rules added this way appear in sbx policy ls <name> and can be removed with sbx policy rm network --sandbox <name> --resource <host>.

Specify multiple hosts in one command with a comma-separated list:

$ sbx policy allow network "api.anthropic.com,*.npmjs.org,*.pypi.org"

Remove a rule by resource or by rule ID:

$ sbx policy rm network --resource ads.example.com
$ sbx policy rm network --id 2d3c1f0e-4a73-4e05-bc9d-f2f9a4b50d67

To remove a sandbox-scoped rule, pass --sandbox <name>:

$ sbx policy rm network --sandbox my-sandbox --resource api.example.com

HTTP method and path rules

Add --method to an allow or deny rule to match specific HTTP methods on a host, and --path to restrict it to part of the host's URL space:

$ sbx policy allow network api.github.com --method GET --path '/repos/org/project/**'

Quote the path so your shell doesn't expand the wildcard. Pass several methods as a comma-separated list:

$ sbx policy allow network api.github.com --method GET,HEAD

--method ANY matches every HTTP method, and --path defaults to /** when you omit it:

$ sbx policy allow network api.github.com --method ANY

ANY can't be combined with specific methods, and a path without a method is rejected. Pass a method, or use ANY when you mean every method.

Method names are case-insensitive. The accepted values are GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, CONNECT, and TRACE.

A path must start with / and be canonical. It can't contain a query string, a fragment, percent-encoding, control characters, surrounding whitespace, repeated or trailing slashes, or dot segments such as . and ... Each rule takes one path.

Hosts follow the same patterns as network rules and can include a port. Write the host on its own, without a scheme, so an HTTP rule takes api.example.com rather than https://api.example.com.

A local HTTP rule takes a hostname. To match an IP address or a CIDR range, add a plain network rule for that destination instead.

Deny rules take the same flags, which is the usual way to carve a method or path out of a broader allow:

$ sbx policy allow network api.example.com
$ sbx policy deny network api.example.com --method POST --path '/admin/**'

For how the two layers combine, see HTTP rules.

Remove an HTTP rule by naming the same qualifiers you added it with, or by rule ID:

$ sbx policy rm network --resource api.github.com --method GET --path '/repos/org/project/**'
$ sbx policy rm network --id 7f3a1c2e-4a73-4e05-bc9d-f2f9a4b50d67

List HTTP rules with --type http, or see them alongside network rules in a wide listing, where the METHOD and PATH columns are empty for rules that match a whole host:

$ sbx policy ls --wide
TYPE      METHOD   PATH
network   -        -
http      GET      /repos/org/project/**

メモ

sbx policy check network and sbx policy log don't evaluate or display HTTP methods and paths. A check reports the decision for the host, which can differ from the decision for a specific method and path on that host.

Inspecting rules

To inspect which policies are active and where they come from, use sbx policy ls. Use --source to filter by origin (local, org, kit), --decision to filter by outcome (allow, deny), and --wide for rule-level detail including rule IDs. To inspect a single policy or rule in full, use sbx policy inspect. See Monitoring.

Allow outbound UDP

Outbound UDP is experimental and disabled by default. Turn on experimental features and UDP egress before adding UDP allow rules:

$ sbx settings set platform.allowExperimentalFeatures true
$ sbx settings set feature.udp-egress true
$ sbx policy allow network --protocol udp api.example.com:443

Local allow rules apply to TCP by default. Use --protocol udp for UDP or --protocol tcp,udp for both. Deny rules apply to both protocols by default. Use --protocol to restrict a deny rule to one protocol.

UDP follows the same organization and local policy precedence as TCP. It is refused when the destination requires an HTTP, SOCKS5, system, or PAC-selected proxy, because those proxies can't carry UDP. ICMP remains blocked.

Inspect UDP rules or check a destination:

$ sbx policy ls --protocol udp
$ sbx policy check network --protocol udp api.example.com:443

The CLI warns if you save a UDP rule while UDP egress is disabled.

Testing policy

Before running a sandbox, you can check whether the current policy would allow a network request with sbx policy check network:

$ sbx policy check network api.anthropic.com
Allowed: api.anthropic.com

$ sbx policy check network blocked.example.com
Denied: blocked.example.com

The target can be a hostname, a host:port pair, an IP address, or a URL. Bare hostnames and IP addresses are evaluated against port 443. This is useful for verifying custom rules or checking what the Locked Down preset blocks before you start an agent.

To check policy in the context of a specific sandbox:

$ sbx policy check network --sandbox my-sandbox api.example.com

Resetting

To remove all custom rules and start fresh with a new preset, use sbx policy reset:

$ sbx policy reset

This deletes the local policy store, restarts the daemon, and prompts you to choose a new preset. Running sandboxes stop when the daemon shuts down. Pass --force to skip the confirmation prompt:

$ sbx policy reset --force

Troubleshooting

Local allow rules have no effect

If rules you add with sbx policy allow don't change sandbox behavior, your organization likely has governance enabled. Run sbx policy ls to check: if the output starts with a Governance: status line showing Managed by <org>, org governance is active. When it's active, local allow rules are inactive. You can't use them to loosen restrictions the org policy imposes.

Inactive allow rules are hidden from sbx policy ls by default; run sbx policy ls --include-inactive to see them with an inactive status in the STATUS column.

When organization governance is active, only organization allow rules can grant access. Ask your admin to update the organization policy if you need access to an additional resource. Local deny rules remain active, so you can use sbx policy deny to restrict access further.

A domain is still blocked after adding an allow rule

If a domain remains blocked after you add a local allow rule, your organization likely enforces governance, which makes local allow rules inactive. Run sbx policy ls to check whether org governance is active; if the output starts with a Governance: status line showing Managed by <org>, it is. Add --include-inactive to confirm your rule shows an inactive status. If so, the block can only be lifted by updating the org policy in Docker Home or via the API.

An HTTP method or path is blocked on an allowed host

A host that a network rule allows can still have individual methods or paths denied by an HTTP rule. Run sbx policy ls --type http to see which HTTP rules apply. sbx policy check network reports the decision for the host only, so it shows a host as allowed even when the specific request is denied. See HTTP method and path rules.