How to block a domain from a sandbox

Call sbx.network.set({ internet: true, deny: ["example.com"] }); the sandbox keeps the rest of the internet but never reaches that domain.

On Runtime a deny entry always wins, over any allow entry and over root inside the sandbox. The rule lives in a proxy on the host, not in the guest's firewall, so sudo iptables in the sandbox changes nothing about what leaves it. It takes effect at once, connections already open included, which makes it a switch you can throw while an agent is mid-task.

Block at create

TypeScriptimport { Sandbox } from "withruntime";await using sbx = await Sandbox.create({  network: { internet: true, deny: ["example.com", "*.example.com"] },});const blocked = await sbx.exec("curl -sS --max-time 5 https://www.example.com", {  timeoutMs: 30_000,});console.log(blocked.exitCode !== 0); // true: refused on the host

Pythonfrom withruntime import Sandboxwith Sandbox.create(network={"internet": True, "deny": ["example.com", "*.example.com"]}) as sbx:    blocked = sbx.exec("curl -sS --max-time 5 https://www.example.com", timeout_ms=30_000)    print(blocked.exit_code != 0)  # True: refused on the host

Terminalruntime sandbox create --deny example.com --deny '*.example.com'

example.com matches the name itself, and *.example.com every name under it. List both to cover a whole site.

Block while it runs

An agent that starts misbehaving can lose a destination without being stopped. set replaces the rules, so include anything you still want:

TypeScriptimport { Sandbox } from "withruntime";await using sbx = await Sandbox.create();await sbx.spawn("python3 -m http.server 8000");await sbx.network.set({ internet: true, deny: ["pastebin.com"] });console.log(await sbx.network.get()); // the process keeps running

Pythonfrom withruntime import Sandboxwith Sandbox.create() as sbx:    sbx.spawn("python3 -m http.server 8000")    sbx.network.set(internet=True, deny=["pastebin.com"])    print(sbx.network.get())  # the process keeps running

Terminalruntime sandbox network <id> --deny pastebin.com

Processes, files and memory are untouched; only the refused connections end. An agent on MCP does the same with runtime_sandbox_network_set.

What a deny entry can name

Entry	Blocks
`example.com`	That name
`*.example.com`	Every name under it
`203.0.113.7`	One address
`198.51.100.0/24`	A CIDR range

Deny, allow or off?

You know	Use
The few places that are off-limits	`deny`: everything else stays reachable
The few places the code needs	`allow`: everything else refused
The code needs no network at all	`internet: false`

A deny list is the lightest touch and the weakest guard: a site you did not think of is still open. For code you do not trust, an allow-list is the safer default, and deny inside it carves out exceptions under an allowed wildcard, such as one subdomain of *.githubusercontent.com.

Blocked whatever you set

Some destinations are refused for every sandbox without a rule:

private and internal addresses, so a sandbox never reaches your network;
mail ports 25, 465 and 587, unless support enables mail for the account;
telnet, Windows RPC, NetBIOS and SMB, and IRC.

TCP leaves a sandbox, and a paid one also sends QUIC and NTP over UDP (outbound UDP); names are resolved inside it.

Mistakes and how Runtime handles them

Blocking example.com and expecting www.example.com to fail. Add the wildcard *.example.com too.
Chasing every mirror of a site. A deny list grows without end when the site has many names. When the list of places the code needs is shorter, switch to an allow-list.
Losing the old rules. Each set replaces the rules; read them with sbx.network.get() first and send the full list back.
Trying to block inside the guest. /etc/hosts or iptables in the sandbox can be undone by the code you are guarding against. The host's rule cannot.

The network in the sandbox environment guide.
Network access.
Egress control.
Run untrusted LLM code.

Facts on this page were checked on 25 September 2026.