Docker Compose browser sidecar fails silently due to SSRF policy blocking private network

Author: jiatonCreated Apr 19, 2026Updated Sep 14, 2026

Environment

  • OpenClaw: 2026.4.14
  • Deployment: Docker Compose (self-hosted)
  • Browser sidecar: coollabsio/openclaw-browser:latest

Problem

When using the official browser sidecar via Docker Compose, the browser tool
always fails with:

Remote CDP for profile "openclaw" is not reachable at http://browser:9223.

This happens silently — no HTTP requests are ever made to the browser container.
The error returns in ~2ms, which rules out any network timeout.

Root Cause

OpenClaw's SSRF protection policy (introduced for cloud/multi-tenant deployments)
blocks outbound HTTP requests to private network IPs by default. In a Docker
Compose setup, the browser hostname resolves to a private IP (e.g.
192.168.64.x), which gets blocked before any connection attempt.

The check in cdp-reachability-policy.ts applies the SSRF policy to all remote
CDP profiles. With no explicit SSRF config, resolveBrowserSsrFPolicy returns
{} (an empty object, which is truthy), causing assertCdpEndpointAllowed to
run and reject the private IP.

Fix

Add this to the openclaw service environment in docker-compose.yml:

  - OPENCLAW__browser__ssrfPolicy__dangerouslyAllowPrivateNetwork=true                

Suggestion

Either:

  1. Document this requirement in the README under the browser sidecar section, or
  2. Auto-detect the browser sidecar hostname and whitelist it when
    BROWSER_CDP_URL points to a Docker service name (non-loopback private host)