Summary

existing-session browser attach hangs on this machine even though Chrome remote debugging stays live and the OpenClaw gateway stays reachable. In the same environment, a local Playwright worker works normally, which isolates the failure to the OpenClaw existing-session path rather than general browser automation.

OpenClaw version

• OpenClaw 2026.3.13 (61d171a)

Environment

• OS: Ubuntu 24.04.4 LTS
• Kernel: 6.17.0-19-generic
• Browser: Google Chrome 146.0.7680.80

Exact browser profile config

{
  "browser": {
    "attachOnly": false,
    "enabled": true,
    "defaultProfile": "user",
    "profiles": {
      "user": {
        "driver": "existing-session",
        "attachOnly": true,
        "color": "#00AA00"
      }
    }
  }
}

This is from ~/.openclaw/openclaw.json.

What was verified

Chrome remote debugging stayed live

~/.config/google-chrome/DevToolsActivePort existed and contained:

9222
/devtools/browser/b2c55e12-eb64-4fd2-bf68-de6331509473

Chrome remote debugging UI was enabled and reported:

• server running at 127.0.0.1:9222

Gateway stayed reachable

openclaw gateway probe consistently reported successful loopback connectivity, e.g.:

Targets
Local loopback ws://127.0.0.1:18789
  Connect: ok (33ms) · RPC: limited - missing scope: operator.read

So this does not appear to be a general gateway outage.

Exact commands that hung

These commands repeatedly hung / timed out instead of returning browser status:

openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs

I also saw equivalent timeouts via the OpenClaw browser tool when using profile="user".

Additional observations

• chrome-devtools-mcp was being launched by OpenClaw.
• Chrome remote debugging remained live while the commands hung.
• Gateway remained reachable while the commands hung.

Control test: Playwright works on the same machine

I created a simple local Playwright worker and verified it works end-to-end on the same machine.

Successful repeated runs produced screenshots such as:

• /home/leo/.openclaw/workspace/browser-workers/out/example.png
• /home/leo/.openclaw/workspace/browser-workers/out/example-2.png

So browser automation in general works here; the failure appears isolated to the OpenClaw existing-session attach path.

Cleanup / reset attempts

I tried the following recovery steps:

1. verified Chrome remote debugging was enabled
2. verified DevToolsActivePort existed
3. verified gateway reachability with openclaw gateway probe
4. restarted the OpenClaw gateway
5. cleaned up / attempted cleanup of stale chrome-devtools-mcp helper processes
6. re-ran a single fresh attach test

Result: cleanup/reset did not recover the existing-session path.

Expected behavior

With Chrome remote debugging enabled and the user existing-session profile configured, I expected at minimum:

• openclaw browser --browser-profile user status to return promptly
• openclaw browser --browser-profile user tabs to return the live tabs

Actual behavior

Those commands hang until timeout even though:

• Chrome remote debugging stays live
• the OpenClaw gateway stays reachable
• Playwright works on the same host

Possible area to inspect

This seems likely to be somewhere in the OpenClaw browser existing-session / Chrome DevTools MCP integration path, or a stuck consent/attach state that does not resolve correctly and leaves browser commands hanging.