Troubleshooting
Chrome Extension Can’t Reach Remote Gateway?
A fast, deterministic setup for running browser control against a remote OpenClaw gateway without flaky tunnel loops.
Community pattern: users run OpenClaw on a remote server, then try random public tunnels for the browser extension and get intermittent disconnects. The fix is to pick one stable access path and prove it with a tiny canary test.
Reality check: if your gateway is behind NAT/firewall, the extension cannot reach it directly unless you provide a reachable URL (public reverse proxy, private mesh VPN, or secure tunnel).
Fast path (5 steps)
1) Confirm gateway is healthy on the server first
From the server host, verify OpenClaw is running before touching network plumbing:
openclaw gateway status
If unhealthy locally, remote access fixes won't matter yet.
2) Choose one access lane (don't mix three)
- Best for reliability: private mesh network (e.g., Tailscale/ZeroTier) + private URL
- Best for teams: reverse proxy with TLS and strict allowlist
- Temporary testing: tunnel URL (acceptable for quick canaries, not ideal for daily production)
3) Lock origin + token settings
Most remote failures are origin mismatch or stale token issues. Make sure:
- You use the exact remote origin (scheme + host + port)
- The extension is pointed to the same origin your gateway allows
- Gateway token in the extension matches current server token
4) Run a tiny remote canary
From the machine running Chrome, do one tiny command only:
Open a blank page, return current URL, stop.
If this fails, do not start full workflows yet.
5) Only then run real browser tasks
Once canary succeeds, move to login/forms/workflows one variable at a time.
Known-good prompt to paste to your agent
We are testing remote browser connectivity only.
Do exactly this:
1) Open about:blank
2) Return the active URL
3) Return whether remote browser control is working: YES or NO
4) If NO, return exact error text and whether it looks like:
- gateway unreachable
- token mismatch
- origin not allowed
- timeout
Do not do any other steps.
High-friction failure patterns
- Works once, then dies: unstable tunnel endpoint rotation or tunnel sleep policy.
- 401/unauthorized behavior: extension token and gateway token are out of sync.
- Origin not allowed: remote URL in browser doesn't match gateway allowlist exactly (scheme/host/port mismatch).
- Long hangs/timeouts: remote path is blocked by firewall/proxy/NAT or stale DNS.
Advanced edge cases (from recent community reports)
- NAT/firewall with unstable public tunnels: tools like LocalTunnel/Serveo can rotate endpoints or drop sessions, which breaks extension reliability. For day-to-day work, move to a stable lane (private mesh VPN or reverse proxy).
- Token survives in one browser profile but fails in another: extension on Profile A may still hold an old token while Profile B has the new one. Re-enter token in the exact active profile and rerun canary.
- Remote URL changes but allowlist does not: if your tunnel URL changed, your prior `allowedOrigins` entry is now stale. Update origin allowlist first, then reconnect.
- "It worked yesterday" after reboot: dynamic DNS/Tunnel URL or host IP changed after restart. Verify current endpoint before assuming model/tool failure.
Stable lane recommendation (to avoid tunnel loops)
If temporary tunnels keep dropping: pick one of these and standardize.
- Most stable for solo use: Tailscale/ZeroTier + private gateway URL
- Most stable for shared/team use: Reverse proxy + TLS + fixed DNS hostname
- Tunnel-only mode: Use for short tests only, not long-running production browser sessions
Loop-break rules (important)
Don't retry blindly: after two failed remote attempts, stop and capture exact error text + endpoint + timestamp. Random retries hide the root cause.
- Change one variable at a time (URL, token, origin allowlist, then retry).
- Never rotate multiple tunnel tools in one debugging pass.
- Keep one canonical remote URL and document it in your setup notes.
Support escalation packet (copy/paste)
Remote Browser Access Issue Packet
Expected behavior:
- Chrome extension should connect to remote OpenClaw gateway and run canary command.
Observed behavior:
- [exact error text]
Gateway endpoint used:
- [full URL with scheme + host + port]
Gateway health on server:
- openclaw gateway status => [output summary]
Token state:
- extension token recently updated? [yes/no]
- gateway token recently rotated? [yes/no/unknown]
Origin/allowlist state:
- configured allowed origin(s): [list]
- browser origin actually used: [value]
Network path:
- access method: [tailscale | reverse proxy | tunnel]
- if tunnel, provider + whether URL changed recently: [details]
Canary result:
- about:blank test => [pass/fail + timestamp]
Timezone:
- [your local timezone]
Bottom line: remote browser control is reliable when you treat it as network engineering first, automation second: stable endpoint, matching origin, fresh token, tiny canary, then real work.