Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

For Chrome MCP existing-session profiles (e.g. --browser-profile user), openclaw browser status exposes only transport-handshake fields (cdpHttp, cdpReady). It does not surface whether a page-level Chrome MCP tool round-trip (list_pages, etc.) actually succeeds. Operators and downstream tooling have no honest signal to distinguish "transport handshake passed" from "page tools are usable."

Steps to reproduce

1. On macOS, open Chrome and enable remote debugging via chrome://inspect/#remote-debugging → toggle Allow remote debugging for this browser instance ON. Confirm port 9222 is listening (netstat -an | grep 9222).
2. Run openclaw browser --browser-profile user status. Inspect the JSON response — fields are limited to transport-readiness signals.
3. Run openclaw browser --browser-profile user snapshot (or any page-level tool). It can hang for 8–60 seconds because page-discovery endpoints under the permission-gated debugging mode are not the same as the standard CDP HTTP endpoints chrome-devtools-mcp relies on.
4. Compare with the prior step: there was no field in status whose value differed between the working-transport-only state and a fully-working state.

Expected behavior

openclaw browser status should expose a separate, named field for page-tool readiness — independent of cdpReady and cdpHttp — so operators and tooling can determine, before a page-tool call hangs, whether the profile is actually usable.

The behavior should match the contract documented in docs/tools/browser.md:576, which lists tabs and snapshot as part of the existing-session smoke test (i.e., page-level reachability is part of the documented success state).

Actual behavior

status returns only cdpHttp and cdpReady, both derived from profileCtx.isTransportAvailable(...) for Chrome MCP profiles. There is no field in the response that reflects whether a page-level Chrome MCP tool can complete.

Code references (against current main, head 5ec84b3040):

• extensions/browser/src/browser/routes/basic.ts:77-85 — for chrome-mcp profiles, cdpHttp and cdpReady are both set to the same single isTransportAvailable(...) boolean. No page-level probe runs.
• extensions/browser/src/browser/server-context.availability.ts:153-167 — isReachable() already exists and calls listChromeMcpTabs (a real page-tool round-trip), but it is not invoked from the status route.
• extensions/browser/src/browser/routes/basic.existing-session.test.ts:274-290 — current regression test asserts running: true, cdpReady: true even when isReachable: async () => false. The contract gap is encoded in tests.
• extensions/browser/src/browser/client.types.ts:10-32 — BrowserStatus has no field that represents page-tool readiness.

OpenClaw version

2026.5.7 (also reproducible against current main, head 5ec84b3040)

Operating system

macOS 26.x / Darwin arm64

Install method

npm global

Model

n/a (browser status path)

Provider / routing chain

n/a

Additional provider/model setup details

n/a — this is a plugin status surface issue, not a model/routing issue.

Logs, screenshots, and evidence

$ openclaw browser --browser-profile user status
running: true
cdpReady: true       ← transport handshake only
cdpHttp: true        ← transport handshake only
transport: chrome-mcp
driver: existing-session
attachOnly: true

No field in this response distinguishes "transport handshaked" from "page tools succeed."

CDP HTTP discovery endpoints under Chrome's permission-gated debugging mode (the chrome://inspect toggle, as opposed to legacy --remote-debugging-port=9222) return 404, even though the TCP socket is open:

$ for ep in /json/version /json/list /json /json/protocol; do
    printf "%-20s " "$ep"
    curl -s -o /dev/null -w "HTTP %{http_code}\n" "http://127.0.0.1:9222${ep}"
  done
/json/version        HTTP 404
/json/list           HTTP 404
/json                HTTP 404
/json/protocol       HTTP 404

The TCP socket alone is enough to satisfy the transport-handshake checks (isTransportAvailable), but page-discovery endpoints that downstream Chrome MCP tools rely on do not respond.

Impact and severity

Affected: anyone using --browser-profile user (Chrome MCP existing-session attach), particularly under Chrome's permission-gated debugging mode. Severity: Medium. Because status has no page-readiness field, operators and Doctor/CLI tooling cannot programmatically detect the transport-vs-page gap; every diagnosis requires invoking a real page tool and waiting for it to time out. Frequency: Always reproducible on existing-session profiles where transport attaches but page tools fail. Consequence: Status output cannot be used to assert profile usability before issuing page-tool calls. Triage burden is shifted to per-call timeouts.

Additional information

Refs #80036.

Suggested fix shape (to bound review effort):

• Add a new pageReady: boolean field to BrowserStatus, derived from isReachable() for Chrome MCP profiles (with a status-bound timeout) and mirroring cdpReady for managed CDP profiles (where the WS handshake already covers page-level reachability).
• Skip the page probe when transport is down (cdpReady === false) so status latency does not regress on offline profiles.
• Update basic.existing-session.test.ts:274 so the existing assertion reflects the new contract (transport up + page-tools-down → cdpReady: true, pageReady: false).