Skip to main content
Custom proxies route browser traffic through a proxy URL. Use them when a workflow needs a specific egress network, region, or enterprise proxy path. Keep proxy URLs in environment variables. Proxy URLs often contain credentials, and Webcompute redaction treats proxy-shaped values as sensitive observability data.

Support matrix

TypeScript SDK

Browser creation

Agent browser creation

This is the supported SDK path for agent work that needs a custom proxy.

Quick actions

Blank proxy strings are omitted by the SDK. Non-blank values are trimmed before they are sent.

CLI

Browser creation

Quick actions

Agent CLI

web agent does not expose a proxy flag.
Use the TypeScript SDK agent path when the agent-created browser must use a proxy.

REST API

The OpenAPI spec includes proxy on browser-create and quick-action request bodies. Use the REST API when you need a non-TypeScript runtime but still want direct proxy support.

MCP

MCP tool schemas do not expose a custom proxy field. If an MCP workflow needs a proxied browser, create the browser through the SDK, CLI, or REST first, then pass the browser ID to a surface that can reuse an existing browser where supported.

Credential handling

Proxy URLs may contain usernames, passwords, tokens, regions, or account IDs. Do:
  • Store proxy URLs in environment variables.
  • Pass proxy URLs as options, not inside natural-language prompts.
  • Avoid printing full request objects.
  • Rotate proxy credentials if a signed log or transcript leaks them.
Do not:
  • Paste proxy credentials into web agent goals.
  • Put proxy credentials in docs, examples, or issue comments.
  • Assume a proxy changes browser policy boundaries. Policy and proxy solve different problems.

Proxy and policy together

Proxy controls egress path. Policy controls browser scope.
Use both for production workflows: proxy for network routing, policy for allowed browser behavior.