#Browser Relay attaches normal tabs but fails on Gmail / Google tabs (WSL2 + Windows Chrome)

1 messages · Page 1 of 1 (latest)

sturdy hull
#

Trying to get OpenClaw Browser Relay working with Gmail/Google tabs on Windows Chrome, with OpenClaw running in WSL2 Ubuntu.

What works:

  • relay is reachable/authenticated at http://127.0.0.1:18793/
  • relay attaches to normal sites like example.com
  • OpenClaw can control those attached tabs
  • from an attached normal tab, OpenClaw can navigate into Gmail

What fails:

  • attaching directly to a Gmail tab fails
  • the debugger/relay session drops right after the attached tab lands on Gmail
  • after that, OpenClaw no longer sees any attached tabs
  • clicking the relay icon on Gmail again gives the same failure

Has anyone seen this before? Is there a known Chrome/debugger restriction on Gmail/Google properties, or a recommended best-practice path for reliable Google account access in OpenClaw?

still hareBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

scenic iglooBOT
#

Yep — this pattern has shown up before, and it’s usually not a Gmail-only hard restriction.

What you’re seeing (attach works on normal tab, drops around Gmail/account redirects) is typically a relay + tab lifecycle detach problem. Google properties do aggressive redirects/process swaps, which can expose fragility in extension-relay flows.

For your topology (Gateway in WSL2, Chrome on Windows), best-practice is:

  1. Prefer raw remote CDP (Windows Chrome --remote-debugging-port=9222 + WSL2 profile pointing to that endpoint), rather than toolbar relay.
  2. Or run a node host on Windows and use host-local browser attach there.

Docs:

Can you share this first so we can pin exact behavior by build?

OpenClaw
WSL2 + Windows + remote Chrome CDP troubleshooting - OpenClaw
OpenClaw
Browser (OpenClaw-managed) - OpenClaw
OpenClaw
FAQ - OpenClaw