openclaw - 💡(How to fix) Fix [Bug]: Chrome MCP existing-session `profile=user` reports ready but all page tools time out on macOS

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Chrome MCP existing-session browser control for profile=user appears to attach successfully, but page-level operations are unusable.

The managed OpenClaw browser profile works correctly, but the existing user Chrome profile does not. This is important because some sites, such as Shopee, may trigger anti-bot checks when using a fresh managed profile, so the signed-in user profile is required.

With profile=user, OpenClaw reports the browser as running and CDP-ready:

running: true
cdpReady: true
cdpHttp: true
transport: chrome-mcp
driver: existing-session
attachOnly: true

However, all page-level Chrome MCP tools time out, including:

• list_pages
• take_snapshot
• take_screenshot
• evaluate_script

This happens even when Chrome has only one active tab and the remote debugging permission has been allowed.

Steps to reproduce

1. On macOS, open Google Chrome.

2. Enable Chrome remote debugging permission through:

   chrome://inspect/#remote-debugging

3. Turn on:

   Allow remote debugging for this browser instance

4. Open a normal signed-in user Chrome window.

5. Keep only one active tab open, for example Shopee Thailand purchase page.

6. Check OpenClaw browser status:

   openclaw browser --browser-profile user status

7. Observe that the user profile appears ready.

8. Try listing tabs:

   openclaw browser --browser-profile user tabs

9. Try taking a snapshot through the browser tool or equivalent browser operation.

10. Try screenshot or evaluate operations on the active page.

Expected behavior

If profile=user reports:

running: true
cdpReady: true
cdpHttp: true

then page-level operations should work, or at minimum fail quickly with a specific actionable error.

Expected working operations include:

• listing pages/tabs
• taking an accessibility/DOM snapshot
• taking a screenshot
• evaluating JavaScript on the active page

The behavior should be comparable to the managed profile=openclaw browser profile.

Actual behavior

The managed profile=openclaw browser profile works:

profile=openclaw
open https://example.com -> success
snapshot -> success

But the existing-session profile=user only reaches status readiness. Page-level tools time out:

Chrome MCP "list_pages" timed out after 8000ms. Session reset for reconnect.

Chrome MCP "take_snapshot" timed out after 12000ms / 30000ms / 60000ms.

Chrome MCP "take_screenshot" timed out after 60000ms.

Chrome MCP "evaluate_script" timed out after 12000ms.

The problem persists even when:

• Chrome remote debugging permission is allowed
• Chrome has only one active tab
• the target page is focused
• Chrome shows it is being controlled by automated test software
• openclaw browser --browser-profile user status reports ready

OpenClaw version

2026.5.7

Operating system

macOS 26.4.1

Install method

npm global

Model

openai-codex/gpt-5.5

Provider / routing chain

openclaw->openai-codex/gpt-5.5

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Severity: High for real-world browser automation.

Impact:

• Existing signed-in Chrome user profile cannot be controlled through OpenClaw.
• Some websites cannot be reliably automated with a fresh managed profile because they may trigger anti-bot/login checks.
• Browser status reports ready, but actual page control is unusable.
• The failure mode is misleading because readiness succeeds while all page tools time out.
• This blocks workflows that require the real user browser session.

Requested fix

Please investigate Chrome MCP existing-session support for macOS Chrome 148.

Specifically:

• Why does profile=user report running=true, cdpReady=true, and cdpHttp=true, while all page tools time out?
• Is Chrome MCP attaching to the browser but failing to select/control the active page?
• Should readiness verify that at least one page-level operation can complete?
• Can active-page operations avoid requiring list_pages when the user only needs the currently focused page?
• Can errors distinguish between:
  • attach success
  • tab/page discovery failure
  • page tool execution timeout
  • permission/selection problems

Related issue: #65125 may be related, but this appears to be a later-stage failure. In this case, the user profile reaches ready status, but page-level Chrome MCP operations remain unusable.

Additional information

Environment

• OpenClaw version: 2026.5.7 (eeef486)

• OS: macOS / Darwin arm64 26.4.1

• Chrome version: 148.0.7778.97 (Official Build) (arm64)

• Browser profile tested:

  • profile=openclaw / managed CDP profile: works
  • profile=user / Chrome MCP existing-session profile: status works, page tools timeout

• Channel/runtime: Telegram direct chat / main agent

• Chrome executable detected by OpenClaw:

  /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

Logs, screenshots, and evidence

profile=user status succeeds:

profile: user
enabled: true
running: true
transport: chrome-mcp
driver: existing-session
detectedBrowser: chrome
detectedPath: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
cdpReady: true
cdpHttp: true
attachOnly: true

Port is listening:

netstat -an | grep 9222
tcp4 0 0 127.0.0.1.9222 *.* LISTEN

Chrome UI confirms automation control:

Chrome is being controlled by automated test software

Managed profile works:

profile=openclaw
open https://example.com -> success
snapshot -> success

Existing-session user profile page tools fail:

Chrome MCP "list_pages" timed out after 8000ms. Session reset for reconnect.

Chrome MCP call failed profile="user" tool="take_snapshot" attempt=1 timeoutMs=60000:
MCP error -32001: Request timed out

Chrome MCP call failed profile="user" tool="take_screenshot" attempt=1 timeoutMs=60000:
MCP error -32001: Request timed out

Chrome MCP call failed profile="user" tool="evaluate_script" attempt=1 timeoutMs=12000:
Chrome MCP "evaluate_script" timed out after 12000ms. Session reset for reconnect.

Debugging already attempted

Several local runtime patches were attempted and then rolled back. These patches helped isolate the failure but did not fix it.

Attempted patches included:

• increasing the existing-session attach timeout
• bypassing the list_pages readiness gate for active-page operations
• avoiding invalid Playwright fallback when cdpUrl is null
• threading browser tool timeoutMs through the gateway/browser request wrapper
• increasing take_snapshot timeout to 30–60 seconds
• adding active-page no-list_pages paths for snapshot/screenshot/evaluate

After these changes, failures moved past earlier wrapper timeouts, but the underlying Chrome MCP page methods still timed out.

All local patches were rolled back so the installation can be tested from a clean baseline again.