Passing walls
Some public pages refuse an ordinary automated browse, or serve different content depending on the country you appear to be visiting from. dangerously_pass_walls is the guard-railed, opt-in capability that lets the agent reach that public content on your behalf when the normal browser cannot. The name is deliberate: it is powerful, it is used sparingly, and every use is logged and visible.
What it is
- Tool
dangerously_pass_walls- Purpose
- Reach public pages a normal browse is refused from, on your behalf
- Returns
- A browser session id — the agent drives it with the ordinary browser actions
- Availability
- Off the always-on toolset. Pulled in on demand, only when a task needs it
- Visibility
- Lights up the live Computer-tab view; renders in chat as a labelled result
- Scope
- Public web content only. Internal and infrastructure targets are refused
A normal browse handles the vast majority of the web. A small slice does not cooperate: some sites turn automated visitors away at the door even though the content is public, and some serve different pages by region. dangerously_pass_walls opens such a page through a more capable browsing path so the agent can load and read it for you.
It is not a separate browsing interface. It only opens a session and hands back a session id. From there the agent uses the exact same verbs as any other browser session — observe, act, fill a form, extract, screenshot, close. Only the way the page was reached is different; everything downstream is identical, including the live view.
Two legitimate reasons
It exists for content you are entitled to read but a plain browse can’t reach.
| Case | What it means |
|---|---|
| Bot-walled public content | A public page that a standard automated browse is turned away from, even though a person could open it and you are entitled to read it. |
| Region-specific views | Browse as a resident of a given country (an optional two-letter country code, defaulting to yours) to see geo-varying content or pricing you asked about. |
When the agent reaches for it
Deliberately not a default reach.
The tool is kept off the agent’s always-on toolset and surfaced only through on-demand tool discovery, so the model has to reach for it on purpose. Its own contract encodes the discipline the agent must follow.
| Rule | Why |
|---|---|
| Try the normal browser first | Passing walls is only justified once a standard browse has actually been blocked, or a specific country’s view is genuinely required. |
| Never preemptively | It costs more and is slower. It is not used on sites that are not actually walled. |
| Don’t hammer | It reliably gets blocked public pages to load and read. For the harder case of a site that re-challenges at an interactive submit, the agent stops and tells you plainly rather than retrying in a loop. |
What you see
Nothing is hidden.
When the tool opens a session, the same live browser view lights up in the Computer tab that any browser session would trigger — you watch the page load and the agent work. The result renders in chat through the standard external-content component, clearly labelled. When a wall still cannot be cleared, the agent says so directly instead of implying success.
The guardrails
Why it carries the “dangerously” label — and what backs it up.
The dangerously_ prefix is the first guardrail: a signal, to both the model and anyone reading the tool list, that this is a capability to use sparingly and legitimately. The rest are enforced in code.
| Guardrail | What it guarantees |
|---|---|
| Destination safety check | Every URL is validated before anything opens. Internal, private, and infrastructure targets are refused and the refusal is logged. The tool can only be pointed at public web pages. |
| Untrusted-content fencing | Everything the tool brings back is fenced as untrusted external content, so page text can never be treated as trusted instructions to the agent. |
| Audit trail | Each session is recorded as a replayable trail of exactly what was done in the browser. |
| Credentials stay server-side | If a flow needs a login, your saved credentials are supplied to the backend server-side. The model never sees, types, or receives the password. |
| Availability gate | If the capable backend is not configured, the tool returns a clear message rather than silently falling back to something unexpected. |