FIXED - Headless Browser Still Falling Back to Chrome Ext Relay (DISP Set, Browser Service Running)

[outer nacelle]

nvironment

Host: DigitalOcean VPS

OS: Ubuntu 24.04

Runtime: Docker

Image: ghcr.io/openclaw/openclaw:2026.2.6-3

Gateway: local mode, token auth

Goal: Headless browser inside container (no Chrome extension)

Container started with:

-e DISPLAY=:99
-v /home/admin/molt/data:/home/node/.openclaw
-p 18789:18789

DISPLAY confirmed inside container (:99).

Current Issue

Browser service starts, but all browser commands route to Chrome extension relay mode.

Symptoms:

browser start →
Chrome extension relay is running, but no tab is connected

browser profiles:

openclaw: stopped
chrome: running (0 tabs) [default]

Starting openclaw profile still triggers extension relay.

What’s Working

Browser service log:

[browser/service] Browser control service ready (profiles=2)

No crash loops

Proxy, gateway, auth, DISPLAY all confirmed correct

This is not infra, proxy, auth, or DISPLAY related.

What We Tried

Recreated container with DISPLAY=:99

Verified browser service + DISPLAY

Attempted explicit browser config in openclaw.json:

"browser": {
"defaultProfile": "openclaw",
"profiles": {
"openclaw": {
"enabled": true,
"headless": true
}
}
}

→ Rejected by validator:

color required

enabled, headless are unrecognized keys

Config schema appears stricter than expected.

Question for Devs

For OpenClaw 2026.x:

What is the correct browser.profiles schema?

How do we force headless (non-extension) mode?

Config?

CLI?

Env var?

Is chrome always extension-only, and is there a built-in headless profile name we should use?

Desired Outcome

Headless browser starts

No Chrome extension relay references

browser start works without manual extension attachment

[wicked flare]

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

[dense zenith]

For 2026.x the browser config is not “per-profile enabled/headless”. Those keys live at the top level of browser, and browser.profiles.<name> has a different schema.

Correct browser.profiles schema (2026.x)

browser.profiles is a map of:

profiles: {
  "<name>": {
    cdpPort?: number,          // local managed browser
    cdpUrl?: "http(s)://...",  // remote CDP
    driver?: "clawd" | "extension",
    color: "#RRGGBB"           // REQUIRED if the profile is defined in config
  }
}

Important gotchas (match your validator errors):

• enabled / headless inside a profile are unrecognized (that’s why you got that error).
• If you define browser.profiles.openclaw at all, it must include color (and also either cdpPort or cdpUrl), otherwise validation fails.

How to force headless, non-extension mode

1. Set the default profile to the managed browser:

• browser.defaultProfile: "openclaw"

2. Turn on headless globally:

• browser.headless: true

3. (Docker/Linux often) add:

• browser.noSandbox: true (commonly required in containers)

Minimal config that validates and does what you want:

{
  browser: {
    enabled: true,
    defaultProfile: "openclaw",
    headless: true,
    noSandbox: true
    // Do NOT set browser.cdpUrl unless you really mean “use this one CDP endpoint for everything”
    // Do NOT add profiles unless you need custom ports/colors/remote CDP
  }
}

If you do want to explicitly define the openclaw profile, it must look like this (note cdpPort + color):

{
  browser: {
    enabled: true,
    defaultProfile: "openclaw",
    headless: true,
    noSandbox: true,
    profiles: {
      openclaw: { cdpPort: 18800, color: "#FF4500", driver: "clawd" }
    }
  }
}

CLI side (so it doesn’t pick the relay)

• openclaw browser start --browser-profile openclaw

openclaw browser start without --browser-profile will start whatever browser.defaultProfile is (and by default that’s chrome, i.e. extension relay).

Answering your direct questions

• Is chrome always extension-only? Yes — it’s the built-in “Chrome extension relay” profile (driver: "extension").
• Built-in headless profile name? Use openclaw + browser.headless:true. There isn’t a separate “openclaw-headless” profile name.
• Env var? Not for “default profile” in 2026.x; use config/CLI.

Docs that spell this out:

• https://docs.openclaw.ai/tools/browser
• https://docs.openclaw.ai/tools/browser-linux-troubleshooting

If after setting defaultProfile: "openclaw" you still see it behaving like relay, paste:

• openclaw config get browser
• openclaw browser profiles --json

(That will usually reveal either browser.cdpUrl being set to the relay port, or profiles.openclaw.driver being extension.)

[outer nacelle]

Update: Managed browser selected, but no browser binary in container

Image: ghcr.io/openclaw/openclaw:2026.2.6-3
OS: Ubuntu 24.04 (Docker)

Current verified state

Browser config set per maintainer guidance:

{
"browser": {
"enabled": true,
"defaultProfile": "openclaw",
"headless": true,
"noSandbox": true
}
}

OpenClaw restarted

browser profiles:

openclaw: stopped [default] port: 18800
chrome: running (0 tabs)

Failure

Starting managed profile:

openclaw browser start --browser-profile openclaw

returns:

Error: No supported browser found (Chrome/Brave/Edge/Chromium on macOS, Linux, or Windows).

New evidence (inside container)

Checked for browser binaries:

command -v chromium || command -v chromium-browser ||
command -v google-chrome || command -v google-chrome-stable ||
command -v brave-browser || command -v microsoft-edge

Result:

NO_BROWSER_BIN_FOUND

Conclusion

The OpenClaw container does not include a browser binary, so the managed (clawd) profile cannot start. This explains why it previously fell back to the Chrome extension relay and why, now that relay is disabled, startup fails with “No supported browser found”.

Question for maintainers

What is the recommended approach for 2026.x in Docker?

Install Chromium inside the OpenClaw container (supported packages + deps)?

Use a separate browser container and connect via browser.profiles.<name>.cdpUrl?

Use a different OpenClaw image/tag that bundles Chromium?

Happy to follow the canonical pattern you recommend.

[dense zenith]

Yep — that error is expected with the stock ghcr.io/openclaw/openclaw:* image.

Per the Docker docs, the default container is security-first and ships with no bundled Chromium/Chrome (“no bundled Chromium/Playwright browsers”), so the openclaw (managed) profile can’t launch anything until you provide a browser binary.
Docs: https://docs.openclaw.ai/install/docker#power-user--full-featured-container-opt-in

Recommended patterns (2026.x)

Option A (most common): Bake a browser into a derived image

Extend the OpenClaw image and install Chromium or Google Chrome, then set browser.executablePath if needed.

OpenClaw auto-detects these paths on Linux:

• /usr/bin/chromium or /usr/bin/chromium-browser
• /usr/bin/google-chrome-stable (etc)

So as long as your install drops a binary there, openclaw browser start --browser-profile openclaw will work.

If you’re building via the repo’s docker-setup.sh, the intended knob is:

• OPENCLAW_DOCKER_APT_PACKAGES="chromium" (or whatever package name matches your base)

Option B (clean separation): Run a separate “remote CDP” browser container

Run something like Browserless (or your own Chrome-with-CDP container) and point OpenClaw at it:

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    profiles: {
      remote: {
        cdpUrl: "http://browserless:3000?token=YOUR_TOKEN",
        color: "#00AA00"
      }
    }

  }
}

This avoids stuffing GUI/browser deps into the gateway container, and upgrades are simpler. Key rule: do not expose the CDP port publicly; keep it on the Docker network only.

“Is there an image/tag that bundles Chromium?”

Not in the documented 2026.x “canonical” Docker flow — the default image intentionally does not include it. The supported approach is (A) build/extend or (B) remote CDP.

If you tell me whether your container base is Debian vs Ubuntu (cat /etc/os-release inside the container), I can suggest the exact apt-get install ... package name + a minimal Dockerfile snippet that lands the binary at one of the auto-detected paths.

[outer nacelle]

thank you krill

✅ Molt / OpenClaw — Headless Browser Control FIXED

Root cause (confirmed):
The stock OpenClaw Docker image intentionally ships without Chromium, so the managed browser profile fails with No supported browser found. This is expected behaviour.

Fix (approved & implemented):
Built and deployed a derived OpenClaw image with Chromium baked in.

What was done:

Created derived image from ghcr.io/openclaw/openclaw:2026.2.6-3

Installed chromium (+ certs, fonts) at build time (no ad-hoc installs)

Recreated openclaw container using derived image

Preserved all volumes, config, tokens, and proxy setup

Recreated loopback proxy (--network container:openclaw)

Verification (evidence-based):

Chromium detected at /usr/bin/chromium

Managed browser profile openclaw:

enabled: true

running: true

CDP exposed on 127.0.0.1:18800

/json/version, /json/list respond correctly

Tabs successfully created and closed via CDP (PUT /json/new, PUT /json/close)

No Chrome extension relay involved

Result:
Headless browser control is fully operational via OpenClaw managed browser. Issue resolved and closed.

[dense zenith]

Glad you got it nailed down.

If you want this to be searchable for the next person, please right‑click the message that contained the fix → Apps → ✅ Mark Solution (Answer Overflow indexes it).

Quick recap (for future readers):

• The ghcr.io/openclaw/openclaw:* image is security-first and does not ship a browser binary.
• For managed browser (openclaw profile) in Docker, the canonical fix is to derive an image and install Chromium/Chrome at build time, then run with browser.defaultProfile="openclaw" + browser.headless=true (+ usually browser.noSandbox=true in containers).