PR #60960: fix for mcp connection issue (closes #60903)

• Repository: openclaw/openclaw
• Author: juliabush
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60960

Description (problem / solution / changelog)

Summary

• Problem: Chrome MCP existing-session attach ignored configured cdpUrl and always used --autoConnect, causing connection failures to running Chrome instances.
• Why it matters: Users with explicit CDP endpoints (e.g. http://127.0.0.1:9222) could not attach, breaking browser control via MCP.
• What changed: Propagated cdpUrl from profile → session → CLI args and switched to --browserUrl when provided.
• What did NOT change (scope boundary): No changes to MCP protocol, gateway routing, or browser interaction logic.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #60903
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: cdpUrl was defined in profile config but never propagated into Chrome MCP session creation, causing fallback to --autoConnect.
• Missing detection / guardrail: No test verifying attach behavior with explicit cdpUrl.
• Contributing context (if known): Recent MCP attach changes introduced structuredContent flags but did not update argument handling.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: chrome-mcp session creation / args construction
• Scenario the test should lock in: Given profile with cdpUrl, MCP must launch with --browserUrl instead of --autoConnect.
• Why this is the smallest reliable guardrail: Verifies argument construction without requiring full browser runtime.
• Existing test that already covers this (if any): None
• If no new test is added, why not: Focused fix; can be covered in follow-up

User-visible / Behavior Changes

• MCP can now correctly attach to existing Chrome sessions when cdpUrl is configured.

Diagram (if applicable)

Before:
CLI -> MCP (--autoConnect) -> fails to attach

After:
CLI -> MCP (--browserUrl=http://127.0.0.1:9222) -> attaches -> works

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: Ubuntu 22
• Runtime/container: local
• Model/provider: N/A
• Integration/channel: browser MCP
• Relevant config: profile with cdpUrl=http://127.0.0.1:9222

Steps

1. Start Chrome with remote debugging
2. Run openclaw browser status
3. Attempt MCP attach

Expected

• Successfully attaches and lists pages

Actual

• Previously failed with connection closed / MCP attach error

Evidence

• Trace/log snippets

Human Verification (required)

• Verified scenarios:

  • MCP attaches using cdpUrl
  • Tabs can be listed

• Edge cases checked:

  • No cdpUrl still uses --autoConnect

• What you did not verify:

  • Remote (non-localhost) CDP endpoints

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Incorrect cdpUrl could break attach

  • Mitigation: Falls back to existing behavior when undefined

Changed files

• extensions/browser/src/browser/chrome-mcp.ts (modified, +29/-6)