Can't get my claw to browse the web | Friends of the Crustacean 🦞🤝 | Page 1

young token Feb 15, 2026, 9:52 PM

#

Can't get my claw to browse the web I tried solving it but we did like 10 tiems and he said to go discord and ask here

[openclaw] Still the same error 😩

This is either a bug or some weird config state. The gateway might be regenerating a new auth token on restart.

Honestly at this point I'd say:

Option A: Ask in the OpenClaw Discord with a screenshot - this token mismatch loop seems like a known issue

gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Error: gateway closed (1008): unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback

strange condorBOT Feb 15, 2026, 9:52 PM

#

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

cerulean lintelBOT Feb 15, 2026, 9:55 PM

#

That error isn’t “web browsing” yet — it’s your CLI/UI failing to authenticate to the Gateway WebSocket.

In OpenClaw there are two relevant token settings:

gateway.auth.token = the token the Gateway server expects
gateway.remote.token = the token your client/CLI uses when it connects in remote mode

If those don’t match, you get exactly: unauthorized: gateway token mismatch.

1) First: please run these (and paste the output)

Don’t paste any tokens — these commands won’t print them.

openclaw --version
openclaw gateway status
openclaw status --all

#

openclaw config get gateway.mode
openclaw config get gateway.remote.url

openclaw gateway status is especially important because it often shows Config (cli) vs Config (service) — if you’ve been using sudo sometimes, you can end up with the service reading a different config file than the CLI.

2) Quick fix (most common)

On the machine where you run the CLI:

openclaw config get gateway.auth.token
openclaw config set gateway.remote.token "<PASTE_THE_SAME_VALUE_AS_gateway.auth.token>"

Then retry whatever was failing.

#

Notes:

Do not paste the token into Discord.
If your gateway.auth.token is empty/missing, generate one on the gateway host:
```
openclaw doctor --generate-gateway-token
```

3) If you did not mean to be in remote mode

If you’re running everything on the same box and don’t need remote mode:

openclaw config set gateway.mode "local"
openclaw config unset gateway.remote.url
openclaw config unset gateway.remote.token
openclaw gateway restart

#

Docs that match this exact situation

Control UI unauthorized loop: https://docs.openclaw.ai/help/faq#the-control-ui-says-unauthorized-or-keeps-reconnecting-what-now
Remote mode/token semantics: https://docs.openclaw.ai/gateway/remote

Paste the outputs from step (1) and I’ll tell you which of the two paths above is the right one for your setup.

young token Feb 15, 2026, 10:04 PM

#

I can't drop pictures here

#

gents
┌────────────┬───────────┬──────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap │ Sessions │ Active │ Store │
├────────────┼───────────┼──────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ main │ OK │ 0 │ unknown │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴───────────┴──────────┴──────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback

✓ Config: /root/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 2865 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
error: Error: spawn tailscale ENOENT
✓ Skills: 4 eligible · 0 missing · /root/.openclaw/workspace
! Channel issues skipped (gateway unreachable)

Gateway health:
connect failed: unauthorized: gateway token mismatch (provide gateway auth token)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

🦞 OpenClaw 2026.2.12 (f9e444d) — I read logs so you can keep pretending you don't have to.

local
root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~#

@cerulean lintel

cerulean lintelBOT Feb 15, 2026, 10:05 PM

#

No worries — you don’t need screenshots for this.

Can you just paste the command output as text here (wrap it in a code block)? These are safe to share (tokens get redacted in the report):

openclaw --version
openclaw status --all
openclaw gateway status

In Discord, format it like:

<paste output here>

If openclaw status --all is too long for one message, paste it to something like a GitHub Gist / Pastebin and drop the link (and don’t include any raw token values if you happen to see them anywhere).

#

Your paste actually tells us a lot:

The Gateway process is running (pid 2865 … 127.0.0.1:18789)
But the CLI can’t talk to it: unauthorized: gateway token mismatch

So this is almost always: gateway.remote.token (what the CLI sends) ≠ gateway.auth.token (what the Gateway expects), or your Gateway service is reading a different config/env than the CLI.

Fix (no screenshots needed, don’t paste tokens here)

Run these on the VPS:

openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw config get gateway.remote.token

#

Now do one of these:

Option A (recommended): make the CLI token match the Gateway token

Copy the value you got from gateway.auth.token and set it as gateway.remote.token:

openclaw config set gateway.remote.token "<PASTE gateway.auth.token HERE>"
openclaw gateway restart

Then test:

openclaw gateway probe
openclaw status

#

Option B: if `gateway.auth.token` is empty/missing

Generate one, then set remote token to match:

openclaw doctor --generate-gateway-token
openclaw config get gateway.auth.token   # copy it (don’t post it)
openclaw config set gateway.remote.token "<PASTE IT HERE>"
openclaw gateway restart

If it still says token mismatch after that

Then your service is likely using a different config file than the CLI (super common when mixing sudo / different users).

Paste the output of this (it’s safe):

#

openclaw gateway status

Specifically we’re looking for a line like “Config (cli)” vs “Config (service)” being different.

young token Feb 15, 2026, 10:10 PM

#

gateway.auth.token where do i get this from

cerulean lintelBOT Feb 15, 2026, 10:10 PM

#

You fetch it on the machine that runs the Gateway (your VPS), as the same user that runs the gateway service (in your paste that looks like root, config at /root/.openclaw/openclaw.json).

Run:

openclaw config get gateway.auth.token

If it prints a token: copy it locally (don’t paste it in Discord), then set your client/CLI to use the same value (usually gateway.remote.token).
If it prints nothing / null: generate one:

openclaw doctor --generate-gateway-token
openclaw config get gateway.auth.token

Docs: https://docs.openclaw.ai/help/faq#how-do-i-authenticate-the-dashboard-token-on-localhost-vs-remote

young token Feb 15, 2026, 10:12 PM

#

ok i did it and restarted the the gateway

cerulean lintelBOT Feb 15, 2026, 10:13 PM

#

Cool — next step is just to confirm the auth loop is actually gone.

Run on the gateway host:

openclaw gateway probe
openclaw status

If those now work (no “unauthorized”), you’re unblocked.
If you still see token mismatch / unauthorized, paste the output of:

openclaw gateway status

(That will show whether Config (cli) and Config (service) are pointing at the same place / user, which is the usual remaining culprit.)

#

If you’re trying to use the Control UI from a browser too: open http://127.0.0.1:18789/ (or your tunnel/Tailscale URL) and paste the same gateway.auth.token into the Control UI settings.

young token Feb 15, 2026, 10:14 PM

#

Ok this error now:

oot@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# openclaw browser start --browser-profile openclaw

🦞 OpenClaw 2026.2.12 (f9e444d) — Ah, the fruit tree company! 🍎

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Error: gateway closed (1008): unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback
root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~#

cerulean lintelBOT Feb 15, 2026, 10:15 PM

#

That means the Gateway is expecting gateway.auth.token, but your CLI is sending a different token (it uses gateway.remote.token as the “client token”).

So even though you set gateway.auth.token, you still need to set the matching remote token (don’t paste the token in Discord):

# 1) Show the gateway’s expected token (copy it locally)
openclaw config get gateway.auth.token

# 2) Set the CLI/client token to the same value (paste the one you copied)
openclaw config set gateway.remote.token "<PASTE_THE_SAME_TOKEN_HERE>"

Now retry (no restart required for this step, since it’s the client token):

openclaw gateway probe

#

openclaw browser start --browser-profile openclaw

If it still says mismatch after that, paste only this (it’s safe) because it will reveal if your gateway service is reading a different config than your CLI:

openclaw gateway status

young token Feb 15, 2026, 10:17 PM

#

OpenClaw 2026.2.12 (f9e444d) — Greetings, Professor Falken

│
◇
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: unauthorized: gateway token mismatch (provide gateway auth token)

root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~#

cerulean lintelBOT Feb 15, 2026, 10:20 PM

#

That means your Gateway is still expecting a different token than the CLI is sending.

On Linux/VPS this is usually because the Gateway token is coming from an env override (like /root/.openclaw/.env or the systemd unit), which overrides what you put in openclaw.json.

1) First check (don’t paste tokens here)

Run these and just tell me “same” or “different”:

openclaw config get gateway.auth.token
openclaw config get gateway.remote.token

They must be identical.

2) Check if an env override exists (safe: prints no token)

#

if [ -f /root/.openclaw/.env ] && grep -q '^OPENCLAW_GATEWAY_TOKEN=' /root/.openclaw/.env; then
  echo "FOUND: OPENCLAW_GATEWAY_TOKEN in /root/.openclaw/.env (this overrides config)"
else
  echo "OK: no OPENCLAW_GATEWAY_TOKEN in /root/.openclaw/.env"
fi

If it says FOUND, open /root/.openclaw/.env and either:

delete the OPENCLAW_GATEWAY_TOKEN=... line, or
set it to the same token as gateway.auth.token.

Then:

openclaw gateway restart

#

openclaw gateway probe

3) If no `.env` override, paste this (safe)

openclaw gateway status --no-probe --deep

That will show which service/unit is actually running the gateway, so we can check if the systemd service has a baked-in token that’s overriding your config.

young token Feb 15, 2026, 10:22 PM

#

They must be identical. - they are

cerulean lintelBOT Feb 15, 2026, 10:22 PM

#

If gateway.auth.token and gateway.remote.token in the config are truly the same, but you still get token mismatch, then either:

the running Gateway process is using a different token (env/service override), or
your CLI is sending a different token (env override in your shell), or
you’re talking to a different gateway instance/profile than the one you edited.

Let’s narrow it down without ever posting tokens.

A) Paste this (safe)

This shows which config the service is using (and avoids the WS probe):

openclaw gateway status --no-probe --deep

B) Check for a token env var override (don’t paste the token)

Just paste the YES/NO outputs:

#

test -n "$OPENCLAW_GATEWAY_TOKEN" && echo "OPENCLAW_GATEWAY_TOKEN=SET" || echo "OPENCLAW_GATEWAY_TOKEN=NOT_SET"
test -f /root/.openclaw/.env && grep -q '^OPENCLAW_GATEWAY_TOKEN=' /root/.openclaw/.env && echo "/root/.openclaw/.env has token" || echo "/root/.openclaw/.env no token"

C) Quick sanity: make sure only one thing is listening on 18789 (safe)

ss -lptn | grep ':18789' || true

Once you paste A + B + C, I can tell you exactly where the “other” token is coming from (most often it’s /root/.openclaw/.env or the systemd unit environment).

young token Feb 15, 2026, 10:24 PM

#

< OpenClaw 2026.2.12 (f9e444d) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-15.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
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: running (pid 21232, state active, sub running, last exit 0, reason 0)
Port 18789 is already in use.

pid 2865 openclaw: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):
openclaw.service (system, unit: /etc/systemd/system/openclaw.service)
Cleanup hint: systemctl --user disable --now openclaw-gateway.service
Cleanup hint: rm ~/.config/systemd/user/openclaw-gateway.service

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# >

cerulean lintelBOT Feb 15, 2026, 10:25 PM

#

Your gateway status output shows the real problem now: you have multiple gateways running on the same machine, and the one that’s actually listening on 18789 is PID 2865.

That’s why you still get “token mismatch” even though your config tokens match — your CLI is connecting to the other gateway instance.

Fix: leave only ONE gateway running

Stop/disable the system service it detected (the extra one):

systemctl disable --now openclaw.service 2>/dev/null || true
systemctl stop openclaw.service 2>/dev/null || true

Now stop the remaining listener on 18789 (should be gone after step 1, but check):

ss -lptn | grep ':18789' || echo "nothing listening on 18789"

#

If it still shows pid 2865 listening, kill just that stray process:

kill 2865

Restart the gateway cleanly (the one managed by OpenClaw):

openclaw gateway restart

Confirm there is exactly one listener now:

ss -lptn | grep ':18789'
openclaw gateway probe

Once openclaw gateway probe is reachable, openclaw browser start --browser-profile openclaw will stop failing on auth and we can move on to any actual browser issues (Chrome/Chromium install, headless deps, etc.).

young token Feb 15, 2026, 10:27 PM

#

[ OpenClaw 2026.2.12 (f9e444d) — I can run local, remote, or purely on vibes—results may vary with DNS.

│
◇
Gateway Status
Reachable: yes
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: ok (109ms) · RPC: ok
Gateway: openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01 (104.131.174.200) · linux 6.8.0-100-generic · app unknown
Wide-area discovery: unknown

root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# ]

cerulean lintelBOT Feb 15, 2026, 10:27 PM

#

Nice — that’s the green light. Connect: ok · RPC: ok means the token mismatch loop is fixed and you’re talking to the right gateway now.

Now retry the browser start:

openclaw browser start --browser-profile openclaw

If it errors, paste the new error text. The next most common issue on Ubuntu VPS is simply “no Chrome/Chromium installed” or missing headless deps, and the error message will tell us which.

(Also: if this fixed it, please mark the solution message in the thread so Answer Overflow indexes it.)

young token Feb 15, 2026, 10:27 PM

#

estarted systemd service: openclaw-gateway.service
root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# ss -lptn | grep ':18789'
openclaw gateway probe

🦞 OpenClaw 2026.2.12 (f9e444d) — I can run local, remote, or purely on vibes—results may vary with DNS.

│
◇
Gateway Status
Reachable: yes
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: ok (109ms) · RPC: ok
Gateway: openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01 (104.131.174.200) · linux 6.8.0-100-generic · app unknown
Wide-area discovery: unknown

root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# openclaw browser start --browser-profile openclaw

🦞 OpenClaw 2026.2.12 (f9e444d) — I run on caffeine, JSON5, and the audacity of "it worked on my machine."

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Error: gateway closed (1008): unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback
root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~#

cerulean lintelBOT Feb 15, 2026, 10:29 PM

#

What you’re seeing ( gateway probe works but browser start fails with token mismatch ) almost always means:

gateway probe is successfully authenticating to the local loopback target using gateway.auth.token (or env), BUT
openclaw browser start is authenticating as a “remote client” using gateway.remote.token, and that one doesn’t match what the Gateway expects.

This happens when you accidentally left the CLI in remote mode (or set gateway.remote.*).

Check this (safe to paste)

openclaw config get gateway.mode
openclaw config get gateway.remote.url

If `gateway.mode` is `"remote"` (or `gateway.remote.url` is set) → fix

On the gateway host (your VPS), set it back to local-mode and clear the remote target:

#

openclaw config set gateway.mode "local"
openclaw config unset gateway.remote.url
openclaw config unset gateway.remote.token
openclaw gateway restart

Then try again:

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

If gateway.mode already says "local", paste the two outputs above anyway — then we’ll check what’s still forcing the CLI down the “remote token” path.

young token Feb 15, 2026, 10:33 PM

#

root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# openclaw config get gateway.mode
openclaw config get gateway.remote.url

🦞 OpenClaw 2026.2.12 (f9e444d) — I read logs so you can keep pretending you don't have to.

local

#

root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# openclaw config get gateway.mode
openclaw config get gateway.remote.url

🦞 OpenClaw 2026.2.12 (f9e444d) — I read logs so you can keep pretending you don't have to.

local

🦞 OpenClaw 2026.2.12 (f9e444d) — Automation with claws: minimal fuss, maximal pinch.

Config path not found: gateway.remote.url
root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~#

cerulean lintelBOT Feb 15, 2026, 10:34 PM

#

gateway probe is hitting the local loopback target and authenticating fine.

But openclaw browser start is still behaving like a remote-client call, which (in this version) uses gateway.remote.* auth if a gateway.remote.url is set — and that’s how you can get “probe ok” but “browser start token mismatch”.

On the gateway host (your VPS), run this and paste the output (it’s not secret):

openclaw config get gateway.remote.url

If that prints anything (even ws://127.0.0.1:18789), clear the remote settings on the server (remote settings belong on your laptop/client, not on the gateway itself):

openclaw config unset gateway.remote.url
openclaw config unset gateway.remote.token
openclaw config unset gateway.remote.password

#

openclaw gateway restart

Then retry:

openclaw browser start --browser-profile openclaw

If gateway.remote.url was already empty, reply with the output of:

openclaw config get gateway.auth.mode
openclaw gateway status --no-probe

#

gateway probe succeeding but openclaw browser start still getting token mismatch means the browser command is somehow sending a different token than probe.

Fastest way to prove/fix that: pass the token explicitly to the browser command.

Run this on the VPS (don’t paste the token):

T="$(openclaw config get gateway.auth.token)"
openclaw browser --browser-profile openclaw start --token "$T"

(Also note the syntax: openclaw browser --browser-profile openclaw start — profile flag before the subcommand.)

If that works

Then your config is fine; the issue was token resolution for that command. You can keep using --token "$T" (or export OPENCLAW_GATEWAY_TOKEN in the shell you’re running CLI from).

If it still says token mismatch

#

Then the Gateway service is using a different token source than you think (usually ~/.openclaw/.env).

Check (safe output, no token printed):

test -f ~/.openclaw/.env && grep -q '^OPENCLAW_GATEWAY_TOKEN=' ~/.openclaw/.env && echo ".env has token override" || echo "no token override in .env"

Tell me which of those two cases you get, and whether the explicit --token "$T" run worked.

young token Feb 15, 2026, 10:39 PM

#

root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~# openclaw config get gateway.remote.url

🦞 OpenClaw 2026.2.12 (f9e444d) — Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

Config path not found: gateway.remote.url
root@openclaw-ubuntu-s-2vcpu-4gb-120gb-intel-nyc3-01:~#

cerulean lintelBOT Feb 15, 2026, 10:42 PM

#

Good: gateway.remote.url is not set, and gateway.mode is local — so remote-mode config isn’t the cause.

Next, let’s catch what’s overriding the token for the browser command.

1) Check if your shell has an env token override (safe to paste)

env | grep -E 'OPENCLAW_GATEWAY_TOKEN|CLAWDBOT_GATEWAY_TOKEN' || echo "no gateway token env vars set"

2) Confirm only one gateway is listening (paste output)

ss -lptn | grep ':18789' || echo "nothing listening on 18789"

3) Force the browser command to use the gateway token explicitly

(Do not paste the token here — just copy/paste it locally from openclaw config get gateway.auth.token)

#Can't get my claw to browse the web

1) First: please run these (and paste the output)

2) Quick fix (most common)

3) If you did not mean to be in remote mode

Docs that match this exact situation

Fix (no screenshots needed, don’t paste tokens here)

Option A (recommended): make the CLI token match the Gateway token

Option B: if gateway.auth.token is empty/missing

If it still says token mismatch after that

1) First check (don’t paste tokens here)

2) Check if an env override exists (safe: prints no token)

3) If no .env override, paste this (safe)

A) Paste this (safe)

B) Check for a token env var override (don’t paste the token)

C) Quick sanity: make sure only one thing is listening on 18789 (safe)

Fix: leave only ONE gateway running

Check this (safe to paste)

If gateway.mode is "remote" (or gateway.remote.url is set) → fix

If that works

If it still says token mismatch

1) Check if your shell has an env token override (safe to paste)

2) Confirm only one gateway is listening (paste output)

3) Force the browser command to use the gateway token explicitly

Option B: if `gateway.auth.token` is empty/missing

3) If no `.env` override, paste this (safe)

If `gateway.mode` is `"remote"` (or `gateway.remote.url` is set) → fix