#sandbox browser

1 messages · Page 1 of 1 (latest)

full moss
proud prairieBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

drowsy badgeBOT
#

To make OpenClaw actually use the sandbox-browser image, you need to enable the sandboxed browser in config (OpenClaw will then auto-start the container when the browser tool needs it).

1) Enable it in ~/.openclaw/openclaw.json

Add (or merge) something like:

{
  agents: {
    defaults: {
      sandbox: {
        // optional but recommended if you want browser calls to default to the sandbox:
        mode: "all", // or "non-main"

        browser: {
          enabled: true,
#

3) Verify it’s in effect

Run:

openclaw sandbox explain

That will tell you what sandbox mode is active and whether the sandbox browser is enabled.

Notes (common gotcha)

If you paste your current agents.defaults.sandbox block (redact secrets), I can tell you exactly what to tweak.

full moss
#

The browser docker container is located at host browser (10.10.0.10) port 9222

drowsy badgeBOT
#

If your Chromium/CDP endpoint is on another host (10.10.0.10:9222), that’s not the “sandbox browser” path.

  • scripts/sandbox-browser-setup.sh just builds the image openclaw-sandbox-browser:bookworm-slim.
  • OpenClaw’s sandbox browser (agents.defaults.sandbox.browser.*) is a Docker container that OpenClaw expects to start/manage on the same machine as the Gateway (via the local Docker socket). It won’t “attach” to a container running on a different host.

Option A (simple): Treat it as a remote CDP browser

Configure a browser profile that points at your remote CDP URL:

~/.openclaw/openclaw.json

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    profiles: {
      remote: {
# 
        cdpUrl: "http://10.10.0.10:9222"
      }
    }
  }
}

Then use it via:

openclaw browser --browser-profile remote status
openclaw browser --browser-profile remote tabs

Docs: https://docs.openclaw.ai/tools/browser (see “Remote CDP” / “Local vs remote control”)

Security note: CDP on :9222 is basically “remote-control my browser”. Keep it private/firewalled (which 10.10.x.x suggests you are).

#

Option B (recommended): Run a node host on 10.10.0.10

Run an OpenClaw node host on the machine that has the browser/container, so the Gateway can proxy browser actions to it (and you don’t have to expose CDP broadly). Docs: https://docs.openclaw.ai/tools/browser (“Node browser proxy”).

If you actually want the Docker sandbox browser

Then you want the container to run locally on the Gateway host, and enable:

{
  agents: {
    defaults: {
      sandbox: {
        browser: { enabled: true }
      }
    }
  }
}
full moss
#

Invalid config at /home/node/.openclaw/openclaw.json:\n- browser.profiles.remote.color: Invalid input: expected string, received undefined

drowsy badgeBOT
#

That error means your config currently has a color key for the remote profile, but its value is effectively missing/undefined (e.g. color: with nothing after it, or color: undefined).

Fix: either delete the color line or set it to a real string.

Example working profile:

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    profiles: {
      remote: {
        cdpUrl: "http://10.10.0.10:9222",
        color: "#00AA00", // optional, but must be a string if present
      }
# 
    }
  }
}

Then restart the gateway, and test:

openclaw browser --browser-profile remote status

If you paste just your browser.profiles.remote block, I can point out the exact line that’s coming through as undefined.

full moss
#

ok

./openclaw.bsh browser --browser-profile remote status

  • docker exec -it openclaw_htpc-gateway-1 openclaw browser --browser-profile remote status

🦞 OpenClaw 2026.3.2 (unknown) — I'll butter your workflow like a lobster roll: messy, delicious, effective.

│
â—‡
profile: remote
enabled: true
running: false
cdpPort: 9222
cdpUrl: http://10.10.0.10:9222
browser: unknown
detectedBrowser: unknown
detectedPath: auto
profileColor: #00AA00

Is there a test I can do to actually use it?

drowsy badgeBOT
#

Yep — status mostly just shows config, it doesn’t really “exercise” the connection. The easiest real tests are the commands that have to talk to CDP:

Quick “is CDP reachable?” test

./openclaw.bsh browser --browser-profile remote tabs

If that returns a list of targets (or even an empty list without error), your Gateway can reach http://10.10.0.10:9222.

Actually drive it (open a page + prove it by snapshot/screenshot)

./openclaw.bsh browser --browser-profile remote open https://example.com
./openclaw.bsh browser --browser-profile remote snapshot --format aria --limit 80
./openclaw.bsh browser --browser-profile remote screenshot --full-page

Notes:

  • Seeing running: false in status is normal for a remote CDP profile — OpenClaw isn’t launching it, only attaching.
#
  • If tabs/open/snapshot fails with connection errors, the most common cause is Chromium inside the container binding CDP to loopback only. Make sure it’s started with:
    • --remote-debugging-address=0.0.0.0
    • and that the port is actually reachable from the Gateway container/network.

If you paste the exact error from tabs (if any), I can tell you whether it’s a network reachability issue vs a “CDP is up but not speaking what OpenClaw expects” issue.

full moss
#

openclaw browser --browser-profile remote tabs

🦞 OpenClaw 2026.3.2 (unknown) — iMessage green bubble energy, but for everyone.

│
â—‡
No tabs (browser closed or no targets).