#managed browser is failing

12 messages · Page 1 of 1 (latest)

heady estuary
#

OpenClaw managed browser is failing on macOS even after switching from Chrome to Brave.

Current setup:

• OpenClaw gateway is running normally on 127.0.0.1:18789
• browser config is enabled in ~/.openclaw/openclaw.json
• profile is openclaw
• transport is cdp
• cdp port is 18800
• browser path is:
/Applications/Brave Browser.app/Contents/MacOS/Brave Browser

What happens:

• openclaw browser status shows running: false
• openclaw browser start fails with:
Chrome CDP websocket for profile "openclaw" is not reachable after start.
• same failure happened before with Chrome too, so it’s not just a Chrome-vs-Brave issue

Question:
What are the most likely causes on macOS for OpenClaw launching the browser process but never getting a reachable CDP websocket, and what exact config or debug steps should we try next?

If useful, he can assume:

• process appears to start briefly, then OpenClaw still reports no reachable CDP
• we’re trying to use this for OpenClaw browser control, not generic manual Playwright
• goal is to get one working controllable browser profile for a logged-in ArtPrice session

If he wants one more detail, add:

• detectedBrowser: custom
• browser: unknown
• detectedPath correctly points to Brave

heady mortarBOT
formal pilotBOT
#

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

mystic zodiacBOT
#

This looks more like a managed-browser launch/CDP stability problem than a Chrome-vs-Brave problem.

A few concrete things from the docs/source:

  • detectedBrowser: custom is not the root cause. It just means browser.executablePath is set, so OpenClaw stops labeling it as built-in Chrome/Brave detection.
  • browser: unknown in status is usually just “nothing healthy is running right now”.
  • The specific error means OpenClaw got far enough to try the managed launch, but the CDP websocket never became healthy after startup.

Most likely causes on macOS:

  1. Browser starts, then exits/crashes quickly

    • especially with the managed profile dir under ~/.openclaw/.../browser/openclaw/user-data
    • if it fails on both Chrome and Brave, I’d suspect the launch context or managed profile state before the binary path

  2. Gateway is launching the browser from the wrong macOS context

    • headful Chromium on macOS can behave badly if the gateway is not effectively running in the logged-in GUI session
#

  1. CDP comes up partially, then dies before OpenClaw can handshake

    • source shows OpenClaw waits for HTTP reachability first, then separately waits for a healthy WS/CDP command response

  2. Config/goal mismatch

    • openclaw is the isolated managed profile
    • if the real goal is “reuse my already logged-in ArtPrice Brave session”, the better fit is usually driver: "existing-session", not the managed openclaw profile

What I’d try next, in this order:

openclaw --version
openclaw browser status --browser-profile openclaw
openclaw browser start --browser-profile openclaw
openclaw browser profiles
openclaw logs --follow
openclaw doctor
#

Please paste:

  • full openclaw --version
  • full openclaw browser status --browser-profile openclaw
  • the browser-related lines from openclaw logs --follow while reproducing the failure
  • openclaw doctor

My recommendation for ArtPrice specifically:

Option A, fastest if you need the existing logged-in Brave session

Use an existing-session profile instead of fighting the managed one:

{
  browser: {
    enabled: true,
    defaultProfile: "brave",
# 
    profiles: {
      brave: {
        driver: "existing-session",
        attachOnly: true,
        userDataDir: "~/Library/Application Support/BraveSoftware/Brave-Browser",
        color: "#FB542B"
      }
    }
  }
}

Then in Brave:

  • open brave://inspect/#remote-debugging
  • enable remote debugging
  • keep Brave running
#
  • approve the attach prompt when OpenClaw connects

Smoke test:

openclaw browser start --browser-profile brave
openclaw browser status --browser-profile brave
openclaw browser tabs --browser-profile brave
openclaw browser snapshot --browser-profile brave

Option B, if you want the fuller managed-browser path

Keep openclaw managed, but focus on why the launched browser is dying before CDP is stable. The logs are the important next step there.

Docs:

hollow compass
mystic zodiacBOT
#

Nice catch, that issue is real, but it looks more specific than this thread.

Issue #66065 is about a 2026.4.12 regression with the managed browser on Docker/Linux, with 2026.4.10 as the known-good version.

So my read would be:

  • if this machine is actually on 2026.4.12 or newer, trying 2026.4.10 is a very reasonable A/B test
  • if it’s on 2026.4.9 on macOS, that issue probably is not the same root cause

I’d ask for this first:

openclaw --version
openclaw browser status --browser-profile openclaw

If --version comes back 2026.4.12+, then yes, I’d absolutely test 2026.4.10.