Skip to main content

​
Browser And Web Boundaries

Use this page when web fetch, browser actions, browser preview, or outbound HTTP delivery feels “mysteriously blocked.” The important operator truth is that Loong has more than one web-facing boundary, and each one owns a different lane.

​
Start Here

If you need to…Start here
allow a private or loopback HTTP target for outbound deliveryOutbound HTTP Trust Toggle
change built-in browser enablement or session limitsBuilt-In Browser Shape
allow the built-in web fetch or built-in browser lane to reach a private hostBuilt-In Web And Browser Policy
constrain browser or web traffic to a reviewed domain setAllowed And Blocked Domains
understand why browser preview still is not ready after installBrowser Preview And Companion Gates
inspect the underlying public safety postureSecurity And Reliability

​
One Problem Family, Four Different Config Owners

The same symptom word, such as “browser is blocked” or “URL is rejected,” can come from different policy owners:
  • [outbound_http] owns HTTP-backed outbound delivery such as webhook-style and workplace send surfaces
  • [tools.browser] owns built-in browser enablement and local session limits
  • [tools.web] owns built-in web fetch and the outbound trust boundary used by built-in browser requests
  • [tools.browser_companion] owns the richer managed browser companion policy
That is why “just set one flag” is often the wrong operator advice.

​
Outbound HTTP Trust Toggle

Use this when the blocked target is an outbound delivery surface rather than the built-in browser lane. 
[outbound_http]
allow_private_hosts = true
This is the right owner when:
  • a webhook target is loopback or private-network only
  • a self-hosted Slack/Discord-style bridge sits behind an internal endpoint
  • an outbound-only surface is intentionally meant to stay inside a trusted network boundary
Keep this mental rule:
  • outbound_http is for config-backed outbound delivery
  • it is not the same thing as the built-in browser or web-fetch policy

​
Built-In Browser Shape

The built-in browser tool is split across two config families on purpose: 
[tools.browser]
enabled = true
max_sessions = 4
max_links = 8
max_text_chars = 2048

[tools.web]
enabled = true
allow_private_hosts = false
allowed_domains = ["docs.example.com", "api.example.com"]
blocked_domains = ["internal.example"]
timeout_seconds = 9
max_bytes = 262144
max_redirects = 1
Read this split carefully:
  • change [tools.browser] when browser actions themselves are disabled or need different session, link, or text limits
  • change [tools.web] when the blocker is URL policy, private-host policy, redirects, timeout, or allowed and blocked domains
  • built-in browser requests follow tools.web for host and domain trust; they do not use [outbound_http]

​
Built-In Web And Browser Policy

The built-in browser lane follows the same web-fetch safety boundary as the built-in web tools. 
[tools.web]
enabled = true
allow_private_hosts = false
allowed_domains = ["docs.example.com", "api.example.com"]
blocked_domains = ["internal.example"]
timeout_seconds = 9
max_bytes = 262144
max_redirects = 1
What the fields mean publicly:
  • allow_private_hosts decides whether loopback and private-network targets are blocked or allowed
  • allowed_domains becomes an explicit allowlist when it is non-empty
  • blocked_domains stays a deny list for known-bad or out-of-scope targets
  • timeout_seconds, max_bytes, and max_redirects keep the lane bounded even when it is enabled
This is the lane to change when:
  • built-in web.fetch or search-style retrieval is blocked on a local/private URL
  • built-in browser open/extract/navigation needs to reach a private bridge
  • the browser lane should be allowlisted to a reviewed public domain set
  • the browser tool itself is already enabled and the remaining problem is clearly about web reachability rather than browser session sizing

​
Allowed And Blocked Domains

Domain rules are normalized into lowercase entries and are meant to be read as real operator policy, not only as implementation detail. Use them like this:
  • keep allowed_domains empty when public-web access should remain broad
  • fill allowed_domains when the lane should only talk to a reviewed set such as docs.example.com
  • use blocked_domains for explicit no-go destinations even when the rest of the lane remains broad
If a target is still rejected after you set allow_private_hosts = true, check these next:
  • the host may still be missing from a non-empty allowed_domains list
  • the host may already appear in blocked_domains
  • you may be changing the wrong lane, such as outbound_http when the built-in browser is the real caller

​
Browser Preview And Companion Gates

Browser preview adds another layer beyond plain URL policy: the runtime itself must be installed and ready. The shortest public path is still: 
loong skills enable-browser-preview
npm install -g agent-browser && agent-browser install
agent-browser open example.com
loong doctor
That path solves a different problem than tools.web:
  • enable-browser-preview turns on the managed preview helper flow
  • agent-browser is the runtime binary that must actually exist on PATH
  • loong doctor is the public repair path when preview still is not ready

​
Managed Browser Companion Policy

When you want the richer companion lane to be explicit in config instead of relying on defaults alone, this is the public shape: 
[tools.browser_companion]
enabled = true
command = "loong-browser-companion"
expected_version = "1.2.3"
timeout_seconds = 30
allow_private_hosts = false
allowed_domains = ["docs.example.com"]
blocked_domains = ["internal.example"]
Read this block carefully:
  • enabled = true only turns on the config gate; it does not make the runtime binary magically available
  • command and expected_version make doctor’s install/version checks concrete
  • allow_private_hosts, allowed_domains, and blocked_domains are the companion lane’s own policy when you configure it explicitly
  • this block is separate from [tools.browser] and the built-in browser tool; it is for the managed companion runtime path
If the companion block is still at defaults, the runtime can fall back to the exported web policy environment instead of a custom companion-specific domain policy.

​
Common Failure Cases

What happenedWhat it usually meansWhat to change
an outbound webhook or workplace send target is rejectedthe outbound delivery lane is still fail-closed for private hostsset [outbound_http] allow_private_hosts = true only if that private target is intentional
browser commands are unavailable before any URL is even triedthe built-in browser tool is disabled or too tightly bounded for the use casereview [tools.browser] enabled, max_sessions, max_links, and max_text_chars
built-in browser open or web fetch rejects a local/private URLthe built-in tool lane is still in public-only modeset [tools.web] allow_private_hosts = true
a target is still rejected after private hosts are allowedthe host is missing from an allowlist or already blocked explicitlyreview allowed_domains and blocked_domains in the owning lane
browser preview enable succeeded, but preview is still unavailablethe helper skill is present but the runtime binary is missing or not callableinstall agent-browser, verify it directly, then rerun loong doctor
browser preview enable fails immediatelyshell policy explicitly denies agent-browserremove agent-browser from [tools].shell_deny, then retry
doctor says the browser companion runtime gate is not readyconfig and runtime readiness are still different stateskeep using the built-in browser lane or disable tools.browser_companion.enabled until the companion runtime is truly ready

​
Reading Rules

  • Change only the lane that actually owns the blocked traffic.
  • Check [tools.browser] first if the problem is “browser tool unavailable” rather than “URL rejected.”
  • Do not use outbound_http as a generic fix for built-in browser or web-fetch failures.
  • Do not use allow_private_hosts = true as a substitute for a real domain policy when the lane should stay narrow.
  • Treat doctor as the repair path when browser preview or companion readiness is unclear.

​
Continue Reading

  • Continue to Managed Skills when the issue is skill install, browser preview enablement, or download policy rather than raw URL policy.
  • Continue to Configuration Patterns when you want the wider operator config map around providers, channels, memory, and trust toggles.
  • Continue to Tool Surface when you want the broader truthful-tool contract behind these boundaries.
  • Continue to Doctor And Health when you want the repair-first operator path.