Egress and network access control
The sameproxy_config that injects credentials also controls which destinations a sandbox can reach.
Default egress posture
By default (noaccess_control configured):
- HTTP and HTTPS (ports 80 and 443) to any host are allowed. Outbound HTTP(S) is transparently routed through the proxy, where your
rulesandcallbacksinject credentials. - All other raw TCP is blocked. Connections to non-HTTP ports—databases (
psql/dbton 5432), SSH (22), Redis (6379), and so on—are dropped unless you explicitly allow them.
access_control.
Allow and deny lists
Add anaccess_control object to proxy_config with either an allow_list or a deny_list (not both—the request is rejected if both are set):
Raw TCP egress (e.g. PostgreSQL on 5432) can only be enabled with an
allow_list entry that specifies an explicit non-HTTP port (host:PORT). The default posture and deny_list mode only ever permit HTTP/HTTPS.Pattern syntax
Eachallow_list/deny_list entry uses the following forms:
Connecting to a database (raw TCP)
To let sandbox code reach an external PostgreSQL database withpsql, dbt, or any driver, allow-list the host on its port. Because allow_list is default-deny, also list any HTTP(S) hosts the sandbox needs:
db.example.com:5432 is passed through at the TCP layer with no interception, so the PostgreSQL wire protocol—and TLS, host-key checking, and any other end-to-end protocol on top of it—works unchanged.
Configure via SDK
Configure auth proxy rules
Add aproxy_config when creating a sandbox, or update an existing sandbox by patching its proxy_config. Each rule specifies:
Header types
Each header has atype that controls how its value is stored and displayed:
Single API example
Create a sandbox that automatically injects an OpenAI API key into outbound requests:Multiple API example
Add multiple rules to authenticate with several services at once:GitHub example
Open SWE authenticates GitHub access by minting a short-lived GitHub App installation token outside the sandbox, then patching the sandbox with write-onlyopaque proxy rules. This keeps the short-lived GitHub access token out of the sandbox filesystem and out of deployment environment variables.
Configure two rules:
Python
configure_github_proxy after creating or reattaching to a sandbox. GitHub App installation tokens expire, so refresh the proxy config whenever you reuse a sandbox for a new run.
Inside the sandbox, set a non-secret placeholder token when a CLI requires a local credential before it sends a request:
gh CLI’s local check. The proxy injects the real Authorization header into the outbound request.
Configure via SDK
Callback credential example
Staticworkspace_secret rules pull credentials from your workspace when the proxy configuration is applied, and opaque rules let your application patch in short-lived credentials such as the GitHub token example. For credentials that must be resolved by your own service at proxy time, use a callback. The proxy POSTs to a URL you provide, your endpoint returns the headers to inject, and the proxy caches the result.
Callbacks are configured alongside rules under proxy_config:
Static rules win. If any rule in
rules matches the host, the callback is skipped for that host. Within rules, first-match-wins; the same applies between callbacks if multiple match.
Callback contract
The proxy makes the following request whenever it needs to resolve credentials for a matched host on a cache miss:2xx with a JSON body:
ttl_seconds. Any non-2xx response, transport error, or malformed JSON fails closed: the sandbox’s request is rejected with 502 callback resolution failed (no headers injected, response not cached).
Example
Use a callback when your OAuth tokens are minted on demand by your own service:Configure via SDK
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

