openclaw - 💡(How to fix) Fix Browser existing-session Chrome MCP tabs fail with 300ms attach timeout despite doctor passing

Summary

browser existing-session / Chrome MCP profile can pass browser doctor, but normal browser operations such as tabs still fail with a hard-coded/implicit 300ms attach timeout:

BrowserProfileUnavailableError: Chrome MCP existing-session attach for profile "user" timed out after 300ms.

This makes the signed-in Chrome profile appear healthy in diagnostics while actual use remains unreliable/unusable.

Environment

• OpenClaw: 2026.5.28-beta.4
• OS: macOS 26.6 arm64
• Node: 25.6.0
• Chrome: 148.0.7778.216
• Browser profile config:

{
  "browser": {
    "enabled": true,
    "defaultProfile": "user",
    "profiles": {
      "user": {
        "driver": "existing-session",
        "color": "#4285F4",
        "mcpArgs": ["--autoConnect"]
      }
    },
    "ssrfPolicy": {
      "dangerouslyAllowPrivateNetwork": true
    }
  }
}

Reproduction

1. Configure a browser.profiles.user profile with driver: "existing-session" and Chrome MCP auto-connect.
2. Keep normal Google Chrome running locally.
3. Run browser doctor for the user profile.
4. Run a normal tabs/snapshot operation for the same profile.

Observed behavior

browser doctor passes:

{
  "ok": true,
  "profile": "user",
  "transport": "chrome-mcp",
  "checks": [
    { "id": "plugin-enabled", "status": "pass", "summary": "enabled" },
    { "id": "profile", "status": "pass", "summary": "user via chrome-mcp" },
    { "id": "attach-target", "status": "pass", "summary": "Chrome MCP target is reachable" }
  ],
  "status": {
    "driver": "existing-session",
    "transport": "chrome-mcp",
    "running": true,
    "cdpReady": true,
    "cdpHttp": true,
    "pageReady": true,
    "attachOnly": true
  }
}

But browser tabs / tool-equivalent operation fails:

BrowserProfileUnavailableError: Chrome MCP existing-session attach for profile "user" timed out after 300ms.

The error persists even when the browser tool call is given a higher timeoutMs.

Additional evidence

Running Chrome MCP manually with the same arguments works, but takes materially longer than 300ms:

npx -y chrome-devtools-mcp@latest \
  --autoConnect \
  --no-usage-statistics \
  --experimentalStructuredContent \
  --experimental-page-id-routing

A direct MCP client test showed roughly:

connect 1864ms
tools 1867ms
pages 4427ms

So the 300ms budget is too aggressive for a normal first attach/list-pages flow on this machine.

Expected behavior

If browser doctor says Chrome MCP existing-session is reachable, tabs/snapshot should also use a realistic attach/readiness timeout, or should honor the caller-provided timeoutMs during attach/list-pages.

Suspected cause

There appears to be an internal path where listChromeMcpTabs(profile.name, profile) is called without forwarding a timeout, so it falls back to an implicit 300ms timeout. This affects normal operations even though doctor uses a different/ephemeral probe path and passes.

Relevant symptoms from local inspection:

• server-context has paths that call listChromeMcpTabs(profile.name, profile) without an explicit timeout.
• chrome-mcp then reports: timed out after 300ms.

Impact

Existing-session browser automation with signed-in Chrome profiles is unreliable: diagnostics pass, but actual operations fail immediately. This affects workflows that rely on logged-in Chrome sessions.

Possible fix

• Forward the request/action timeout into Chrome MCP attach/list-pages calls used by tabs, snapshot, and ensureTabAvailable; or
• Raise the default existing-session attach/list-pages timeout from 300ms to something closer to the existing Chrome MCP handshake/readiness windows; and
• Ideally make browser doctor and normal operations exercise the same path or report this mismatch.