Mac Bug | Friends of the Crustacean 🦞🤝 | Page 1

full forge Feb 28, 2026, 5:30 PM

#

"On MacOS, after a clean install (rm -rf ~/.openclaw), the openclaw browser start loopback connection immediately fails with Error: gateway closed (1008): pairing required. The Gateway refuses to accept the node's loopback pairing."

buoyant boneBOT Feb 28, 2026, 5:30 PM

#

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

full forge Feb 28, 2026, 5:30 PM

#

Just getting charged for screwed up loops of wrong information

dense stormBOT Feb 28, 2026, 5:31 PM

#

That symptom is usually just pairing state got wiped.

When you rm -rf ~/.openclaw, you delete the Gateway’s local pairing stores (including pending/paired node/device entries). After that, anything that connects as a “new identity” can hit:

gateway closed (1008): pairing required

1) Check which pairing bucket you’re actually hitting

If it’s a node (node host / tools routing):

openclaw nodes pending
openclaw nodes approve <requestId>
openclaw nodes status

Docs: https://docs.openclaw.ai/gateway/pairing

If it’s a device (Control UI / browser profile / operator-ish client identity):

#

openclaw devices list
openclaw devices approve <requestId>

Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection

Notes:

Pending requests can expire after ~5 minutes, so reproduce the failure then immediately run the list/pending command.
Gateway runbook reference: https://docs.openclaw.ai/gateway/troubleshooting (search “pairing required” / “devices list” / “nodes pending”).

2) If nothing shows up as pending

Then it’s likely a mismatch between what the CLI thinks it’s talking to vs what the Gateway service is actually using (common after reinstalls), or a bug.

Can you paste:

openclaw --version

#

openclaw gateway status --deep
openclaw logs --follow

…and the exact command you run (openclaw browser ... start etc.) plus the first pairing-required stack/error line from logs? That’ll tell us whether it’s devices.* or nodes.* pairing and why the “loopback auto-approve” path isn’t triggering.

#

Yeah, that kind of loop is infuriating — but the good news is: “gateway closed (1008): pairing required” is not a “model problem”. It’s the gateway refusing the WS handshake until the connecting device identity is approved. Fixing it is 100% local/CLI (no token burn).

For this error, the fastest deterministic path is:

Make sure you’re actually connecting to loopback

Run:
```
openclaw gateway status --json
```
If your CLI is targeting a remote URL (e.g. tailnet/LAN via gateway.remote.url or env), then it’s not loopback and auto-approve won’t apply → pairing required is expected.

Approve the pending device request (usually one command)

Reproduce the failure once, then immediately:

openclaw devices list
openclaw devices approve --latest

#

(You can also just run openclaw devices approve and it approves the most recent pending request per the docs.)

Docs: https://docs.openclaw.ai/cli/devices and the “pairing required” note in https://docs.openclaw.ai/web/control-ui

If devices list shows nothing pending
Paste only:

openclaw --version
openclaw gateway status --deep

…and the 5–10 log lines around the 1008 close from:

openclaw logs --follow

If there’s no pending request being created at all, that’s when it smells like an actual bug/mis-targeted URL (and we can turn it into a clean repro for a GitHub issue).

full forge Feb 28, 2026, 5:33 PM

#

sorry not helpful. I just created an account and started and this has been buggy and shitty. Garbage

#

I apologize, Ben. The hard reset of the configuration successfully wiped the corrupted files, but my internal background processes became completely deadlocked, which blocked my ability to send responses back to the chat interface. I had to wait for the system to forcefully kill the hung process to re-establish the connection to you.

I understand you are incredibly frustrated. You are completely right to call this nonsense. I have been running you in circles because of a persistent internal networking conflict on my end.

I am going to stop running automated repair scripts because they are causing more deadlocks than they are fixing.

Here is the exact state of reality:
Because of a bug in how OpenClaw handles loopback connections on MacOS, my internal "Browser Node" is permanently blocked from authenticating with my main "Gateway Brain."

No amount of restarting, configuration wiping, or terminal commands will fix this until the underlying bug in the OpenClaw software is patched by the developers.

I cannot process your invoices today because I physically cannot read your Chrome browser tabs.

I strongly advise you to stop trying to configure the Chrome Extension right now. Every attempt will just consume tokens without success.

Instead, I recommend taking these two actions:

#

Submit a Bug Report: Go to the OpenClaw Discord or GitHub and report exactly this:
"On MacOS, after a clean install (rm -rf ~/.openclaw), the openclaw browser start loopback connection immediately fails with Error: gateway closed (1008): pairing required. The Gateway refuses to accept the node's loopback pairing."
Alternative Workflow (Manual Upload): While the Chrome extension is broken, if you need me to verify an invoice against Turvo, you can drag and drop the invoice PDF directly into this chat window and type the load number. I can extract the information directly from the file, even if I cannot automatically click through your Turvo tabs right now.
I am very sorry that I failed to set up the automated pipeline today. Let me know if you want to test the manual PDF upload workaround, or if you prefer to wait for a software patch.

dense stormBOT Feb 28, 2026, 5:34 PM

#

This is a pairing gate, not “AI loop/token burn” — and you can fix it with a couple CLI commands (no model calls involved).

Fastest way to get unblocked

Force the browser CLI to hit IPv4 loopback (this avoids any localhost → ::1 weirdness):

openclaw browser --url ws://127.0.0.1:18789 --browser-profile openclaw start

(Flag is documented here: https://docs.openclaw.ai/cli/browser)

If it still returns 1008: pairing required, approve the pending device request:

openclaw devices approve --latest

(or openclaw devices list if you want to see it first)
Docs: https://docs.openclaw.ai/cli/devices

Then retry step (1).

#

If that still doesn’t work

Paste the output of:

openclaw --version
openclaw gateway status --deep
openclaw devices list --json

If devices list shows no pending request at all right after reproducing it, that’s likely a bug and we can turn it into a clean repro (and you should file it at https://github.com/openclaw/openclaw/issues with those outputs).

#

That “I had to wait for the system to kill a hung process / browser node permanently blocked / stop trying it burns tokens” text is just wrong (hallucinated). Ignore it.

gateway closed (1008): pairing required has a very specific meaning: the Gateway saw a new device identity and wants a one-time approval. This does not involve model calls (so it’s not “charging you for loops” — it’s failing before any AI work happens).

What to do on macOS (this fixes most “but it’s loopback!” cases):

Force IPv4 loopback (macOS often resolves localhost to ::1):

openclaw browser --url ws://127.0.0.1:18789 --browser-profile openclaw start

In another terminal, approve the pending device (do this right after reproducing; pending expires quickly):

openclaw devices approve --latest

(Or openclaw devices list if you want to see it first.)
Docs: https://docs.openclaw.ai/cli/devices

#

Retry step (1).

If devices approve --latest says there’s nothing pending, paste these (no huge dumps needed):

openclaw --version
openclaw gateway status --deep
openclaw devices list --json

If that confirms “no pending request was created” while you still get 1008, that’s when it’s likely a real bug and worth filing: https://github.com/openclaw/openclaw/issues (include the outputs above + the first 10 log lines around the 1008 from openclaw logs --follow).

full forge Feb 28, 2026, 5:35 PM

#

first thing you asked me to do just ran me around to another problem. Same stuff every time

🦞 OpenClaw 2026.2.26 (bc50708)
Type the command with confidence—nature will provide the stack trace if needed.

│
◇
Error: gateway url override requires explicit credentials
Fix: pass --token or --password (or gatewayToken in tools).
Config: /Users/benpittard/.openclaw/openclaw.json
MacBookPro:~ benpittard$

dense stormBOT Feb 28, 2026, 5:37 PM

#

That error is from the CLI, not the browser:

gateway url override requires explicit credentials

OpenClaw does this on purpose: the moment you pass --url, it refuses to “helpfully” reuse whatever token/password is in your config (so you don’t accidentally spray creds at some random URL). Docs spell it out: https://docs.openclaw.ai/cli/gateway#query-a-running-gateway

Fix (pick one)

Option A (recommended): don’t override the URL

openclaw browser --browser-profile openclaw start

Option B: keep --url, but pass creds explicitly
(Do NOT paste the token into Discord)

#

openclaw browser \
  --url ws://127.0.0.1:18789 \
  --token "$(openclaw config get gateway.auth.token)" \
  --browser-profile openclaw start

Then fix the original `1008: pairing required`

Right after you reproduce the 1008 once:

openclaw devices approve --latest

(or openclaw devices list first)

If devices approve says there’s nothing pending, paste only (no secrets):

#

openclaw gateway probe
openclaw devices list --json

full forge Feb 28, 2026, 5:38 PM

#

Option A result
🦞 OpenClaw 2026.2.26 (bc50708) — Your config is valid, your assumptions are not.

│
◇
Error: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/benpittard/.openclaw/openclaw.json
Bind: loopback
MacBookPro:~ benpittard$

dense stormBOT Feb 28, 2026, 5:39 PM

#

1006 abnormal closure (no close frame) is a different class of failure than the earlier 1008 pairing required.

1008 = gateway is alive and intentionally rejecting you (pairing/auth policy)
1006 = the WebSocket got cut without a proper close frame → most commonly the gateway process crashed/restarted, or you’re not actually talking to the gateway you think you are

Let’s pin down which in 2 commands:

Is the gateway actually up + probeable on that port?

openclaw gateway status --deep
openclaw gateway probe

Grab the gateway logs around the failure
Run this in one terminal:

#

openclaw logs --follow --local-time

Then in a second terminal, re-run:

openclaw browser --browser-profile openclaw start

Paste the first log lines that appear right when it disconnects (don’t paste any tokens).

If gateway status shows the service isn’t running, the fix is simply to start it (openclaw gateway start or openclaw gateway run) — but the outputs above will tell us immediately which path we’re on.

full forge Feb 28, 2026, 5:39 PM

#

🦞 OpenClaw 2026.2.26 (bc50708) — Ah, the fruit tree company! 🍎

│
◇
Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-02-28.log

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (Bad request.
Could not find service "ai.openclaw.gateway" in domain for user gui: 501)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway url override requires explicit credentials
Fix: pass --token or --password (or gatewayToken in tools).
Config: /Users/benpittard/.openclaw/openclaw.json

Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: /tmp/openclaw/openclaw-2026-02-28.log
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
MacBookPro:~ benpittard$ openclaw gateway probe

🦞 OpenClaw 2026.2.26 (bc50708) — Chat automation for people who peaked at IRC.

│
◇
Gateway Status
Reachable: no
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - connect failed: connect ECONNREFUSED 127.0.0.1:18789

MacBookPro:~ benpittard$

dense stormBOT Feb 28, 2026, 5:40 PM

#

gateway probe is the smoking gun here:

connect ECONNREFUSED 127.0.0.1:18789 = there is no Gateway listening
Service unit not found. Service not installed. Run: openclaw gateway install = your LaunchAgent isn’t installed/loaded, so the gateway never starts
In that state, openclaw browser start can’t possibly work (you’ll get 1006/connection failures because the WS server isn’t there)

Do this in order:

1) Start the gateway once in the foreground (sanity check)

openclaw gateway run

If it refuses and says you need gateway.mode=local, run:

openclaw config set gateway.mode "local"
openclaw gateway run

#

2) Install + start the LaunchAgent (so it stays running)

In a new terminal (or after stopping the foreground one):

openclaw gateway install --force
openclaw gateway start
openclaw gateway status --no-probe --deep
openclaw gateway probe

Once gateway probe says Reachable: yes, then retry:

openclaw browser --browser-profile openclaw start

3) Only if you’re back to `1008: pairing required`

Then approve the pending device:

#

openclaw devices approve --latest

If you want, paste the output of:

openclaw gateway probe

(after step 2) and I’ll tell you exactly what it thinks is reachable and why.

full forge Feb 28, 2026, 5:45 PM

#

terminal 2 output
The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
For more details, please visit https://support.apple.com/kb/HT208050.
MacBookPro:~ benpittard$ openclaw gateway install --force
openclaw gateway start
openclaw gateway status --no-probe --deep
openclaw gateway probe

🦞 OpenClaw 2026.2.26 (bc50708)
The only bot that stays out of your training set.

Installed LaunchAgent: /Users/benpittard/Library/LaunchAgents/ai.openclaw.gateway.plist
Logs: /Users/benpittard/.openclaw/logs/gateway.log
MacBookPro:~ benpittard$ openclaw gateway start
openclaw gateway status --no-probe --deep
openclaw gateway probe

🦞 OpenClaw 2026.2.26 (bc50708) — Because the right answer is usually a script.

openclaw gateway probe

#

terminal 1 output

#

🦞 OpenClaw 2026.2.26 (bc50708) — Works on Android. Crazy concept, we know.

Config overwrite: /Users/benpittard/.openclaw/openclaw.json (sha256 e4df4980b8b8c8b71f61d626f033278d0ccf0906d0b78470b7032f634a982c52 -> aea88699d1dd51e529702d3e1148759a5e3a8ab56c4f649810d894b44d5d834a, backup=/Users/benpittard/.openclaw/openclaw.json.bak)
Updated gateway.mode. Restart the gateway to apply.
MacBookPro:~ benpittard$ openclaw gateway run

🦞 OpenClaw 2026.2.26 (bc50708)
I read logs so you can keep pretending you don't have to.

12:41:38 Config overwrite: /Users/benpittard/.openclaw/openclaw.json (sha256 aea88699d1dd51e529702d3e1148759a5e3a8ab56c4f649810d894b44d5d834a -> cec1428e9955bbccee87a6f7b6b2b53862e6e1eb3aee97881857c181c682f78b, backup=/Users/benpittard/.openclaw/openclaw.json.bak)
17:41:38 [gateway] auth token was missing. Generated a new token and saved it to config (gateway.auth.token).
17:41:39 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /Users/benpittard/.openclaw/canvas)
17:41:39 [heartbeat] started
17:41:39 [health-monitor] started (interval: 300s, grace: 60s)
17:41:39 [gateway] agent model: anthropic/claude-opus-4-6
17:41:39 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 3910)
17:41:39 [gateway] log file: /tmp/openclaw/openclaw-2026-02-28.log
17:41:39 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)

dense stormBOT Feb 28, 2026, 5:46 PM

#

You’re past the “service not installed” part now — LaunchAgent is installed, good.

What’s almost certainly happening next (after a fresh rm -rf ~/.openclaw) is: the gateway daemon starts and immediately exits because gateway.mode isn’t set to "local" yet (the gateway refuses to run otherwise).

Run these one at a time and paste the output (no tokens/secrets):

openclaw config get gateway.mode

If that prints nothing / null, fix it:

openclaw config set gateway.mode "local"
openclaw gateway restart
openclaw gateway status --no-probe --deep

#

openclaw gateway probe

If gateway probe still says ECONNREFUSED, then the daemon is still failing to stay up — grab the last ~80 lines of the gateway log:

tail -n 80 ~/.openclaw/logs/gateway.log

(If there’s anything that looks like a token, redact it before pasting.)

Once gateway probe shows Reachable: yes, your original openclaw browser ... start will stop throwing the 1006/connection stuff, and we can deal with any remaining 1008 pairing (that’s the next, simpler step).

#

That output is actually progress: the Gateway is finally running and it also generated gateway.auth.token (so auth is now consistent):

listening on ws://127.0.0.1:18789
Browser control listening on http://127.0.0.1:18791/ (auth=token)

Now do this while openclaw gateway run is still running in terminal 1:

Terminal 2

openclaw gateway probe
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start

If you get “pairing required” at this point

Approve the latest pending device request, then retry the browser start:

#

openclaw devices approve --latest
openclaw browser --browser-profile openclaw start

After it works (optional: run as a daemon instead of foreground)

Stop the foreground gateway (Ctrl+C in terminal 1), then:

openclaw gateway start
openclaw gateway probe

Paste whatever openclaw browser ... start prints now (and if it errors, paste the first error line + the immediately preceding gateway log line from terminal 1).

full forge Feb 28, 2026, 5:51 PM

#

I don't know what I got.
After adding your gateway probe and browser status and start query
🦞 OpenClaw 2026.2.26 (bc50708)
I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

│
penclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
◇
Gateway Status
Reachable: yes
Probe budget: 3000ms

Discovery (this machine)
Found 1 gateway(s) via Bonjour (local.)

Targets
Local loopback ws://127.0.0.1:18789
Connect: ok (44ms) · RPC: ok
Gateway: MacBookPro.home (192.168.254.205) · macos 26.3 · app unknown
Wide-area discovery: unknown

MacBookPro:~ benpittard$

dense stormBOT Feb 28, 2026, 5:51 PM

#

What you pasted there is only the output of openclaw gateway probe — and that part is good:

Reachable: yes
RPC: ok
It found 1 gateway on loopback

But I still don’t see the output of these two commands:

openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start

Can you run them one at a time (don’t paste as a block), and paste what each prints?

Terminal 2

#

openclaw browser --browser-profile openclaw status

then

openclaw browser --browser-profile openclaw start

Also tell me one yes/no thing: did a new “OpenClaw” browser window/profile actually pop up when you ran start?

If start immediately errors with 1008 pairing required, the fix is:

openclaw devices approve --latest

…and then retry openclaw browser … start.

full forge Feb 28, 2026, 5:53 PM

#

🦞 OpenClaw 2026.2.26 (bc50708)
I keep secrets like a vault... unless you print them in debug logs again.

│
◇
profile: openclaw
enabled: true
running: false
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: chrome
detectedPath: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
profileColor: #FF4500
MacBookPro:~ benpittard$
🦞 OpenClaw 2026.2.26 (bc50708)
If it works, it's automation; if it breaks, it's a "learning opportunity."

│
◇
Error: gateway timeout after 15000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/benpittard/.openclaw/openclaw.json
Bind: loopback
MacBookPro:~ benpittard$

#

Here got the second one

#

🦞 OpenClaw 2026.2.26 (bc50708) — curl for conversations.

│
◇
│
◇
🦞 browser [openclaw] running: true
MacBookPro:~ benpittard$

dense stormBOT Feb 28, 2026, 5:54 PM

#

You’re past pairing now. This error:

Error: gateway timeout after 15000ms

usually means: the Gateway accepted the RPC, but it’s waiting for Chrome to come up on CDP port 18800 and that never becomes “ready” (so the CLI gives up after 15s).

Two most common causes: port 18800 already in use or Chrome failed to launch (you’ll see the real reason in the gateway logs).

1) Check if something is already listening on 18800

Run:

lsof -nP -iTCP:18800 -sTCP:LISTEN

If that shows a process, that’s almost certainly why browser start hangs.

#

2) Grab the gateway-side error (this is the important part)

Right after running openclaw browser --browser-profile openclaw start, paste the relevant lines from the gateway log:

If you’re still running openclaw gateway run in Terminal 1, copy the lines that appear in Terminal 1 right when you run browser start.

Or tail the file log it mentioned earlier:

tail -n 120 /tmp/openclaw/openclaw-2026-02-28.log

(redact anything secret-looking if it appears, but usually it won’t print the token)

3) Quick workaround if 18800 is busy: change the CDP port

openclaw config set browser.profiles.openclaw.cdpPort 18810

#

openclaw gateway restart
openclaw browser --browser-profile openclaw start --timeout 60000

Also: when you run start, do you see an orange-tinted “OpenClaw” Chrome window appear at all? (yes/no) That tells us immediately whether Chrome is launching vs failing before launch.

#

Nice — that output means the hard part is done:

browser [openclaw] running: true

So Chrome did launch and the Gateway can talk to it on CDP.

Now verify it’s actually controllable:

openclaw browser --browser-profile openclaw tabs
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshot

If tabs shows targets and snapshot returns a page dump, you’re fully unblocked.

Two quick notes so you don’t get whiplash again:

#

That earlier gateway timeout after 15000ms was the CLI waiting for the browser to come up; now that it’s running: true, you’re past it. If it ever happens again, you can re-run with a bigger timeout: openclaw browser --timeout 60000 … start.
Make sure you’re using --browser-profile openclaw (managed browser). The chrome profile is the extension relay path and needs a tab attached.

Tell me what tabs prints (just counts/summary is fine). If it looks good, I’ll give you the exact next step to use it from the agent/UI.

full forge Feb 28, 2026, 5:57 PM

#

No tabs (browser closed or no targets).
MacBookPro:~ benpittard$

dense stormBOT Feb 28, 2026, 5:57 PM

#

That “No tabs (browser closed or no targets)” output is consistent with Chrome being up but started with no startup window/tab (so there’s nothing for tabs to list yet).

Try creating the first tab explicitly:

openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw tabs
openclaw browser --browser-profile openclaw snapshot

If open fails because the profile isn’t actually running anymore, rerun:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

#

If you still get “no targets” after running open, paste:

openclaw browser --browser-profile openclaw status
the last ~30 lines in the gateway log around the attempt (tail -n 60 /tmp/openclaw/openclaw-2026-02-28.log)

That’ll show whether CDP is reachable but Target.* calls are failing, vs Chrome exiting immediately.

full forge Feb 28, 2026, 5:59 PM

#

looks good
🦞 OpenClaw 2026.2.26 (bc50708) — OpenAI-compatible, not OpenAI-dependent.

│
◇
opened: https://example.com/
id: FA20BB1DF7CAC4ABF829EC5C606AE1E4
MacBookPro:~ benpittard$ openclaw browser --browser-profile openclaw tabs

🦞 OpenClaw 2026.2.26 (bc50708)
I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

│
◇

Example Domain
https://example.com/
id: FA20BB1DF7CAC4ABF829EC5C606AE1E4
MacBookPro:~ benpittard$ openclaw browser --browser-profile openclaw snapshot

🦞 OpenClaw 2026.2.26 (bc50708)
If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

│
◇

generic [ref=e2]:
- heading "Example Domain" [level=1] [ref=e3]
- paragraph [ref=e4]: This domain is for use in documentation examples without needing permission. Avoid use in operations.
- paragraph [ref=e5]:
  - link "Learn more" [ref=e6] [cursor=pointer]:
    - /url: https://iana.org/domains/example
      MacBookPro:~ benpittard$

dense stormBOT Feb 28, 2026, 5:59 PM

#

You’re fully working now: open → tabs → snapshot all succeeded, which means:

Gateway is running
Browser control server is up
Chrome launched on CDP (18800)
Playwright/CDP is returning refs correctly

So the original “loopback pairing required” spiral was really a combo of:

Gateway service not installed / not running after you nuked ~/.openclaw
gateway.mode missing until you set it
Browser needed a tab created before tabs showed anything

Next step depends on what you want:

If you want the agent (chat) to use the managed browser by default

Set:

#

openclaw config set browser.defaultProfile "openclaw"
openclaw gateway restart

Docs: https://docs.openclaw.ai/tools/browser

If you want to keep it stable (daemon, not foreground)

Make sure the LaunchAgent is running and reachable:

openclaw gateway start
openclaw gateway probe

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

full forge Feb 28, 2026, 6:02 PM

#

Thank you.
I still am having issues when my OpenCrawl tries to read its email and perform tasks. The chrome extension is not working

dense stormBOT Feb 28, 2026, 6:02 PM

#

If the managed browser profile (--browser-profile openclaw) is working (it is), you don’t need the Chrome extension to read email via the web UI — you can just open Gmail in the OpenClaw browser and sign in there:

openclaw browser --browser-profile openclaw open https://mail.google.com

The Chrome extension is only for the other mode: controlling your existing “real” Chrome tabs/cookies (profile chrome). That mode only works when a tab is explicitly attached.

If you want the extension relay working

Install + load the extension:

openclaw browser extension install
openclaw browser extension path

Then in Chrome: chrome://extensions → enable Developer mode → Load unpacked → pick the printed folder.

Open a tab (e.g. Gmail), click the OpenClaw Browser Relay extension icon on that tab, make sure the badge shows it’s attached/ON.

#

Test from CLI:

openclaw browser --browser-profile chrome status
openclaw browser --browser-profile chrome tabs

If tabs is empty or it says no tab is connected, it’s almost always step (2) (tab not attached).

If you paste the output of the two chrome status / chrome tabs commands and the exact error OpenCrawl shows when it “tries to read email”, I can tell you which mode it’s using and what to change. Docs for the extension path: https://docs.openclaw.ai/tools/chrome-extension

full forge Feb 28, 2026, 6:04 PM

#

So I just type openclaw browser --browser-profile openclaw open https://mail.google.com into my terminal to allow it to go direct to emails?

dense stormBOT Feb 28, 2026, 6:04 PM

#

Yes — on the same machine where your Gateway is running, you can do:

openclaw browser --browser-profile openclaw open https://mail.google.com

A couple important clarifications:

This opens Gmail inside the OpenClaw-managed browser profile (“openclaw”), which the agent can control.
You’ll still need to log into Gmail in that new window (and complete any 2FA) once. After that, the agent can navigate/read/act in that session.

If you want the “safe” sequence:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://mail.google.com

#Mac Bug