Why can't my AI agent reach a website or package registry?

Because outbound traffic from a Sanbox Computer is denied unless the template's network policy allows it. A blocked request or image pull names the host it couldn't reach, so the fix is usually to add that host and port to the policy and start a new run. If the host seems allowed, the cause is often a secret proxy granted without a network rule, or a client that ignores the Computer's proxy or certificate settings. On any other machine, the same symptoms usually point to a firewall or a corporate proxy.

Run this with your agent

Read https://sanbox.cloud/kb/errors/why-cant-my-agent-reach-a-website.md and follow it to find and fix the host my agent can't reach.
If the Sanbox CLI is missing, install it with `npm install -g @sanlabs/sanbox-cli@latest`
and sign in with `sanbox login`. Show me each command before you create, stop or delete a Computer.

Why is the request blocked at all?

Every template's network policy is deny-by-default. The Computer reaches the model provider configured for its template, plus the destinations listed in its policy, and nothing else. A template can be runnable: true and still block the sites your task needs: readiness doesn't check the policy against your task.

The policy covers outbound traffic only. If you're trying to reach a service running inside the Computer, that's inbound access, which is a separate setting and off by default. See How do I preview the dev server my agent is running?

1. Find the blocked host

Read the error. A blocked pull or request names the host it couldn't reach. Note that one site often needs several hosts: a package manager may fetch metadata from one host and files from another, and a website may load from a CDN. Fix them one at a time; each new error names the next host.

2. Check what the template allows

Open the template in the Sanbox console and look at its Network access tab, or read the template from the CLI:

sanbox templates get <template-id> --json

3. Add the host

Rules are per host and port. Here is a policy for a Node and Python project that pulls images from Docker Hub:

{
  "default_action": "deny",
  "rules": [
    { "destination": "registry.npmjs.org", "ports": [{ "from": 443, "to": 443 }] },
    { "destination": "pypi.org", "ports": [{ "from": 443, "to": 443 }] },
    { "destination": "files.pythonhosted.org", "ports": [{ "from": 443, "to": 443 }] },
    { "destination": "registry-1.docker.io", "ports": [{ "from": 443, "to": 443 }] },
    { "destination": "auth.docker.io", "ports": [{ "from": 443, "to": 443 }] },
    { "destination": "production.cloudfront.docker.com", "ports": [{ "from": 443, "to": 443 }] },
    { "destination": "production.cloudflare.docker.com", "ports": [{ "from": 443, "to": 443 }] }
  ]
}

Common hosts:

Docker has served image layers from both CDN hosts, so allow both. If a client uses a port other than 443, the rule needs that port.

Create a template with the policy, or edit an existing template's Network access tab in the console:

sanbox templates create --name "Project dev" --type opencode-computer \
  --model-provider <provider-id> --model <model-id> \
  --network-policy policy.json --json

Then start a new run from the template and try again:

sanbox run --template <template-id> --json

Forks don't pick up template edits: a fork keeps the network rules of the run it was copied from.

4. If the host has a secret proxy, check its rule

A secret proxy grant doesn't add a network rule by itself. If the agent calls an API through a secret proxy and the request is blocked, grant it again with --add-network-access, which adds an HTTPS rule on port 443:

sanbox templates secret-proxies grant <template-id> <proxy-name> --add-network-access --json

Check data.network_access in the response for warnings. Grants apply on the next start or resume; to pick up the new network rule, start a new Computer from the template. Secret proxies work only over HTTPS to hosts with public addresses; plain HTTP and requests to a bare IP address never receive the credential.

5. If you get a TLS error on an allowed host

On hosts with a secret proxy, the Computer trusts the run's Secret Proxy CA through SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE and similar variables. Clients that ignore these variables can fail with a certificate error. Java is the common case: add /dev/sanbox/runtime-ca.pem to its trust store explicitly. Don't turn off TLS verification to make an error go away.

The same goes for clients that override proxy settings. Commands run with the run's proxy settings; a tool that ignores them can fail even when its host is allowed.

6. If it fails inside a Docker container

In a Docker Computer, containers and builds reach the network only through the run's proxy at http://169.254.77.1:3128, which Docker passes on automatically. Two things trip people up:

• Packages fetched during a build need their own rules, for example deb.debian.org, pypi.org or registry.npmjs.org.
• Compose services calling each other over HTTP send that traffic to the proxy too, unless the service names are in NO_PROXY in each service's environment.

See How do I run Docker Compose inside an AI agent's sandbox?

What this doesn't do

• Static IP addresses. Sanbox has no static egress IP, so a destination can't allowlist your Computers by IP.
• VPN. There's no VPN inside the Computer.
• Other protocols. Rules are per host and port. For connections that aren't HTTP or HTTPS, such as a database protocol, write to support@sanlabs.ai before you build on them.
• Opening everything. Allowing every host defeats the policy. Add hosts as errors name them.

Related

• How do I restrict which domains an AI agent can reach?
• How do I give an AI agent API keys without exposing them?
• How do I run Docker Compose inside an AI agent's sandbox?
• How do I preview the dev server my agent is running?

Sources

• PyPI, API documentation (package files served from files.pythonhosted.org), checked 2026-11-06