openclaw - 💡(How to fix) Fix Bug: browser user profile (existing-session / Chrome MCP) ignores cdpUrl config in WSL environment

Bug: browser user profile (existing-session / Chrome MCP) ignores cdpUrl config in WSL environment

Environment

• OpenClaw version: 2026.5.7 (eeef486)
• OS: Windows 11 + WSL2 (Ubuntu 24.04), networkingMode=mirrored
• Chrome: 147.0.7727.119 (Windows, not WSL)
• Chrome MCP: 0.26.0 (via npx)
• WSL config: dnsTunneling=true, networkingMode=mirrored

Description

The built-in user profile with driver: "existing-session" (Chrome DevTools MCP) does not work when Chrome runs on the Windows host and OpenClaw runs inside WSL2. The Chrome MCP subprocess is always launched with --autoConnect, which looks for Chrome's DevToolsActivePort at the Linux path (~/.config/google-chrome/DevToolsActivePort) instead of the Windows Chrome data directory.

Setting cdpUrl on the user profile (or mcpArgs with --browserUrl) has no effect — the Chrome MCP subprocess always receives --autoConnect regardless of configuration.

Expected behavior

When browser.profiles.user.cdpUrl is set to "http://127.0.0.1:9222", OpenClaw should pass --browserUrl http://127.0.0.1:9222 to the Chrome MCP subprocess instead of --autoConnect.

This is documented at https://docs.openclaw.ai/zh-CN/tools/browser — "当在现有会话配置文件上设置 cdpUrl 时，OpenClaw 会跳过 --autoConnect，并自动将端点转发给 Chrome MCP".

Actual behavior

Chrome MCP is always launched with --autoConnect:

npm exec chrome-devtools-mcp@latest --autoConnect --experimentalStructuredContent --experimental-page-id-routing

Error:

Could not find DevToolsActivePort for chrome at /home/zht12/.config/google-chrome/DevToolsActivePort

Steps to reproduce

1. Set up OpenClaw in WSL2 (Ubuntu) with Windows Chrome on the host
2. Enable remote debugging in Chrome via chrome://inspect/#remote-debugging (Chrome 144+ MCP mode, server running at 127.0.0.1:9222)
3. Configure user profile in openclaw.json:

   {
     "browser": {
       "profiles": {
         "user": {
           "cdpUrl": "http://127.0.0.1:9222"
         }
       }
     }
   }

4. Restart gateway
5. Run openclaw browser --browser-profile user start
6. Observe: Chrome MCP subprocess uses --autoConnect (ignores cdpUrl), fails to find Chrome

Root cause analysis (from source code)

In chrome-mcp-BOqL_stO.js:

• normalizeChromeMcpOptions() correctly maps cdpUrl → browserUrl
• buildChromeMcpConnectionArgs() correctly returns ["--browserUrl", url] when browserUrl is set
• BUT chromeMcpProfileOptionsFromParams(params) returns params.profile ?? params.userDataDir
• If params.profile is passed as a string (profile name like "user") rather than the resolved config object, normalizeChromeMcpOptions("user") takes the string path and ignores all config fields (cdpUrl, mcpArgs, etc.)
• The built-in user profile's config is apparently not being resolved and passed as an object to the Chrome MCP session factory

Workaround attempted

• mcpArgs: ["--browserUrl", "http://127.0.0.1:9222"] — also ignored
• userDataDir: "/mnt/c/Users/.../Chrome/User Data" — also ignored (profile options not passed as object)

Proposed fix

When calling Chrome MCP for existing-session profiles, resolve the full profile config object (including cdpUrl, mcpArgs, userDataDir) and pass it to normalizeChromeMcpOptions() as an object rather than just the profile name string.

For WSL2 users, also consider:

• Auto-detecting WSL environment and checking Windows Chrome paths
• Supporting a browserUrl field directly on the profile config (documented but not working)