Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

manual-cdp attachOnly profile does not detect a live Chrome CDP session and reports no tabs even when a valid page target exists.

Steps to reproduce

1. Configure browser profile:

   • cdpUrl = http://127.0.0.1:9222
   • attachOnly = true

2. Launch Chrome manually:
   chrome --remote-debugging-port=9222 --user-data-dir="C:\temp\chrome-openclaw-manual"

3. Open a normal webpage (e.g. WordPress admin login)

4. Verify CDP endpoint:
   http://127.0.0.1:9222/json/list
   → contains a "type": "page" target

5. Run:
   openclaw browser --browser-profile manual-cdp tabs
   openclaw browser --browser-profile manual-cdp snapshot

Expected behavior

OpenClaw detects the external CDP session as running and returns the active page target when listing tabs or taking a snapshot.

Actual behavior

OpenClaw reports:

• "No tabs (browser closed or no targets)."
• "Browser attachOnly is enabled and profile 'manual-cdp' is not running."

This occurs even though the CDP endpoint is reachable and /json/list contains a valid "type": "page" target.

OpenClaw version

Latest (no tagged release; running current main branch) v2026 4.11

Operating system

Windows 11 Pro (version 25)

Install method

npm/global install (node_modules openclaw)

Model

NOT_APPLICABLE

Provider / routing chain

NOT_APPLICABLE

Additional provider/model setup details

NOT_APPLICABLE

Logs, screenshots, and evidence

- /json/version returns valid CDP endpoint
- /json/list returns targets including a "type": "page" (WordPress login page)
- openclaw browser --browser-profile manual-cdp tabs → "No tabs (browser closed or no targets)"
- openclaw browser --browser-profile manual-cdp snapshot → "profile is not running"

Additional logs show intermittent:
token_mismatch
(control UI/webchat), but CDP endpoint is independently verified as functional.

Impact and severity

Affected: users relying on manual-cdp / attachOnly browser profiles

Severity: blocks workflow

Frequency: always reproducible

Consequence:

• prevents browser automation fallback
• blocks workflows requiring logged-in browser sessions (e.g. Elementor / WordPress admin)
• forces manual-only interaction despite valid CDP connection

Additional information

All common causes were ruled out:

• device pairing repaired
• device has full operator scopes
• gateway restarted
• Chrome CDP endpoint confirmed working
• real page target exists

This isolates the issue to attachOnly profile state detection or CDP target handling inside OpenClaw.