Summary
The bundled browser plugin is loaded and browser automation is generally available, but the user existing-session attach path is brittle while the managed openclaw browser lane remains the reliable default.
In real usage, the managed browser can open and inspect sites like Figma, Framer, and TradingView, but profile="user" fails before tabs become available.
Observed failure
Exact error observed during user profile attach:
Chrome MCP existing-session attach for profile "user" timed out waiting for tabs to become available.
Cause: Could not find DevToolsActivePort for chrome at /Users/alex/Library/Application Support/Google/Chrome/DevToolsActivePort
This occurred even after:
- enabling browser config
- keeping Chrome open
- attempting the documented inspect / remote debugging flow
- restarting the gateway
What appears to be working
@openclaw/browser plugin is loaded
- managed
openclaw browser can open tabs and inspect content
- general browser tool availability is not the issue
- config such as
browser.enabled=true and browser.defaultProfile="openclaw" is fine
What appears broken or too brittle
- Existing-session attach assumes
DevToolsActivePort is present in the expected Chrome profile path.
- Failure mode loops users into repeated “approve prompt and retry” guidance even when the core issue is earlier / different.
- Diagnostics do not clearly separate:
- browser plugin loaded
- managed browser healthy
- existing-session attach unhealthy
- For complex editors like Figma/Framer, the browser lane may be inspectable but not actionable. This issue does not claim a full fix there, but better fallback messaging would help.
Product recommendation
Prefer the managed openclaw browser lane by default, and treat profile=\"user\" as an explicit opt-in fallback only when existing login state is truly required.
Suggested improvements
- Harden
existing-session readiness detection beyond a single DevToolsActivePort assumption.
- Improve fallback behavior when Chrome MCP attach fails, for example:
- suggest managed browser lane immediately
- distinguish missing Chrome / wrong profile / attach approval / DevToolsActivePort failure
- Improve diagnostics so
plugins doctor or browser status can explicitly show:
- managed browser healthy
- existing-session unhealthy
- Consider clearer UX for canvas-heavy tools where refs are inspectable but not reliably actionable.
Reproduction context
This was reproduced in a local macOS OpenClaw setup while trying to automate Figma / Framer workflows through both the managed browser and profile=\"user\".
Summary
The bundled browser plugin is loaded and browser automation is generally available, but the
userexisting-session attach path is brittle while the managedopenclawbrowser lane remains the reliable default.In real usage, the managed browser can open and inspect sites like Figma, Framer, and TradingView, but
profile="user"fails before tabs become available.Observed failure
Exact error observed during
userprofile attach:This occurred even after:
What appears to be working
@openclaw/browserplugin is loadedopenclawbrowser can open tabs and inspect contentbrowser.enabled=trueandbrowser.defaultProfile="openclaw"is fineWhat appears broken or too brittle
DevToolsActivePortis present in the expected Chrome profile path.Product recommendation
Prefer the managed
openclawbrowser lane by default, and treatprofile=\"user\"as an explicit opt-in fallback only when existing login state is truly required.Suggested improvements
existing-sessionreadiness detection beyond a singleDevToolsActivePortassumption.plugins doctoror browser status can explicitly show:Reproduction context
This was reproduced in a local macOS OpenClaw setup while trying to automate Figma / Framer workflows through both the managed browser and
profile=\"user\".