openclaw - 💡(How to fix) Fix [Bug]: attach-only external CDP profile returns targetId from browser.open, but browser.tabs stays empty and snapshot fails with tab not found [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Summary

When OpenClaw is configured to use an attach-only external CDP profile (Browserless-style endpoint on localhost), the browser tool can return a targetId from browser.open, but subsequent browser-tool state is inconsistent:

• browser.tabs returns an empty list
• browser.snapshot(targetId=...) fails with tab not found
• the external CDP endpoint itself is healthy and /json/list shows page targets

This makes multi-step browser workflows impossible even though the underlying CDP service is reachable and can create/list pages.

Steps to reproduce

1. Configure OpenClaw browser with an attach-only external CDP profile on localhost, for example:

{
  "browser": {
    "enabled": true,
    "evaluateEnabled": true,
    "headless": true,
    "noSandbox": true,
    "attachOnly": true,
    "defaultProfile": "rsshub-browserless",
    "profiles": {
      "rsshub-browserless": {
        "cdpUrl": "http://127.0.0.1:13000",
        "driver": "openclaw",
        "color": "22AA88"
      }
    }
  }
}

1. Confirm the external CDP service is healthy:

curl -fsS http://127.0.0.1:13000/json/version
curl -fsS http://127.0.0.1:13000/json/list

1. Check OpenClaw browser status:

openclaw browser status --json

1. Use the browser tool or CLI to open a page:

{"action":"open","target":"host","url":"https://example.com"}

1. Immediately list tabs and try to snapshot the returned target:

{"action":"tabs","target":"host"}
{"action":"snapshot","target":"host","targetId":"<returned targetId>","snapshotFormat":"ai"}

Expected behavior

If browser.open succeeds and returns a targetId, the browser tool should be able to:

• list the tab in browser.tabs
• resolve the returned targetId
• perform snapshot / screenshot / act on that tab

At minimum, the browser tool state should stay consistent with the underlying CDP target list.

Actual behavior

Observed on latest stable 2026.4.1:

• browser.status reports healthy after service fixes:
  • running: true
  • cdpReady: true
  • cdpHttp: true
  • attachOnly: true
• browser.open succeeds and returns a targetId
• browser.tabs still returns []
• browser.snapshot on that targetId fails with:

{"status":"error","tool":"browser","error":"tab not found"}

Meanwhile, the external CDP endpoint itself can still list pages:

curl -fsS http://127.0.0.1:13000/json/list
curl -fsS 'http://127.0.0.1:13000/json/new?https://example.com'

Example observed response:

[{"description":"","devtoolsFrontendUrl":"/devtools/inspector.html?ws=127.0.0.1:13000/devtools/page/BROWSERLESS4RZSOSIKP4W6TRRW2D1MF","targetId":"/devtools/page/BROWSERLESS4RZSOSIKP4W6TRRW2D1MF","title":"about:blank","type":"page","url":"about:blank","webSocketDebuggerUrl":"ws://127.0.0.1:13000/devtools/page/BROWSERLESS4RZSOSIKP4W6TRRW2D1MF"}]

So the CDP service can create/list targets, but OpenClaw browser-tool state remains empty/non-resolvable.

OpenClaw version

2026.4.1

Operating system

Linux 6.8.0-106-generic (x64)

Install method

global npm install + systemd user service

Model

cli-codex/gpt-5.4

Provider / routing chain

Telegram -> OpenClaw gateway -> browser tool (target=host) -> attach-only external CDP on 127.0.0.1:13000

Config file / key location

~/.openclaw/openclaw.json -> browser

Additional provider/model setup details

Not model-specific.

Relevant browser config details:

• attachOnly: true
• default profile points to an external localhost CDP service
• cdpUrl: http://127.0.0.1:13000
• no local Chrome/Chromium installed on the host

Logs, screenshots, and evidence

Browser tool state after fixing unrelated service entrypoint mismatch:

{
  "enabled": true,
  "profile": "rsshub-browserless",
  "driver": "openclaw",
  "transport": "cdp",
  "running": true,
  "cdpReady": true,
  "cdpHttp": true,
  "pid": null,
  "cdpPort": 13000,
  "cdpUrl": "http://127.0.0.1:13000",
  "chosenBrowser": null,
  "detectedBrowser": null,
  "detectedExecutablePath": null,
  "detectError": null,
  "userDataDir": null,
  "color": "22AA88",
  "headless": true,
  "noSandbox": true,
  "executablePath": null,
  "attachOnly": true
}

Observed browser tool behavior:

{"action":"open","target":"host","url":"https://example.com"}
=> {"targetId":"1985FEAE139BCE0FD64BA0FDCFC6FFD3","title":"","url":"https://example.com","type":"page"}

{"action":"tabs","target":"host"}
=> {"tabs":[]}

{"action":"snapshot","target":"host","targetId":"1985FEAE139BCE0FD64BA0FDCFC6FFD3","snapshotFormat":"ai","refs":"aria"}
=> {"status":"error","tool":"browser","error":"tab not found"}

Gateway log excerpts before/after diagnosis:

[tools] browser failed: tab not found raw_params={"action":"snapshot",...}

Additional diagnostic observation:

• openclaw doctor --non-interactive also reported a gateway service entrypoint mismatch (dist/entry.js -> dist/index.js)
• fixing that mismatch improved status reporting (cdpHttp became true) but did not fix the browser-tool inconsistency above
• so the entrypoint mismatch was noise / a separate issue, not the root cause of this browser bug

Impact and severity

Affected users/systems:

• users relying on attach-only external CDP / Browserless-style localhost profiles

Severity:

• Medium to high

Frequency:

• Reproduced consistently in this environment

Consequence:

• browser automation is effectively unusable for multi-step flows
• the tool reports a target exists, but cannot list or resolve it afterward
• diagnosis is confusing because the underlying CDP service looks healthy

Additional information

This looks related to existing browser state-sync / remote-CDP issues, but does not seem identical to the current open reports:

• #50321 — chat/browser tool returns no tabs in a Chrome relay + Docker/node setup
• #33093 — /json/list shows target but action layer gets tab not found after navigation in extension relay
• #58646 — remote CDP profiles lose session between commands (Browserbase)
• #49815 — Browserless topology/endpoint classification issues

What seems distinct here is:

• attach-only localhost external CDP is healthy
• OpenClaw browser.open can create/return a target
• OpenClaw browser.tabs remains empty immediately afterward
• OpenClaw snapshot cannot resolve the same returned target
• external /json/list still shows targets

That suggests a browser-tool state tracking / target-resolution bug in the attach-only external CDP path, rather than simple CDP reachability failure.