MacOS x Docker issue: Cannot connect to OpenClaw dashboard.

[lucid cairn]

I have ran the docker-setup.sh and completed the onboarding wizard.

When connecting to the gateway Im constantly met with disconnected (1008): pairing required

The issue I seem to see is that OpenClaw is seeing a cloudflare IP (162.159.133.xxx)

1. Configuration changes tried:

• Changed bind setting from loopback to lan in both .env and config file
• Verified config with: docker compose exec openclaw-gateway cat /home/node/.openclaw/openclaw.json
• Config shows correct "bind": "lan" and "auth": {"mode": "token"}

2. Pairing attempts:

• Added wildcard pairing: {"*": {"approved": true}} to /home/node/.openclaw/devices/paired.json
• Added specific Cloudflare IP: {"162.159.133.234": {"approved": true}}
  Neither worked - pairing requirement persists

3. Network troubleshooting:

• Disabled macOS "Limit IP address tracking" (System Settings → Network → Ethernet → Details)
• Disabled Chrome "Use secure DNS" (Chrome Settings → Privacy and security)
• Disabled Safari IP hiding features
• Confirmed no VPN or Cloudflare WARP installed
• Confirmed no proxy settings: scutil --proxy shows nothing
• DNS is local router (192.168.xxx.xxx), not Cloudflare DNS

4. Connection method variations:

• Tried http://127.0.0.1:18789 - Cloudflare IP appears in logs
• Tried http://localhost:18789 - Cloudflare IP appears in logs
• Tried http://[::1]:18789 (IPv6) - Cloudflare IP appears in logs

5. System checks:

• Routing table normal: netstat -rn shows standard localhost routing
  /etc/hosts file normal (127.0.0.1 → localhost)

Additional context:

• Gateway HTTP server works fine: curl -I http://127.0.0.1:18789 returns 200
• Dashboard UI loads correctly, only websocket connection fails pairing
• CLI commands also fail with same error: docker compose run --rm openclaw-cli devices list → gateway closed (1006 abnormal closure)

Thank you in advance for any assistance that may be able to help in setting this up in docker.
Slats

[placid ferry]

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

[lucid cairn]

openclaw version - 2026.2.6-3
MacOS - Tahoe 26.2

[half epoch]

On docker-setup.sh, disconnected (1008): pairing required is expected the first time — because from the gateway container’s point of view your browser is a “remote device”, so it needs a one-time approval.

A couple key points based on what you tried:

1. Editing ~/.openclaw/devices/paired.json won’t help (that’s legacy). The supported flow is:

• openclaw devices list
• openclaw devices approve <requestId>

2. In Docker, run the pairing approval with an explicit URL+token (don’t paste the token into Discord, just run it locally):

docker compose run --rm openclaw-cli devices list \
--url ws://openclaw-gateway:18789 \
--token "$OPENCLAW_GATEWAY_TOKEN"

docker compose run --rm openclaw-cli devices approve <requestId> \

--url ws://openclaw-gateway:18789 \
--token "$OPENCLAW_GATEWAY_TOKEN"

Then reload the dashboard tab.

3. If openclaw-cli devices list still dies with 1006/1008, the quickest “bootstrap” workaround is to run the command from inside the gateway container (so it’s truly loopback/local):

docker compose exec openclaw-gateway openclaw devices list
docker compose exec openclaw-gateway openclaw devices approve <requestId>

(If openclaw isn’t on PATH in that container, run docker compose exec openclaw-gateway sh and check what the entrypoint/CLI command is; we can adapt.)

4. The “Cloudflare IP” thing is weird, but pairing is by device ID, not by IP — so once the device is approved it should stop blocking even if the source IP looks odd.

If you paste two things, we can pinpoint what’s happening (both are safe):

docker compose run --rm openclaw-cli status --all

- and the pairing/auth lines:
```bash
docker compose logs openclaw-gateway --tail 200 | grep -iE "pairing|required|1008|auth|device"

Also: don’t paste the full dashboard URL (it contains the token).

[lucid cairn]

docker compose run --rm openclaw-cli status --all
Status output shows:
Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (connect ECONNREFUSED 127.0.0.1:18789)

docker compose logs openclaw-gateway --tail 200 | grep -iE "pairing|required|1008|auth|device"
remote=162.159.133.234 ... origin=http://127.0.0.1:18789 ... code=1008 reason=pairing required (browser)
remote=172.19.0.4 ... host=openclaw-gateway:18789 ... code=1008 reason=pairing required (Docker internal)
remote=127.0.0.1 ... host=127.0.0.1:18789 ... code=1008 reason=pairing required (true localhost)

[half epoch]

That status --all output is the smoking gun: inside the openclaw-cli container, ws://127.0.0.1:18789 is “the CLI container itself”, not the gateway container → hence ECONNREFUSED.

1) Re-run status pointing at the gateway service name

docker compose run --rm openclaw-cli status --all \
--url ws://openclaw-gateway:18789 \
--token "$OPENCLAW_GATEWAY_TOKEN"

(You’ll want to use that --url ws://openclaw-gateway:18789 pattern for any CLI RPC from the CLI container.)

2) Approve the pending Control UI device by reading pending.json directly

Since devices list is getting blocked by pairing, bypass it and grab the requestId(s) from the file store:

docker compose exec openclaw-gateway cat /home/node/.openclaw/devices/pending.json

Then approve from inside the gateway container (so there’s no “which URL am I hitting?” confusion):

docker compose exec openclaw-gateway openclaw devices approve <requestId> \
--url ws://127.0.0.1:18789 \
--token "$OPENCLAW_GATEWAY_TOKEN"

Reload the dashboard tab after that.

3) Important note about your earlier paired.json edit

~/.openclaw/devices/paired.json isn’t keyed by IP, so entries like "*" or "162.159..." won’t match anything. Pairing is by device identity, and approvals are done via requestId (what’s stored in pending.json).

---

If step (2) still returns 1008 pairing required even from inside openclaw-gateway, paste:

docker compose exec openclaw-gateway openclaw devices approve <requestId> --json 2>&1

(redact tokens if any show up) — because that would imply the gateway is treating even loopback-in-container as “remote”, which shouldn’t happen and we’ll chase that next.

[lucid cairn]

I will try now:

When running:

--url ws://openclaw-gateway:18789 \
--token "$OPENCLAW_GATEWAY_TOKEN"```

I get this output - `error: unknown option '--url'`

[half epoch]

Yep — openclaw status doesn’t support --url (it’s a “local machine” diagnostic), so that flag will always be rejected there.

In Docker, do it like this instead:

Option A (simplest): run the commands inside the gateway container

Then 127.0.0.1:18789 is actually the gateway, and you avoid the Docker bridge IP issue entirely.

docker compose exec openclaw-gateway openclaw status --all
docker compose exec openclaw-gateway openclaw devices list
docker compose exec openclaw-gateway openclaw devices approve <requestId>

Option B: use a subcommand that does accept --url

For example devices and gateway health accept --url (but status doesn’t):

docker compose run --rm openclaw-cli devices list \
--url ws://openclaw-gateway:18789 \
--token "$OPENCLAW_GATEWAY_TOKEN"

(If you try Option B and it still complains about --url, then the openclaw binary inside your openclaw-cli container is not the version you think it is — in that case Option A is the reliable path.)

If devices list is still blocked, grab the pending requestIds directly:

docker compose exec openclaw-gateway cat /home/node/.openclaw/devices/pending.json

…and paste just the requestId values here (no tokens), and I’ll tell you exactly which one to approve.

[lucid cairn]

Ok that worked using the following:

Checking for current requests:
docker compose exec openclaw-gateway cat /home/node/.openclaw/devices/pending.json

Then accepting the new token:
docker compose exec openclaw-gateway openclaw devices approve "$OPENCLAW_GATEWAY_TOKEN"

Refreshing the page cleared the error - THANK YOU

[half epoch]

Nice — glad it’s unblocked.

One tiny correction for future-you: openclaw devices approve is supposed to take the requestId from pending.json (not the gateway token). So the “canonical” flow is:

docker compose exec openclaw-gateway cat /home/node/.openclaw/devices/pending.json
docker compose exec openclaw-gateway openclaw devices approve <requestId>

…but as long as you’re paired and the dashboard reconnects, you’re good.

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