Skip to main content
The Browser connection is in beta.
A Browser connection lets an agent open web pages in a real (headless) browser — navigate, read content, interact with elements, download files and capture screenshots — confined to a URL allowlist you define. It is useful for data that only lives behind a UI, including internal portals reachable from your deployment. Unlike every other connector, a Browser connection has no catalog and no query language. It is a capability provider: attaching it to an agent adds the browser tools to that agent’s tool catalog and carries the allowlist those tools enforce at runtime. The tools appear for an agent only when a browser connection is attached to it.

The tools it adds

Elements are addressed by the ref from the most recent snapshot. A stale reference returns a typed error so the model re-snapshots rather than blindly retrying.
browser_act is the one write tool — it changes state on the page it is pointed at. It only ever operates inside a page the allowlist already permits.

The allowlist is the security boundary

url_patterns is not a starting point or a default — it is the boundary. Every request the browser makes is confined to it: top-level navigation, subresources, XHR and redirects alike. There is no unscoped browsing; a pattern must be listed for the agent to reach it. Pattern rules:
  • One glob pattern per line, e.g. https://portal.vendor.com/**.
  • A pattern must name a host: a hostname, wildcarded subdomains such as https://*.vendor.com/**, or a single literal IP.
  • Network-spanning host wildcards such as http://10.*.*.*/** are rejected — a pattern may not sweep a whole network.
Anything not matched is refused.

Fields

Authentication

No Auth — none (system scope, the only mode). There is nothing to enter. The connection carries no credentials, and the browser does not log in — point it at pages that are readable without a session, or that your network already authorizes.

Testing the connection

Testing validates the allowlist itself, not reachability. There is no server to contact at configuration time: the “server” is whatever public or internal sites the patterns name, and some of them may only be reachable at run time. A well-formed allowlist is therefore a successful test.

Troubleshooting

It does not name a host, or it wildcards across a network. Use a hostname, https://*.vendor.com/**, or a single literal IP.
The page’s subresources or XHR calls are on a host the allowlist does not cover. Those are confined by the same patterns as navigation — add the host they fetch from.
A browser connection has to be attached to that specific agent. The tools do not appear otherwise.
The page changed since the last snapshot. This is expected and self-correcting — the agent re-snapshots and retries against fresh references.