Browser And Web Boundaries

Use this page when web fetch, built-in browse actions, external browser automation, 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 delivery	Outbound HTTP Trust Toggle
change built-in browse enablement or session limits	Built-In Browse Shape
allow the built-in web fetch or built-in browse lane to reach a private host	Built-In Web And Browse Policy
constrain browse or web traffic to a reviewed domain set	Allowed And Blocked Domains
understand why `agent-browser` still is not ready after install	External Browser Automation Runtime
inspect the underlying public safety posture	Security 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 browse enablement and local session limits
[tools.web] owns built-in web fetch and the outbound trust boundary used by built-in browse requests
managed skills such as agent-browser own richer browser automation outside the built-in browse lane

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 Browse Shape

The built-in browse 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 built-in browse 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 browse requests follow tools.web for host and domain trust; they do not use [outbound_http]

Built-In Web And Browse Policy

The built-in browse 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 browse open/extract/click needs to reach a private bridge
the browse lane should be allowlisted to a reviewed public domain set
the built-in browse tool itself is already enabled and the remaining problem is clearly about web reachability rather than 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 browse tool is the real caller

External Browser Automation Runtime

External browser automation adds another layer beyond plain URL policy: the runtime itself must be installed and ready. The shortest public path is still:

loong skills install-bundled agent-browser --replace
npm install -g agent-browser && agent-browser install
agent-browser open example.com
loong doctor

That path solves a different problem than tools.web:

skills install-bundled agent-browser installs the packaged operator skill
agent-browser is the runtime binary that must actually exist on PATH
loong doctor is the public repair path when automation still is not ready

Common Failure Cases

What happened	What it usually means	What to change
an outbound webhook or workplace send target is rejected	the outbound delivery lane is still fail-closed for private hosts	set `[outbound_http] allow_private_hosts = true` only if that private target is intentional
built-in browse commands are unavailable before any URL is even tried	the built-in browse tool is disabled or too tightly bounded for the use case	review `[tools.browser] enabled`, `max_sessions`, `max_links`, and `max_text_chars`
built-in browse open or web fetch rejects a local/private URL	the built-in tool lane is still in public-only mode	set `[tools.web] allow_private_hosts = true`
a target is still rejected after private hosts are allowed	the host is missing from an allowlist or already blocked explicitly	review `allowed_domains` and `blocked_domains` in the owning lane
`agent-browser` still is not usable after install	the skill is present but the runtime binary is missing or not callable	install `agent-browser`, verify it directly, then rerun `loong doctor`
`agent-browser` is installed but invocation still fails immediately	shell policy explicitly denies `agent-browser`	remove `agent-browser` from `[tools].shell_deny`, then retry

Reading Rules

Change only the lane that actually owns the blocked traffic.
Check [tools.browser] first if the problem is “built-in browse tool unavailable” rather than “URL rejected.”
Do not use outbound_http as a generic fix for built-in browse 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 external browser automation readiness is unclear.

Continue Reading

Continue to Skills when the issue is skill install, agent-browser setup, 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.

​Browser And Web Boundaries

​Start Here

​One Problem Family, Four Different Config Owners

​Outbound HTTP Trust Toggle

​Built-In Browse Shape

​Built-In Web And Browse Policy

​Allowed And Blocked Domains

​External Browser Automation Runtime

​Common Failure Cases

​Reading Rules

​Continue Reading