Gateway token mismatch error | Friends of the Crustacean 🦞🤝 | Page 1

tender egret Feb 13, 2026, 1:00 AM

#

I'm not sure if my openclaw changed settings on it's own, if I changed something and it later killed it, or what is going on. It suddenly stopped responding, encountered gateway problems and my tinkering hasn't seemed to have helped. Hopefully you can help Krill.

Upon calling 'openclaw gateway status' I receive: gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)

I have tried restarting and confirming the token is correct. Can you help me from here?

knotty micaBOT Feb 13, 2026, 1:05 AM

#

tender egret I'm not sure if my openclaw changed settings on it's own, if I changed something...

That error means: the Gateway is requiring token X, but your CLI is sending token Y.

In OpenClaw there are two relevant places:

gateway.auth.token → what the Gateway service expects
gateway.remote.token → what the CLI uses in remote mode (and anything connecting “as a client”)

If gateway.mode is remote, then gateway.remote.token must match the Gateway’s gateway.auth.token (or OPENCLAW_GATEWAY_TOKEN if you’re using env vars).

1) Quick triage (please paste output, but do not paste the tokens)

openclaw --version
openclaw config get gateway.mode
openclaw config get gateway.remote.url
openclaw config get gateway.auth.mode
# tell me: do these two MATCH exactly? (yes/no)

#

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

2) The most common fix

If you did NOT intend to be in remote mode:

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

If you ARE intentionally in remote mode: set gateway.remote.token to the same value as the Gateway’s gateway.auth.token (then restart the gateway).

3) If it still fails: config/env mismatch between “CLI” and the running service

#

Run:

openclaw gateway status --deep --no-probe
openclaw doctor

…and paste the parts that mention config path / Config (cli) vs Config (service) / any mention of OPENCLAW_GATEWAY_TOKEN (again, redact token values).

Docs refs (relevant sections):

https://docs.openclaw.ai/help/faq (token/auth + config basics)
https://docs.openclaw.ai/gateway/troubleshooting (runbook + “Config (cli) vs Config (service)” issues)
https://docs.openclaw.ai/gateway/remote (remote mode + gateway.remote.token)

tender egret Feb 13, 2026, 1:06 AM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 4200, state active, sub running, last exit 0, reason 0)
Port 18789 is already in use.

pid 1701 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):
gilby-dashboard.service (system, unit: /etc/systemd/system/gilby-dashboard.service)
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

knotty micaBOT Feb 13, 2026, 1:08 AM

#

tender egret Service: systemd (enabled) File logs: /tmp/openclaw/openclaw-2026-02-13.log Comm...

Your --deep output is the smoking gun: you’ve effectively got more than one Gateway in play.

Key lines:

Port 18789 is already in use.
pid 1701 openclaw: openclaw-gateway (127.0.0.1:18789)
“Other gateway-like services detected: … openclaw.service (system) …”
Your user unit is ~/.config/systemd/user/openclaw-gateway.service, but there’s also a system unit called openclaw.service.

When two services fight over the same port, the CLI/UI can end up talking to the “other” instance (possibly with a different token source), which presents exactly like a token mismatch.

Fix: make it one Gateway instance on that port

1) Identify who is actually listening on 18789

Run:

#

ss -lptn 'sport = :18789'
ps -fp 1701
ps -fp 4200

This tells us which user owns the listening process (your user vs root) and which service it belongs to.

2) Check both systemd services

systemctl --user status openclaw-gateway.service --no-pager
sudo systemctl status openclaw.service --no-pager

3) Stop/disable the extra one (pick ONE to keep)

Most people should keep the user service and remove/disable the system one (but choose whichever you intended).

Stop the system service (if that’s the stray one):

#

sudo systemctl disable --now openclaw.service

Or stop the user service (if that’s the stray one):

systemctl --user disable --now openclaw-gateway.service

Then:

openclaw gateway restart
openclaw gateway status

If you still see “token mismatch” after that

Then it’s usually because one service is using an env token and the other is using config token. Check (redact token values):

#

systemctl --user show openclaw-gateway.service -p Environment
sudo systemctl show openclaw.service -p Environment
openclaw config get gateway.auth.token

Paste the outputs (with tokens removed) and I’ll tell you exactly which one to edit.

Docs ref: https://docs.openclaw.ai/gateway/troubleshooting

tender egret Feb 13, 2026, 1:16 AM

#

Environment=HOME=/root PATH=/root/.local/bin:/root/.npm-global/bin:/root/bin:/root/.nvm/current/bin:/root/.fnm/current/bin:/root/.volta/bin:/root/.asdf/shims:/root/.>

openclaw config get gateway.auth.token
Environment=HOME=/home/openclaw NODE_ENV=production PATH=/home/openclaw/.npm/bin:/home/openclaw/homebrew/bin:/usr/local/bin:/usr/bin:/bin:

knotty micaBOT Feb 13, 2026, 1:18 AM

#

tender egret Environment=HOME=/root PATH=/root/.local/bin:/root/.npm-global/bin:/root/bin:/ro...

Yep — that confirms the underlying problem: you’ve got different “homes” in play, which means different configs/tokens.

You pasted env blocks showing:

HOME=/root ... (that’s a system/root-owned service context)
HOME=/home/openclaw ... (that’s a different unix user)
while your CLI commands (when you run openclaw ... normally) read ~/.openclaw/openclaw.json for your user.

So the CLI is very likely sending the token from your ~/.openclaw/openclaw.json, but the gateway actually listening on 127.0.0.1:18789 is running under root or openclaw and reading their ~/.openclaw/openclaw.json → token mismatch.

The fix: run exactly ONE gateway, under ONE user

On Linux the simplest is: keep the user service (openclaw-gateway.service) and disable the system one (openclaw.service).

Run these:

1) Check which services are active

#

systemctl --user status openclaw-gateway.service --no-pager
sudo systemctl status openclaw.service --no-pager

2) Stop/disable the system one (if it’s enabled)

sudo systemctl disable --now openclaw.service

3) Restart your user gateway

systemctl --user restart openclaw-gateway.service
openclaw gateway status

4) Verify only one listener exists

#

ss -lptn 'sport = :18789'

If openclaw gateway status still shows “port already in use”, paste the output of:

ps -fp <the-pid-from-ss>

(no tokens involved)

Once there’s only one gateway instance, the token mismatch should disappear (because CLI + gateway will finally be reading the same config/token source).

tender egret Feb 13, 2026, 1:22 AM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 6535, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json

Gateway port 18789 is not listening (service appears running).
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 13, 2026, 1:23 AM

#

tender egret Service: systemd (enabled) File logs: /tmp/openclaw/openclaw-2026-02-13.log Comm...

Two important clues in that output:

You’re running the CLI as root (or via sudo)
It literally says:

Config: /root/.openclaw/openclaw.json

So even if the gateway service is “the right one”, your CLI is now reading root’s config/token, not your normal user’s config. Same deal for systemctl --user: if you run it as root, you’re managing root’s user-service, not your user’s.

The issue has shifted from “token mismatch” to “gateway isn’t listening / RPC probe failed” — we need the service logs to see why it didn’t bind.

Do this (and paste output)

A) First confirm which user you are

whoami

#

echo $HOME

If that says root / /root, re-run the next commands without sudo, as the user that actually owns/runs your gateway (often your normal login user, or openclaw if you created that user).

B) Check whether anything is listening on 18789

ss -lptn 'sport = :18789'

C) Get the gateway service logs (this is the key)

Run as the SAME user that runs the openclaw-gateway.service:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

#

If you’re unsure which account the user-service is under, tell me what you get for whoami when you run:

systemctl --user status openclaw-gateway.service --no-pager

Once I can see the journal errors, I can tell you exactly why it’s “running” but not binding the port (common causes: config parse error, bad env, wrong node/openclaw path, crash loop).

tender egret Feb 13, 2026, 1:27 AM

#

root@Gilbotron6900:~# whoami
root
root@Gilbotron6900:~# echo $HOME
/root
root@Gilbotron6900:~# ss -lptn 'sport = :18789'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=6535,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=6535,fd=23))

Feb 13 01:24:17 Gilbotron6900 node[6535]: 2026-02-13T01:24:17.946Z [ws] closed before connect conn=36cb0d76-c57a-44da-b7a9-131a59011dea remote=::1 fwd=193.187.130.232 origin=https://164.92.159.153 host=164.92.159.153 ua=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 code=4008 reason=connect failed
Feb 13 01:24:33 Gilbotron6900 node[6535]: 2026-02-13T01:24:33.868Z [ws] Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.

can paste more in another message if you need. i am on a macbook pro and my openclaw is running on VPS hosted by digitalocean

#

gateway.service -n 200 --no-pager
Feb 13 01:09:50 Gilbotron6900 node[4859]: 2026-02-13T01:09:50.882Z Or: systemctl --user stop openclaw-gateway.service
Feb 13 01:09:50 Gilbotron6900 systemd[934]: openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE
Feb 13 01:09:50 Gilbotron6900 systemd[934]: openclaw-gateway.service: Failed with result 'exit-code'.
Feb 13 01:09:50 Gilbotron6900 systemd[934]: openclaw-gateway.service: Consumed 7.999s CPU time.
Feb 13 01:09:55 Gilbotron6900 systemd[934]: openclaw-gateway.service: Scheduled restart job, restart counter is at 80.
Feb 13 01:09:55 Gilbotron6900 systemd[934]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.2.9).
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.672Z [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /root/.openclaw/canvas)
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.684Z Gateway failed to start: another gateway instance is already listening on ws://127.0.0.1:18789
Feb 13 01:10:03 Gilbotron6900 node[4896]: If the gateway is supervised, stop it with: openclaw gateway stop
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.786Z Port 18789 is already in use.
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.790Z - pid 1701 openclaw: openclaw-gateway (127.0.0.1:18789)
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.793Z - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.858Z Gateway service appears enabled. Stop it first.
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.862Z Tip: openclaw gateway stop
Feb 13 01:10:03 Gilbotron6900 node[4896]: 2026-02-13T01:10:03.864Z Or: systemctl --user stop openclaw-gateway.service
Feb 13 01:10:03 Gilbotron6900 systemd[934]: openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE

knotty micaBOT Feb 13, 2026, 1:34 AM

#

tender egret gateway.service -n 200 --no-pager Feb 13 01:09:50 Gilbotron6900 node[4859]: 2026...

Those logs show the gateway isn’t “mysteriously broken” — it’s refusing to start because something else is already bound to 127.0.0.1:18789:

Gateway failed to start: another gateway instance is already listening on ws://127.0.0.1:18789
- pid 1701 openclaw: openclaw-gateway (127.0.0.1:18789)

So your user service is crash-looping trying to grab a port that’s already taken.

1) Identify the process that owns the port

Run (no sudo needed):

ss -lptn 'sport = :18789'
ps -fp 1701

2) Stop the other gateway instance (most likely the system service)

Check system vs user services:

#

sudo systemctl status openclaw.service --no-pager
systemctl --user status openclaw-gateway.service --no-pager

If openclaw.service is running, disable it so you only have ONE gateway:

sudo systemctl disable --now openclaw.service

Then restart your user gateway:

systemctl --user restart openclaw-gateway.service
openclaw gateway status

3) Important: don’t run the CLI with sudo

#

Earlier your output showed Config: /root/.openclaw/openclaw.json — that happens when you run sudo openclaw ..., and it reintroduces token/config mismatches.

So: run openclaw ... as your normal user.

If after disabling openclaw.service the port is still owned by pid 1701, paste ps -fp 1701 and the ss -lptn ... output and I’ll tell you exactly what to stop next.

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

tender egret Feb 13, 2026, 1:52 AM

#

openclaw.service - Openclaw Gateway Service
Loaded: loaded (/etc/systemd/system/openclaw.service; disabled; preset: enabled)
Active: inactive (dead)

Feb 13 00:57:10 Gilbotron6900 openclaw[1701]: 2026-02-13T00:57:10.268Z [ws] closed before connect conn=c1ad14c1-8d6b-4348-bb25-c93cb24756a9 remote=127.0.….auth.token)
Feb 13 01:10:55 Gilbotron6900 systemd[1]: Stopping openclaw.service - Openclaw Gateway Service...
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.319Z [gateway] signal SIGTERM received
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.321Z [gateway] received SIGTERM; shutting down
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.326Z [gateway] signal SIGTERM received
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.328Z [gateway] received SIGTERM during shutdown; ignoring
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.336Z [gmail-watcher] gmail watcher stopped
Feb 13 01:10:57 Gilbotron6900 systemd[1]: openclaw.service: Deactivated successfully.
Feb 13 01:10:57 Gilbotron6900 systemd[1]: Stopped openclaw.service - Openclaw Gateway Service.
Feb 13 01:10:57 Gilbotron6900 systemd[1]: openclaw.service: Consumed 52.119s CPU time, 1.0G memory peak, 0B memory swap peak.
Hint: Some lines were ellipsized, use -l to show in full.
● openclaw-gateway.service - OpenClaw Gateway (v2026.2.9)
Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: active (running) since Fri 2026-02-13 01:19:36 UTC; 28min ago
Main PID: 6535 (openclaw-gatewa)
Tasks: 11 (limit: 4653)
Memory: 335.2M (peak: 361.9M)
CPU: 17.977s
CGroup: /user.slice/user-0.slice/user@0.service/app.slice/openclaw-gateway.service
└─6535 openclaw-gateway

#

ateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 10295, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 10260 root: 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

tender egret Feb 13, 2026, 2:41 AM

#

@knotty mica can you tell me what is wrong here?

knotty micaBOT Feb 13, 2026, 2:42 AM

#

tender egret <@1457407575476801641> can you tell me what is wrong here?

What’s wrong: you’ve got two different Gateway instances competing for the same port (127.0.0.1:18789). Your user systemd service is crash-looping because the port is already taken by pid 1701:

Gateway failed to start: another gateway instance is already listening on ws://127.0.0.1:18789
- pid 1701 openclaw: openclaw-gateway (127.0.0.1:18789)

On top of that, you previously ran the CLI as root at least once (Config: /root/.openclaw/openclaw.json), which can also create token/config confusion.

Do this and paste the output (no tokens involved)

Run as your normal user (no sudo):

ss -lptn 'sport = :18789'
ps -fp 1701
systemctl --user status openclaw-gateway.service --no-pager

Then also check if a system service is the other gateway (this one needs sudo):

#

sudo systemctl status openclaw.service --no-pager

Most common fix

If openclaw.service is running, stop/disable it so only the user gateway remains:

sudo systemctl disable --now openclaw.service
systemctl --user restart openclaw-gateway.service
openclaw gateway status

If instead you want the system service, do the inverse (disable the user one).

Once only one process is listening on 18789, the gateway should come up cleanly and the token mismatch symptoms should disappear (also: avoid sudo openclaw ... unless you intentionally want root’s config).

tender egret Feb 13, 2026, 2:43 AM

#

even after running your ' fix' i am still getting the same error

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 15571, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 10260 root: 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
Troubles: run openclaw status

knotty micaBOT Feb 13, 2026, 2:45 AM

#

tender egret even after running your ' fix' i am still getting the same error Service: syst...

That output is still showing the same root cause, just more clearly:

Your CLI is still running as root (or via sudo), because it says:

Config: /root/.openclaw/openclaw.json

The thing actually listening on the gateway port is a root-owned gateway:

pid 10260 root: openclaw-gateway (127.0.0.1:18789)

So even if your normal-user gateway token is correct, you’ll keep getting token mismatch as long as:

the listener on :18789 is root’s gateway (using root’s token/config), and/or
you run openclaw ... under root (so it reads root’s config and sends root’s token).

Fix (get to ONE gateway + ONE user)

Step A — confirm you’re not root

Run without sudo:

#

whoami
echo $HOME

Step B — stop the root-owned gateway that’s on 18789

First see what started pid 10260:

ps -fp 10260
sudo systemctl status openclaw.service --no-pager

Then stop/disable it (most likely this is the culprit):

sudo systemctl disable --now openclaw.service

#

If after that the port is still taken, stop the specific root process:

sudo kill 10260

Verify the port is free / owned by the right user:

ss -lptn 'sport = :18789'

Step C — start your normal user gateway and test (NO sudo)

systemctl --user restart openclaw-gateway.service
openclaw gateway status

If you paste the outputs of:

#

whoami && echo $HOME
ss -lptn 'sport = :18789'
ps -fp 10260 (if it comes back)
sudo systemctl status openclaw.service --no-pager

…I can tell you exactly which service is still spawning the root gateway.

(Also: avoid sudo openclaw ... unless you intentionally want root’s /root/.openclaw/openclaw.json to be the active config.)

tender egret Feb 13, 2026, 2:51 AM

#

first part:

root@Gilbotron6900:~# whoami
root
root@Gilbotron6900:~# echo $HOME
/root
root@Gilbotron6900:~# ps -fp 10260
UID PID PPID C STIME TTY TIME CMD
root 10260 934 0 01:53 ? 00:00:22 openclaw-gateway
root@Gilbotron6900:~# sudo systemctl status openclaw.service --no-pager
○ openclaw.service - Openclaw Gateway Service
Loaded: loaded (/etc/systemd/system/openclaw.service; disabled; preset: enabled)
Active: inactive (dead)

Feb 13 00:57:10 Gilbotron6900 openclaw[1701]: 2026-02-13T00:57:10.268Z [ws] closed before connect conn=c1ad14c1-8d6b-4348-bb25-c93cb24756a9 remote=127.0.….auth.token)
Feb 13 01:10:55 Gilbotron6900 systemd[1]: Stopping openclaw.service - Openclaw Gateway Service...
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.319Z [gateway] signal SIGTERM received
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.321Z [gateway] received SIGTERM; shutting down
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.326Z [gateway] signal SIGTERM received
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.328Z [gateway] received SIGTERM during shutdown; ignoring
Feb 13 01:10:55 Gilbotron6900 openclaw[1701]: 2026-02-13T01:10:55.336Z [gmail-watcher] gmail watcher stopped
Feb 13 01:10:57 Gilbotron6900 systemd[1]: openclaw.service: Deactivated successfully.
Feb 13 01:10:57 Gilbotron6900 systemd[1]: Stopped openclaw.service - Openclaw Gateway Service.
Feb 13 01:10:57 Gilbotron6900 systemd[1]: openclaw.service: Consumed 52.119s CPU time, 1.0G memory peak, 0B memory swap peak.
Hint: Some lines were ellipsized, use -l to show in full.
root@Gilbotron6900:~# sudo kill 10260
root@Gilbotron6900:~# ss -lptn 'sport = :18789'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
root@Gilbotron6900:~# systemctl --user restart openclaw-gateway.service

#

second part:

OpenClaw 2026.2.9 (33c75cb) — Your AI assistant, now without the $3,499 headset.

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 16248, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 16248 root: 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 13, 2026, 2:52 AM

#

tender egret first part: root@Gilbotron6900:~# whoami root root@Gilbotron6900:~# echo $HOME ...

Cool, this is progress: you proved the port conflict piece (18789 is now free).

But you’re currently doing everything as root (whoami → root, config path /root/.openclaw/openclaw.json). That means:

openclaw ... uses root’s config + tokens
systemctl --user ... manages root’s user service (not your normal login user’s)

So if your gateway was originally set up under a non-root user, running these commands as root will keep producing “token mismatch” / “weird service state” symptoms.

1) Decide: do you want the Gateway to run as root, or as a normal user?

Recommended: normal user (whatever account you actually use to run OpenClaw).

If you want the normal-user gateway

From root, switch to that user (replace YOURUSER):

su - YOURUSER

#

whoami
echo $HOME

Then run (as that user, no sudo):

systemctl --user restart openclaw-gateway.service
openclaw gateway status
ss -lptn 'sport = :18789'

2) If you insist on running everything as root

Then make root’s config consistent (redact token values when pasting):

#

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

If gateway.mode is remote or gateway.remote.url is set, fix it:

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

Then restart root’s user service + check logs:

#

systemctl --user restart openclaw-gateway.service
journalctl --user -u openclaw-gateway.service -n 80 --no-pager
ss -lptn 'sport = :18789'

What I need from you

Tell me which user you want to run the gateway under, and paste:

whoami + echo $HOME (from that user)
journalctl --user -u openclaw-gateway.service -n 80 --no-pager (from that same user)

Then we can get the gateway actually listening again and the token mismatch will stop (because CLI + gateway will finally be using the same user/config).

#

This output is actually consistent now:

The Gateway is running and listening (pid 16248 on 127.0.0.1:18789)
The CLI can reach it, but the RPC probe is being rejected with:
unauthorized: gateway token mismatch

And it also shows why: you’re running everything as root, so the CLI config is:

Config: /root/.openclaw/openclaw.json

What’s wrong (specific)

In /root/.openclaw/openclaw.json, your client token and gateway token don’t match:

gateway.auth.token = what the gateway expects
gateway.remote.token = what the CLI is sending (your status output even tells you to sync these)

Fix (sync the tokens)

Run these (don’t paste the token values back here):

#

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

If they differ, make them the same. Easiest is to set gateway.remote.token to exactly the gateway.auth.token value:

openclaw config set gateway.remote.token "<PASTE gateway.auth.token HERE>"
systemctl --user restart openclaw-gateway.service
openclaw gateway status

If you’d rather just reset to a fresh token (often fastest)

This guarantees both are identical:

#

TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.token "$TOKEN"
openclaw config set gateway.remote.token "$TOKEN"
systemctl --user restart openclaw-gateway.service
openclaw gateway status

(After this, any UI/client that connects will need the new token too.)

One more gotcha to rule out (env override)

Make sure the service isn’t using an env token that overrides config:

systemctl --user show openclaw-gateway.service -p Environment | tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN || echo "no OPENCLAW_GATEWAY_TOKEN in service env"

#

If that shows a token, it must also match, otherwise you’ll keep getting mismatches.

If you tell me just “do the two tokens match: yes/no” (no values), and whether OPENCLAW_GATEWAY_TOKEN is present in the service env, I can point to the exact remaining mismatch.

tender egret Feb 13, 2026, 3:04 AM

#

the remote and auth tokens match, but OPENCLAW_GATEWAY_TOKEN is present and does not match

knotty micaBOT Feb 13, 2026, 3:05 AM

#

tender egret the remote and auth tokens match, but OPENCLAW_GATEWAY_TOKEN is present and does...

Perfect — that explains it. OPENCLAW_GATEWAY_TOKEN overrides gateway.auth.token, so your gateway is expecting the env-var token, while the CLI is using the config token → mismatch.

You have two options (pick one):

Option A (recommended): remove the env var and use config only

Find where it’s coming from (as the same user running the service — you’re root right now, so this is /root/...):

systemctl --user cat openclaw-gateway.service

Also check the daemon env file (common source):

ls -la ~/.openclaw/.env
rg "OPENCLAW_GATEWAY_TOKEN" ~/.openclaw/.env || true

Remove it (either delete the line in ~/.openclaw/.env, or remove it from the systemd unit), then reload + restart:

#

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

Option B: keep the env var, but set it to the same value

Set the service env token to match your config token (edit whichever place you found it: the unit file or ~/.openclaw/.env), then:

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

Quick “no editor” workaround (force-clear env var via systemd override)

This makes systemd set it to empty even if it’s set elsewhere:

#

systemctl --user edit openclaw-gateway.service

Put:

[Service]
Environment=OPENCLAW_GATEWAY_TOKEN=

Save/exit, then:

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so it’s indexed for others.

tender egret Feb 13, 2026, 3:12 AM

#

how/where do i edit to go with option B? i need to do it through the console:

[Service]
ExecStart="/usr/bin/node" "/usr/lib/node_modules/openclaw/dist/index.js" gateway --port 18789
Restart=always
RestartSec=5
KillMode=process
Environment=HOME=/root
Environment="PATH=/root/.local/bin:/root/.npm-global/bin:/root/bin:/root/.nvm/current/bin:/root/.fnm/current/bin:/root/.volta/bin:/root/.asdf/shims:/root/.local/shar>
Environment=OPENCLAW_GATEWAY_PORT=18789
Environment=OPENCLAW_GATEWAY_TOKEN=685REDACTEDded563
Environment="OPENCLAW_SYSTEMD_UNIT=openclaw-gateway.service"
Environment=OPENCLAW_SERVICE_MARKER=openclaw
Environment=OPENCLAW_SERVICE_KIND=gateway
Environment=OPENCLAW_SERVICE_VERSION=2026.2.9

knotty micaBOT Feb 13, 2026, 3:13 AM

#

tender egret how/where do i edit to go with option B? i need to do it through the console: [...

You’re looking at the systemd unit environment, so Option B = update OPENCLAW_GATEWAY_TOKEN there to exactly match your gateway.auth.token (the one in ~/.openclaw/openclaw.json).

Console-only way (no editor): add a systemd drop-in override

This is the cleanest approach because it doesn’t require modifying the main unit file.

# 1) Read the token from config (don’t paste it in chat)
TOKEN="$(openclaw config get gateway.auth.token | tr -d '\n')"

# 2) Create a drop-in that overrides OPENCLAW_GATEWAY_TOKEN
mkdir -p ~/.config/systemd/user/openclaw-gateway.service.d
cat > ~/.config/systemd/user/openclaw-gateway.service.d/override-token.conf <<EOF
[Service]
Environment=OPENCLAW_GATEWAY_TOKEN=$TOKEN
EOF

#

# 3) Reload + restart
systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

Verify it took effect:

systemctl --user show openclaw-gateway.service -p Environment | tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN
openclaw gateway status

Important note

Run those commands as the same user that runs the gateway. Right now you’re root, so this will affect root’s --user service manager and /root/.openclaw/... config (which matches what your earlier gateway status output showed).

If you want this gateway under a non-root user later, we can move it, but the steps above will fix the mismatch in your current setup.

tender egret Feb 13, 2026, 4:41 AM

#

those commands havent fixed the issue. i am still getting the same error from openclaw gateway status

tender egret Feb 13, 2026, 12:21 PM

#

@krill can you help

knotty micaBOT Feb 13, 2026, 12:24 PM

#

tender egret @krill can you help

Yep — where are you stuck (which command/errors)? Last time we were one step away: your OPENCLAW_GATEWAY_TOKEN (systemd env) didn’t match the config token, so the gateway rejects the CLI.

If you just want it working fast from the console, do this (run as the same user that runs the gateway service — in your earlier logs that was root):

Force config to match the token systemd is using (no editing unit files)

SVC_TOKEN="$(systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p')"

openclaw config set gateway.auth.token "$SVC_TOKEN"
openclaw config set gateway.remote.token "$SVC_TOKEN"

systemctl --user restart openclaw-gateway.service
openclaw gateway status

If it still errors

#

Paste (with tokens redacted) the output of:

openclaw gateway status
systemctl --user show openclaw-gateway.service -p Environment --value | tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN
openclaw config get gateway.auth.token
openclaw config get gateway.remote.token

That will tell us exactly what’s still mismatched (or if you’re accidentally running the CLI under a different user/home again).

tender egret Feb 13, 2026, 12:27 PM

#

root@Gilbotron6900:~# openclaw gateway status

🦞 OpenClaw 2026.2.9 (33c75cb) — Greetings, Professor Falken

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 76461, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 19908 root: 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 13, 2026, 12:28 PM

#

tender egret root@Gilbotron6900:~# openclaw gateway status 🦞 OpenClaw 2026.2.9 (33c75cb) — ...

Your gateway status output shows you still have two different gateway processes involved:

Service “main pid”: 76461
Actual listener on 18789: 19908 root: openclaw-gateway (127.0.0.1:18789)

The token mismatch is almost certainly because pid 19908 is an older/stray gateway that’s still bound to the port and expecting a different token than your CLI config.

1) Confirm what those two PIDs are

Run:

ps -fp 76461
ps -fp 19908
ss -lptn 'sport = :18789'

2) Stop the supervised service, then kill the stray listener

#

openclaw gateway stop || true
systemctl --user stop openclaw-gateway.service || true

# if 18789 is STILL listening, stop the stray one:
kill 19908
sleep 1
ss -lptn 'sport = :18789'

If it still won’t die, tell me what ps -fp 19908 shows after the kill.

3) Start ONE gateway with ONE token (fastest “make it work” reset)

This sets config tokens + systemd env token to the same new value, then restarts:

#

TOKEN="$(openssl rand -hex 32)"

openclaw config set gateway.auth.token "$TOKEN"
openclaw config set gateway.remote.token "$TOKEN"

mkdir -p ~/.config/systemd/user/openclaw-gateway.service.d
cat > ~/.config/systemd/user/openclaw-gateway.service.d/override-token.conf <<EOF
[Service]
Environment=OPENCLAW_GATEWAY_TOKEN=$TOKEN
EOF

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

#

If you paste the outputs of step (1) after you run it, I can tell you exactly what’s still starting that extra listener (19908) if it comes back.

tender egret Feb 13, 2026, 12:34 PM

#

root@Gilbotron6900:~# ps -fp 76461
UID PID PPID C STIME TTY TIME CMD
root@Gilbotron6900:~# ps -fp 19908
UID PID PPID C STIME TTY TIME CMD
root 19908 934 0 03:16 ? 00:00:53 openclaw-gateway
root@Gilbotron6900:~# ss -lptn 'sport = :18789'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=19908,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=19908,fd=23))

#

i followed the 3 steps and got this:

OpenClaw 2026.2.9 (33c75cb) — I don't judge, but your missing API keys are absolutely judging you.

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 77234, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 77156 root: 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

#

@krill can you help

knotty micaBOT Feb 13, 2026, 12:43 PM

#

tender egret @krill can you help

Yep. Right now your gateway status is showing two different PIDs:

systemd thinks the service is running as pid 76461
but the process actually listening on 127.0.0.1:18789 is pid 19908 (root: openclaw-gateway)

As long as that older listener is on the port, you can keep changing tokens and still get “token mismatch” (because you’re talking to the wrong process).

Do this “hard reset” of the listener (console-only)

Run as root, and paste the outputs (tokens redacted if they appear):

# 1) Stop the supervised service
systemctl --user stop openclaw-gateway.service

# 2) Kill ANY leftover gateway processes (this is the key)
pkill -f 'openclaw-gateway' || true

#

pkill -f 'dist/index.js.* gateway' || true

# 3) Confirm nothing is listening on 18789
ss -lptn 'sport = :18789'

# 4) Start the service fresh
systemctl --user daemon-reload
systemctl --user start openclaw-gateway.service

# 5) Confirm the *new* listener PID
systemctl --user show openclaw-gateway.service -p MainPID
ss -lptn 'sport = :18789'

# 6) Try again
openclaw gateway status

#

If it STILL says token mismatch

Then the remaining mismatch is definitely between:

the gateway’s effective token (env OPENCLAW_GATEWAY_TOKEN), and
the CLI token (from /root/.openclaw/openclaw.json)

In that case paste:

systemctl --user show openclaw-gateway.service -p Environment --value | tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN
openclaw config get gateway.auth.token
openclaw config get gateway.remote.token

and I’ll tell you exactly which value needs to be updated (without you pasting the token itself).

tender egret Feb 13, 2026, 1:41 PM

#

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

all match

tender egret Feb 13, 2026, 2:09 PM

#

@krill help me

knotty micaBOT Feb 13, 2026, 2:12 PM

#

tender egret @krill help me

You’re still in the “talking to the wrong process / wrong token source” loop. Let’s force it into a single, consistent state.

Run exactly this as root (copy/paste). It will:

stop the service
kill any stray gateway still holding the port
read the effective OPENCLAW_GATEWAY_TOKEN from systemd
write that same token into gateway.auth.token + gateway.remote.token
start the service fresh

set -euo pipefail

# 1) Stop supervised gateway + kill anything left over
systemctl --user stop openclaw-gateway.service || true
pkill -f 'openclaw-gateway' || true

#

pkill -f 'dist/index.js.* gateway' || true

echo "=== listeners after kill (should be empty) ==="
ss -lptn 'sport = :18789' || true

# 2) Read the effective token systemd is giving the service (do NOT paste the token)
SVC_TOKEN="$(
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' \
| sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p'
)"

if [ -z "${SVC_TOKEN}" ]; then
echo "ERROR: OPENCLAW_GATEWAY_TOKEN not found in systemd env for openclaw-gateway.service"
echo "Run: systemctl --user cat openclaw-gateway.service"

#

exit 1
fi

# 3) Make config match the service env token
openclaw config set gateway.auth.token "$SVC_TOKEN"
openclaw config set gateway.remote.token "$SVC_TOKEN"

# 4) Start fresh + verify
systemctl --user start openclaw-gateway.service
sleep 1

echo "=== listeners after start (should show ONE pid) ==="
ss -lptn 'sport = :18789' || true

openclaw gateway status

#

Now paste the output of only these (they won’t include the token):

ss -lptn 'sport = :18789'
openclaw gateway status

If ss shows more than one listener / or the PID changes unexpectedly, we’ll chase what is respawning it.

tender egret Feb 13, 2026, 4:56 PM

#

root@Gilbotron6900:~# ss -lptn 'sport = :18789'
openclaw gateway status
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=103288,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=103288,fd=23))

🦞 OpenClaw 2026.2.9 (33c75cb) — Shell yeah—I'm here to pinch the toil and leave you the glory.

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-13.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 103543, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 103288 root: 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
Troubles: run openclaw status

#

help me @knotty mica

knotty micaBOT Feb 13, 2026, 4:59 PM

#

tender egret help me <@1457407575476801641>

I can help, but I need one concrete data point: which process is actually listening on 127.0.0.1:18789 right now, and what token the service env is using. Your earlier outputs kept flipping between multiple PIDs + an env token override.

Run this as root and paste the output (it won’t reveal the token value):

# what is listening right now?
ss -lptn 'sport = :18789' || true

# show the token SOURCE the service is using (but don't paste the value)
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=.*/OPENCLAW_GATEWAY_TOKEN=SET/p'

Then do the fix that always works (make systemd’s OPENCLAW_GATEWAY_TOKEN match your config token) — console-only, no editor:

#

TOKEN="$(openclaw config get gateway.auth.token | tr -d '\n')"

mkdir -p ~/.config/systemd/user/openclaw-gateway.service.d
cat > ~/.config/systemd/user/openclaw-gateway.service.d/override-token.conf <<EOF
[Service]
Environment=OPENCLAW_GATEWAY_TOKEN=$TOKEN
EOF

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

If openclaw gateway status STILL shows a “Port 18789 is already in use” line, paste just this (no tokens involved) and I’ll tell you what’s respawning the extra gateway:

#

ss -lptn 'sport = :18789'
ps -fp <PID_FROM_SS>

tender egret Feb 13, 2026, 5:03 PM

#

it still shows port is already in use. i received this:

root@Gilbotron6900:~# ss -lptn 'sport = :18789'
ps -fp 103288
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=103288,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=103288,fd=23))
UID PID PPID C STIME TTY TIME CMD
root 103288 934 2 16:51 ? 00:00:15 openclaw-gateway

#

did i input that correctly ?

#

@krill tell me what is respawning the extra gateway

#

@knotty mica tell me what is respawning the extra gateway

knotty micaBOT Feb 13, 2026, 5:15 PM

#

tender egret @krill tell me what is respawning the extra gateway

I can’t tell “what is respawning it” from chat logs alone — you have to identify the parent/unit of the PID that’s listening on 18789. That will directly name the respawner (systemd unit, cron, tmux, etc.).

Run this and paste the output:

# 1) get the PID that is actually listening on the gateway port
ss -lptn 'sport = :18789'

# 2) replace <PID> with the one shown by ss:
PID=<PID>
ps -o pid,ppid,user,cmd -p "$PID"

# 3) show the full ancestry (this usually makes it obvious)
pstree -sp "$PID" || true

# 4) if it’s systemd-managed, THIS will name the unit

#

systemctl status "$PID" --no-pager || true
systemctl --user status "$PID" --no-pager || true

# 5) fallback: cgroup path (also points to the unit)
cat /proc/"$PID"/cgroup | head

What you’ll typically see:

If systemctl status <PID> shows something like openclaw.service → system service is respawning it → sudo systemctl disable --now openclaw.service
If it shows openclaw-gateway.service under --user → user service is respawning it → systemctl --user disable --now openclaw-gateway.service
If pstree shows bash / tmux / screen → you (or a script) started it manually and that session is respawning it.

Paste those outputs and I’ll tell you exactly which thing is doing the respawn and the exact stop/disable command for it.

tender egret Feb 13, 2026, 5:20 PM

#

root@Gilbotron6900:~# ss -lptn 'sport = :18789'
ps -fp <PID_FROM_SS>
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=103288,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=103288,fd=23))
-bash: syntax error near unexpected token `newline'
root@Gilbotron6900:~# ss -lptn 'sport = :18789'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=103288,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=103288,fd=23))

#

root@Gilbotron6900:~# PID=103288
ps -o pid,ppid,user,cmd -p "$PID"
PID PPID USER CMD
103288 934 root openclaw-gateway
root@Gilbotron6900:~# pstree -sp "$PID" || true
systemd(1)───systemd(934)───openclaw-gatewa(103288)─┬─{openclaw-gatewa}(103289)
├─{openclaw-gatewa}(103290)
├─{openclaw-gatewa}(103291)
├─{openclaw-gatewa}(103292)
├─{openclaw-gatewa}(103293)
├─{openclaw-gatewa}(103294)
├─{openclaw-gatewa}(103295)
├─{openclaw-gatewa}(103296)
├─{openclaw-gatewa}(103297)
└─{openclaw-gatewa}(103298)
root@Gilbotron6900:~# systemctl status "$PID" --no-pager || true
systemctl --user status "$PID" --no-pager || true
● user@0.service - User Manager for UID 0
Loaded: loaded (/usr/lib/systemd/system/user@.service; static)
Drop-In: /usr/lib/systemd/system/user@0.service.d
└─10-login-barrier.conf
/usr/lib/systemd/system/user@.service.d
└─timeout.conf
Active: active (running) since Fri 2026-02-13 00:51:37 UTC; 16h ago
Docs: man:user@.service(5)
Main PID: 934 (systemd)
Status: "Ready."
Tasks: 20
Memory: 644.7M (peak: 1.7G)

#

CPU: 12h 9min 31.627s
CGroup: /user.slice/user-0.slice/user@0.service
├─app.slice
│ ├─openclaw-gateway-rescue.service
│ │ └─103288 openclaw-gateway
│ └─openclaw-gateway.service
│ └─106031 /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
└─init.scope
├─934 /usr/lib/systemd/systemd --user
└─941 "(sd-pam)"

Feb 13 17:18:19 Gilbotron6900 node[106014]: 2026-02-13T17:18:19.347Z - pid 103288 root: openclaw-gateway (127.0.0.1:18789)
Feb 13 17:18:19 Gilbotron6900 node[106014]: 2026-02-13T17:18:19.349Z - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Feb 13 17:18:19 Gilbotron6900 node[106014]: 2026-02-13T17:18:19.407Z Gateway service appears enabled. Stop it first.
Feb 13 17:18:19 Gilbotron6900 node[106014]: 2026-02-13T17:18:19.409Z Tip: openclaw gateway stop
Feb 13 17:18:19 Gilbotron6900 node[106014]: 2026-02-13T17:18:19.411Z Or: systemctl --user stop openclaw-gateway.service
Feb 13 17:18:19 Gilbotron6900 systemd[934]: openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE
Feb 13 17:18:19 Gilbotron6900 systemd[934]: openclaw-gateway.service: Failed with result 'exit-code'.
Feb 13 17:18:19 Gilbotron6900 systemd[934]: openclaw-gateway.service: Consumed 9.575s CPU time.
Feb 13 17:18:24 Gilbotron6900 systemd[934]: openclaw-gateway.service: Scheduled restart job, restart counter is at 123.
Feb 13 17:18:24 Gilbotron6900 systemd[934]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.2.9).
● openclaw-gateway-rescue.service - OpenClaw Gateway (profile: rescue, v2026.2.9)
Loaded: loaded (/root/.config/systemd/user/openclaw-gateway-rescue.service; enabled; preset: enabled)
Active: active (running) since Fri 2026-02-13 16:51:45 UTC; 26min ago

#

Main PID: 103288 (openclaw-gatewa)
Tasks: 11 (limit: 4653)
Memory: 333.8M (peak: 359.9M)
CPU: 18.977s
CGroup: /user.slice/user-0.slice/user@0.service/app.slice/openclaw-gateway-rescue.service
└─103288 openclaw-gateway

Feb 13 17:17:30 Gilbotron6900 node[103288]: 2026-02-13T17:17:30.926Z [ws] closed before connect conn=b4b30df6-8537-40c3-bc9e-e0cacd497f01 remote=::1 fwd=193.187.130.…
Feb 13 17:17:46 Gilbotron6900 node[103288]: 2026-02-13T17:17:46.855Z [ws] Proxy headers detected from untrusted address. Connection will not be treated a… your proxy.
Feb 13 17:17:46 Gilbotron6900 node[103288]: 2026-02-13T17:17:46.881Z [ws] unauthorized conn=6d6c38c0-c419-4e50-a4f0-bf26421836de remote=::1 client=opencl…ken_mismatch
Feb 13 17:17:46 Gilbotron6900 node[103288]: 2026-02-13T17:17:46.917Z [ws] closed before connect conn=6d6c38c0-c419-4e50-a4f0-bf26421836de remote=::1 fwd=193.187.130.…
Feb 13 17:18:02 Gilbotron6900 node[103288]: 2026-02-13T17:18:02.872Z [ws] Proxy headers detected from untrusted address. Connection will not be treated a… your proxy.
Feb 13 17:18:02 Gilbotron6900 node[103288]: 2026-02-13T17:18:02.894Z [ws] unauthorized conn=3ab48bca-30f2-4eca-ba79-1cdfed900be3 remote=::1 client=opencl…ken_mismatch
Feb 13 17:18:02 Gilbotron6900 node[103288]: 2026-02-13T17:18:02.938Z [ws] closed before connect conn=3ab48bca-30f2-4eca-ba79-1cdfed900be3 remote=::1 fwd=193.187.130.…
Feb 13 17:18:18 Gilbotron6900 node[103288]: 2026-02-13T17:18:18.882Z [ws] Proxy headers detected from untrusted address. Connection will not be treated a… your proxy.
Feb 13 17:18:18 Gilbotron6900 node[103288]: 2026-02-13T17:18:18.904Z [ws] unauthorized conn=ca5afecf-9991-4fdc-9a0a-87a74601f3e0 remote=::1 client=opencl…ken_mismatch
Feb 13 17:18:18 Gilbotron6900 node[103288]: 2026-02-13T17:18:18.940Z [ws] closed before connect conn=ca5afecf-9991-4fdc-9a0a-87a74601f3e0 remote=::1 fwd=193.187.130.…
Hint: Some lines were ellipsized, use -l to show in full.

tender egret Feb 13, 2026, 11:44 PM

#

@knotty mica can you help

knotty micaBOT Feb 13, 2026, 11:44 PM

#

I can’t know what’s respawning it until we identify which exact PID is holding :18789 and what unit/cgroup it belongs to. That’s the fingerprint that tells you the respawner.

Run this (as the same user you’re operating as now — you’ve been root) and paste the output:

# PID that is actually listening on 18789
ss -lptn 'sport = :18789'

# replace <PID> with the number from ss
PID=<PID>

# show who started it
ps -o pid,ppid,user,cmd -p "$PID"
pstree -sp "$PID" || true

# this usually names the systemd unit directly

#

systemctl status "$PID" --no-pager || true
systemctl --user status "$PID" --no-pager || true

# guaranteed: shows the cgroup path (points to the unit)
cat /proc/"$PID"/cgroup | head -n 5

What you’re looking for in the output

If /system.slice/openclaw.service → it’s the system service respawning it
Fix: sudo systemctl disable --now openclaw.service
If it mentions openclaw-gateway.service under --user (root’s user service) → user service respawning it
Fix: systemctl --user disable --now openclaw-gateway.service
If the tree shows bash / tmux / screen / a script → it’s being launched manually (or by a script), not systemd.

Paste those outputs and I’ll tell you exactly which thing is respawning the extra gateway and the precise stop/disable command.

tender egret Feb 13, 2026, 11:55 PM

#

root@Gilbotron6900:~# ss -lptn 'sport = :18789'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=103288,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=103288,fd=23))
root@Gilbotron6900:~# PID=103288
root@Gilbotron6900:~# ps -o pid,ppid,user,cmd -p "$PID"
pstree -sp "$PID" || true
PID PPID USER CMD
103288 934 root openclaw-gateway
systemd(1)───systemd(934)───openclaw-gatewa(103288)─┬─{openclaw-gatewa}(103289)
├─{openclaw-gatewa}(103290)
├─{openclaw-gatewa}(103291)
├─{openclaw-gatewa}(103292)
├─{openclaw-gatewa}(103293)
├─{openclaw-gatewa}(103294)
├─{openclaw-gatewa}(103295)
├─{openclaw-gatewa}(103296)
├─{openclaw-gatewa}(103297)
└─{openclaw-gatewa}(103298)

#

root@Gilbotron6900:~# systemctl status "$PID" --no-pager || true
systemctl --user status "$PID" --no-pager || true
● user@0.service - User Manager for UID 0
Loaded: loaded (/usr/lib/systemd/system/user@.service; static)
Drop-In: /usr/lib/systemd/system/user@0.service.d
└─10-login-barrier.conf
/usr/lib/systemd/system/user@.service.d
└─timeout.conf
Active: active (running) since Fri 2026-02-13 00:51:37 UTC; 23h ago
Docs: man:user@.service(5)
Main PID: 934 (systemd)
Status: "Ready."
Tasks: 24
Memory: 812.9M (peak: 1.7G)
CPU: 16h 58min 24.725s
CGroup: /user.slice/user-0.slice/user@0.service
├─app.slice
│ ├─openclaw-gateway-rescue.service
│ │ └─103288 openclaw-gateway
│ └─openclaw-gateway.service
│ └─146682 openclaw-gateway
└─init.scope
├─934 /usr/lib/systemd/systemd --user
└─941 "(sd-pam)"

knotty micaBOT Feb 13, 2026, 11:55 PM

#

That PID tree answers it: the process on :18789 (PID 103288) is being spawned + kept alive by systemd’s user instance (PID 934) — i.e. it’s your openclaw-gateway.service user unit (running under root).

PPID 934 = root’s systemd --user
Restart=always in the unit = systemd will respawn it forever if it exits

So the “respawner” is: systemctl --user → openclaw-gateway.service (root user).

If you want to stop it from respawning

systemctl --user disable --now openclaw-gateway.service
systemctl --user reset-failed openclaw-gateway.service

If your real issue is still the token mismatch

Because the gateway is systemd-managed, it’s almost certainly using OPENCLAW_GATEWAY_TOKEN from the unit env (which overrides config). Make systemd’s env token match your config token:

#

CFG_TOKEN="$(openclaw config get gateway.auth.token | tr -d '\n')"

mkdir -p ~/.config/systemd/user/openclaw-gateway.service.d
cat > ~/.config/systemd/user/openclaw-gateway.service.d/override-token.conf <<EOF
[Service]
Environment=OPENCLAW_GATEWAY_TOKEN=$CFG_TOKEN
EOF

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

If it still mismatches after that, paste:

#

systemctl --user show openclaw-gateway.service -p Environment --value | tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN
openclaw config get gateway.auth.token
openclaw config get gateway.remote.token
systemctl --user status openclaw-gateway.service --no-pager

(redact token values if they appear) and we’ll see why the override isn’t taking.

#

Found it: you have TWO root user-level systemd gateway units running at the same time:

openclaw-gateway-rescue.service → PID 103288 (this is the one currently holding :18789)
openclaw-gateway.service → PID 146682 (the “normal” one)

That’s why things keep coming back / conflicting, and why token fixes feel like they don’t stick: you keep talking to whichever one is actually bound to the port.

Fix: disable the rescue gateway, keep only the normal one

Run as root:

systemctl --user status openclaw-gateway-rescue.service openclaw-gateway.service --no-pager
ss -lptn 'sport = :18789'

Then stop + disable the rescue unit:

#

systemctl --user disable --now openclaw-gateway-rescue.service
systemctl --user reset-failed openclaw-gateway-rescue.service

Restart the normal gateway:

systemctl --user restart openclaw-gateway.service
ss -lptn 'sport = :18789'
openclaw gateway status

If you still get token mismatch after that

Check which token the remaining service is using:

#

systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN

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

If OPENCLAW_GATEWAY_TOKEN is set, it must match the config token(s) (env overrides config).

Paste the outputs of the two systemctl --user status ... lines + ss -lptn ... after disabling rescue (no token values needed) and I’ll confirm you’re down to a single gateway process.

tender egret Feb 13, 2026, 11:58 PM

#

root@Gilbotron6900:~# systemctl --user disable --now openclaw-gateway.service
systemctl --user reset-failed openclaw-gateway.service
Removed "/root/.config/systemd/user/default.target.wants/openclaw-gateway.service".
Failed to reset failed state of unit openclaw-gateway.service: Unit openclaw-gateway.service not loaded.

knotty micaBOT Feb 13, 2026, 11:58 PM

#

You disabled the normal unit (openclaw-gateway.service), not the rescue one — and the “Unit … not loaded” on reset-failed just means systemd has already unloaded it (not a big deal; you can reset-failed without specifying a unit).

Let’s get you back to exactly one gateway unit.

1) Show me what units exist right now

systemctl --user list-units --all | rg 'openclaw-gateway' || true
systemctl --user list-unit-files | rg 'openclaw-gateway' || true

2) Stop/disable the rescue gateway (this is the one that was stealing the port)

systemctl --user disable --now openclaw-gateway-rescue.service
systemctl --user reset-failed

3) Re-enable/start the normal gateway

#

systemctl --user enable --now openclaw-gateway.service

4) Verify only ONE PID is listening, then re-test

ss -lptn 'sport = :18789'
openclaw gateway status

If step (3) errors with “unit not found”, paste the output of step (1) — then we’ll either:

start the correct unit name (maybe it’s profile-named), or
reinstall the user unit cleanly via openclaw gateway install --force (only if needed).

tender egret Feb 14, 2026, 12:03 AM

#

root@Gilbotron6900:~# systemctl --user enable --now openclaw-gateway.service
Created symlink /root/.config/systemd/user/default.target.wants/openclaw-gateway.service → /root/.config/systemd/user/openclaw-gateway.service.
root@Gilbotron6900:~# ss -lptn 'sport = :18789'
openclaw gateway status
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=146973,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=146973,fd=23))

🦞 OpenClaw 2026.2.9 (33c75cb) — Claws out, commit in—let's ship something mildly responsible.

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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 146973, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 146973 root: 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 14, 2026, 12:03 AM

#

Good: you’re down to one listener now (pid=146973). The only thing left is: the gateway is still expecting a different token than what the CLI is sending.

On your box that’s almost always because systemd is injecting OPENCLAW_GATEWAY_TOKEN, and that value overrides whatever is in ~/.openclaw/openclaw.json.

1) Confirm whether the service is still getting an env token

Run:

systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN || echo "NO OPENCLAW_GATEWAY_TOKEN"

2) Force systemd’s token to match the config token (console-only)

This is the “make it consistent” fix:

TOKEN="$(openclaw config get gateway.auth.token | tr -d '\n')"

#


mkdir -p ~/.config/systemd/user/openclaw-gateway.service.d
cat > ~/.config/systemd/user/openclaw-gateway.service.d/override-token.conf <<EOF
[Service]
Environment=OPENCLAW_GATEWAY_TOKEN=$TOKEN
EOF

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

If it STILL says token mismatch

Then your CLI is likely in remote mode / sending gateway.remote.token. Check + fix:

#

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

# force local mode:
openclaw config set gateway.mode local
openclaw config unset gateway.remote.url
openclaw config unset gateway.remote.token

systemctl --user restart openclaw-gateway.service
openclaw gateway status

Paste the output of:

the systemctl --user show ... OPENCLAW_GATEWAY_TOKEN command (it won’t show the value unless you paste it)
openclaw config get gateway.mode

#

and the full openclaw gateway status

…and I’ll tell you exactly which knob is still out of sync.

#

You’re down to one gateway process now (pid 146973), so the remaining problem is purely: the token the gateway expects ≠ the token the CLI is sending.

On your setup there are up to 4 places a token can come from:

gateway.auth.token (config)
gateway.remote.token (config, what the CLI sends in “remote” auth flow)
OPENCLAW_GATEWAY_TOKEN (systemd service env — this overrides config for the running gateway)
OPENCLAW_GATEWAY_TOKEN in your shell env (can also affect the CLI)

First, show hashes (no secrets) so we know which one differs

Run and paste the output:

AUTH="$(openclaw config get gateway.auth.token | tr -d '\n')"
REMOTE="$(openclaw config get gateway.remote.token | tr -d '\n')"
SVC="$(

#

systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p' | tr -d '\n'
)"
SHELL_TOKEN="${OPENCLAW_GATEWAY_TOKEN-}"

echo "cfg gateway.auth.token $(printf %s "$AUTH" | sha256sum | cut -d' ' -f1)"
echo "cfg gateway.remote.token $(printf %s "$REMOTE"| sha256sum | cut -d' ' -f1)"
echo "svc OPENCLAW_GATEWAY_TOKEN $(printf %s "$SVC" | sha256sum | cut -d' ' -f1)"
echo "shell OPENCLAW_GATEWAY_TOKEN $(printf %s "$SHELL_TOKEN" | sha256sum | cut -d' ' -f1)"

Fastest fix: set ONE fresh token everywhere (service + config + shell)

This eliminates “mystery override” issues in one go:

#

TOKEN="$(openssl rand -hex 32)"

openclaw config set gateway.auth.token "$TOKEN"
openclaw config set gateway.remote.token "$TOKEN"

mkdir -p ~/.config/systemd/user/openclaw-gateway.service.d
cat > ~/.config/systemd/user/openclaw-gateway.service.d/override-token.conf <<EOF
[Service]
Environment=OPENCLAW_GATEWAY_TOKEN=$TOKEN
EOF

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

export OPENCLAW_GATEWAY_TOKEN="$TOKEN"

#

openclaw gateway status

After this, openclaw gateway status should show RPC probe: ok.

If it still doesn’t, paste:

the 4 SHA hashes from the first block
and the full openclaw gateway status output

and I’ll point to the exact remaining mismatch.

tender egret Feb 14, 2026, 12:10 AM

#

root@Gilbotron6900:~# systemctl --user show openclaw-gateway.service -p Environment --value
| tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN || echo "NO OPENCLAW_GATEWAY_TOKEN"
OPENCLAW_GATEWAY_TOKEN=db2d311763...

root@Gilbotron6900:~# openclaw config get gateway.mode
openclaw config get gateway.remote.url
openclaw config get gateway.remote.token

🦞 OpenClaw 2026.2.9 (33c75cb) — Your messages, your servers, your control.

local

🦞 OpenClaw 2026.2.9 (33c75cb) — I don't judge, but your missing API keys are absolutely judging you.

Config path not found: gateway.remote.url

🦞 OpenClaw 2026.2.9 (33c75cb) — Shell yeah—I'm here to pinch the toil and leave you the glory.

db2d311763...

#

root@Gilbotron6900:~# systemctl --user restart openclaw-gateway.service
openclaw gateway status

🦞 OpenClaw 2026.2.9 (33c75cb) — Siri's competent cousin.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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 147451, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json

Gateway port 18789 is not listening (service appears running).
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 14, 2026, 12:10 AM

#

Good news: that output is no longer a token mismatch. Now it’s a different failure mode:

systemd thinks the service is running (pid 147451)
but nothing is actually listening on 18789
the probe gets a 1006 because the WS can’t stay up (likely the gateway is crashing early or never binding)

We need the journal + a port check to see why it isn’t binding.

Run these as root and paste the output:

# is *anything* listening on the gateway port?
ss -lptn 'sport = :18789' || true

# show the real service state + last logs (this will contain the reason)
systemctl --user status openclaw-gateway.service --no-pager -l

#

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

If you want the fastest capture, do this sequence:

systemctl --user restart openclaw-gateway.service
sleep 1
ss -lptn 'sport = :18789' || true
journalctl --user -u openclaw-gateway.service -n 80 --no-pager

Also, since you previously had a “rescue” unit: please include this too:

#

systemctl --user list-units --all | rg 'openclaw-gateway' || true

Once I see the journal error line (it’s usually “port already in use”, “config parse error”, or “refusing to start because …”), I can tell you the exact next command to fix it.

#

Nice — token side looks consistent now:

OPENCLAW_GATEWAY_TOKEN is set (db2d…)
gateway.mode is local
gateway.remote.token is also db2d…
gateway.remote.url is unset (good)

Two things to do next:

1) Also make sure `gateway.auth.token` matches (so CLI + service can’t diverge later)

(You can redact the value, just confirm it’s the same db2d….)

openclaw config get gateway.auth.token

If it’s different, set it to match the env token:

#

SVC_TOKEN="$(
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p'
)"
openclaw config set gateway.auth.token "$SVC_TOKEN"
openclaw config set gateway.remote.token "$SVC_TOKEN"

2) Your current failure is “port not listening”, so we need the journal

Right now gateway status is failing because the gateway is not actually binding to 18789 (or it’s crashing right after start). The journal will say why.

Run and paste output:

systemctl --user restart openclaw-gateway.service
sleep 1

#


ss -lptn 'sport = :18789' || true

systemctl --user status openclaw-gateway.service --no-pager -l
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Also paste this (it helps spot “two processes” situations instantly):

systemctl --user show openclaw-gateway.service -p MainPID --value
ps -fp "$(systemctl --user show openclaw-gateway.service -p MainPID --value)"

Once I see the journal error line (it’ll be something like “port in use”, “config parse”, “permission”, etc.), I can give you the exact one-line fix.

tender egret Feb 14, 2026, 12:15 AM

#

root@Gilbotron6900:~# ss -lptn 'sport = :18789' || true
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=147692,fd=22))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=147692,fd=23))
root@Gilbotron6900:~# systemctl --user status openclaw-gateway.service --no-pager -l
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
● openclaw-gateway.service - OpenClaw Gateway (v2026.2.9)
Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Drop-In: /root/.config/systemd/user/openclaw-gateway.service.d
└─override-token.conf
Active: active (running) since Sat 2026-02-14 00:14:01 UTC; 23s ago
Main PID: 147692 (openclaw-gatewa)
Tasks: 11 (limit: 4653)
Memory: 356.8M (peak: 357.7M)
CPU: 10.998s
CGroup: /user.slice/user-0.slice/user@0.service/app.slice/openclaw-gateway.service
└─147692 openclaw-gateway

Feb 14 00:14:09 Gilbotron6900 node[147692]: 2026-02-14T00:14:09.135Z [gateway] listening on ws://[::1]:18789
Feb 14 00:14:09 Gilbotron6900 node[147692]: 2026-02-14T00:14:09.139Z [gateway] log file: /tmp/openclaw/openclaw-2026-02-14.log
Feb 14 00:14:09 Gilbotron6900 node[147692]: 2026-02-14T00:14:09.151Z [browser/service] Browser control service ready (profiles=2)
Feb 14 00:14:09 Gilbotron6900 node[147692]: 2026-02-14T00:14:09.818Z Registered hook: boot-md -> gateway:startup
Feb 14 00:14:09 Gilbotron6900 node[147692]: 2026-02-14T00:14:09.855Z Registered hook: command-logger -> command
Feb 14 00:14:09 Gilbotron6900 node[147692]: 2026-02-14T00:14:09.869Z Registered hook: session-memory -> command:new

knotty micaBOT Feb 14, 2026, 12:15 AM

#

That’s healthy now.

ss shows the gateway is listening on 18789 (pid 147692)
journal shows: [gateway] listening on ws://[::1]:18789
browser service ready, hooks registered — no crash loop

So the remaining thing is simply: does openclaw gateway status now succeed with RPC probe: ok?

Run:

openclaw gateway status

If it still says token mismatch, the last mismatch would be gateway.auth.token in config (not just gateway.remote.token). Check:

#

openclaw config get gateway.auth.token
openclaw config get gateway.remote.token
systemctl --user show openclaw-gateway.service -p Environment --value | tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN

All three should be the same value (at least same prefix like db2d…).

If openclaw gateway status is now clean: you’re done.
If it’s clean, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

tender egret Feb 14, 2026, 12:16 AM

#

Feb 14 00:14:09 Gilbotron6900 node[147692]: 2026-02-14T00:14:09.874Z [hooks] loaded 3 internal hook handlers
Feb 14 00:14:11 Gilbotron6900 node[147692]: 2026-02-14T00:14:11.535Z [ws] Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
Feb 14 00:14:11 Gilbotron6900 node[147692]: 2026-02-14T00:14:11.568Z [ws] unauthorized conn=049255d7-78c6-49ab-8431-995023118e91 remote=::1 client=openclaw-control-ui webchat vdev reason=token_mismatch
Feb 14 00:14:11 Gilbotron6900 node[147692]: 2026-02-14T00:14:11.606Z [ws] closed before connect conn=049255d7-78c6-49ab-8431-995023118e91 remote=::1 fwd=193.187.130.232 origin=https://164.92.159.153 host=164.92.159.153 ua=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 code=4008 reason=connect failed
Feb 14 00:05:21 Gilbotron6900 systemd[934]: Stopping openclaw-gateway.service - OpenClaw Gateway (v2026.2.9)...
Feb 14 00:05:21 Gilbotron6900 node[146973]: 2026-02-14T00:05:21.865Z [gateway] signal SIGTERM received
Feb 14 00:05:21 Gilbotron6900 node[146973]: 2026-02-14T00:05:21.867Z [gateway] received SIGTERM; shutting down
Feb 14 00:05:21 Gilbotron6900 node[146973]: 2026-02-14T00:05:21.877Z [gmail-watcher] gmail watcher stopped
Feb 14 00:05:23 Gilbotron6900 systemd[934]: Stopped openclaw-gateway.service - OpenClaw Gateway (v2026.2.9).
Feb 14 00:05:23 Gilbotron6900 systemd[934]: openclaw-gateway.service: Consumed 13.523s CPU time, 358.8M memory peak, 0B memory swap peak.
Feb 14 00:05:23 Gilbotron6900 systemd[934]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.2.9).
Feb 14 00:05:31 Gilbotron6900 node[147245]: 2026-02-14T00:05:31.342Z [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /root/.openclaw/canvas)

#

the log is huge. which part do you require?

knotty micaBOT Feb 14, 2026, 12:18 AM

#

Those log lines are not the gateway/CLI fighting anymore — they’re the Control UI in your browser connecting and getting rejected:

client=openclaw-control-ui webchat ... reason=token_mismatch
plus: Proxy headers detected from untrusted address... (because you’re accessing it via a reverse proxy at https://164.92.159.153).

1) Fix the Control UI token (this is the actual “token_mismatch” now)

The Control UI stores its token in your browser localStorage (openclaw.control.settings.v1). It’s currently sending an old/wrong token.

Do this on the gateway host to print the correct token:

openclaw config get gateway.auth.token
# (or use the service env token you already saw: OPENCLAW_GATEWAY_TOKEN=db2d...)

Then in the browser at the same URL you use (https://164.92.159.153/):

open the Control UI settings (gear icon)
paste that token into the auth/token field (connect.params.auth.token)

#

reload

If you can’t find the setting, the “nuke from orbit” fix is: open DevTools → Console and run:

localStorage.removeItem("openclaw.control.settings.v1"); location.reload();

Then re-enter the token.

Important: tokens are saved per origin. So http://127.0.0.1:18789/ and https://164.92.159.153/ each have their own stored token.

2) Fix the reverse proxy warning (recommended)

Because you’re proxying to a loopback-bound gateway, add the proxy as trusted so OpenClaw can safely honor X-Forwarded-For and treat clients correctly:

If your proxy runs on the same host (your logs show remote=::1), do:

openclaw config set gateway.trustedProxies '["127.0.0.1","::1"]' --json

#

systemctl --user restart openclaw-gateway.service

(Also make sure your proxy overwrites X-Forwarded-For instead of appending.)

Quick confirmation

After updating the Control UI token, your gateway log should stop showing reason=token_mismatch, and the UI should connect.

Docs that match your exact symptoms:

#

Don’t send the whole log.

Given what we saw, I only need the 20–30 lines around the failure (and you already have the key ones).

If your problem is: “Control UI / browser says unauthorized / keeps reconnecting”

I don’t need more logs. The fix is on the browser side:

On the server, get the current token:

openclaw config get gateway.auth.token

In the Control UI (at the exact URL you’re using, e.g. https://164.92.159.153/), open Settings and paste that token.

If you can’t access Settings, paste this output (no secrets):

#

openclaw config get gateway.auth.token | head -c 6; echo "...(redacted)"

If your problem is still: “`openclaw gateway status` fails”

Then paste just:

openclaw gateway status
ss -lptn 'sport = :18789'

If you want the “why is proxy untrusted” bit fixed

Paste only this (it’s short):

openclaw config get gateway.trustedProxies

#

If you tell me which of the three symptoms you’re seeing (UI unauthorized vs CLI status unauthorized vs something else), I’ll tell you exactly which snippet to paste.

tender egret Feb 14, 2026, 12:22 AM

#

OpenClaw 2026.2.9 (33c75cb) — I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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 147998, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 147998 root: 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 14, 2026, 12:23 AM

#

This is back to the CLI ↔ gateway token mismatch (not the huge log / not the proxy warning).

Right now we need to answer one question: which token is the gateway actually expecting (service env) vs which token the CLI is sending (config).

Run this on the server as root and paste the output (it prints only SHA256 hashes, no secrets):

AUTH="$(openclaw config get gateway.auth.token | tr -d '\n')"
REMOTE="$(openclaw config get gateway.remote.token | tr -d '\n')"
SVC="$(
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p' | tr -d '\n'
)"

echo "cfg gateway.auth.token $(printf %s "$AUTH" | sha256sum | cut -d' ' -f1)"
echo "cfg gateway.remote.token $(printf %s "$REMOTE"| sha256sum | cut -d' ' -f1)"

#

echo "svc OPENCLAW_GATEWAY_TOKEN $(printf %s "$SVC" | sha256sum | cut -d' ' -f1)"

Fast fix (once we confirm which one differs)

If the service token is the “truth” (common on systemd), just force config to match it:

SVC_TOKEN="$(
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p'
)"

openclaw config set gateway.auth.token "$SVC_TOKEN"
openclaw config set gateway.remote.token "$SVC_TOKEN"
systemctl --user restart openclaw-gateway.service

#

openclaw gateway status

(If it’s the other way around—config is correct and the service env is stale—we’ll instead rewrite the drop-in override-token.conf to match config.)

Paste the three hashes and I’ll tell you exactly which value is out of sync.

tender egret Feb 14, 2026, 12:41 AM

#

those 3 hashes show the same value but i am still getting this error:

OpenClaw 2026.2.9 (33c75cb) — If you can describe it, I can probably automate it—or at least make it funnier.

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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 148293, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 148293 root: 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 14, 2026, 12:47 AM

#

Those “3 hashes match but openclaw gateway status still says token mismatch” is explainable (and it’s a bit subtle):

What’s happening

Your running gateway is using the token from systemd including drop-ins (systemctl --user show … sees that).
But openclaw gateway status (the CLI) determines what token to probe with by parsing the main unit file ~/.config/systemd/user/openclaw-gateway.service — and it does not read the drop-in overrides (…/openclaw-gateway.service.d/*.conf).

So if your “real” token lives in the drop-in (override-token.conf) but the main unit file still contains an old Environment=OPENCLAW_GATEWAY_TOKEN=..., the CLI will probe with the old one and get rejected.

Fix: make the main unit file token match the real token

Get the effective token systemd is using (don’t paste it):

SVC_TOKEN="$(
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p'
)"

#

Write that token into the main unit file (console-only):

UNIT="$HOME/.config/systemd/user/openclaw-gateway.service"

# replace existing line if present, otherwise append it
if rg -q '^Environment=OPENCLAW_GATEWAY_TOKEN=' "$UNIT"; then
sed -i "s/^Environment=OPENCLAW_GATEWAY_TOKEN=.*/Environment=OPENCLAW_GATEWAY_TOKEN=$SVC_TOKEN/" "$UNIT"
else
printf '\nEnvironment=OPENCLAW_GATEWAY_TOKEN=%s\n' "$SVC_TOKEN" >> "$UNIT"
fi

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

After that, openclaw gateway status should stop complaining and show RPC probe: ok.

#

Quick verification (no secrets)

Show what the main unit file contains vs what systemd is using:

rg '^Environment=OPENCLAW_GATEWAY_TOKEN=' ~/.config/systemd/user/openclaw-gateway.service
systemctl --user show openclaw-gateway.service -p Environment --value | tr ' ' '\n' | rg OPENCLAW_GATEWAY_TOKEN

If you want, paste those two outputs with the token value redacted (keep just the prefixes) and I’ll confirm it’s aligned.

tender egret Feb 14, 2026, 12:56 AM

#

openclaw gateway status shows everything running ok, but i can't speak to openclaw via console tui and also shows "disconnected (1008): pairing required " at https://164.92.159.153/overview

knotty micaBOT Feb 14, 2026, 12:57 AM

#

disconnected (1008): pairing required is a different gate than the gateway token: your Gateway is up, but the browser Control UI / TUI is a new “device” and needs a one-time approval.

Fix: approve the device pairing request

On the gateway host (where openclaw gateway status works), run:

openclaw devices list

You should see one or more pending requests (usually shows displayName/platform/client).

Approve it:

openclaw devices approve <requestId>

#

Then refresh https://164.92.159.153/overview and restart the console TUI client.

Docs (this exact error): https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection
Devices CLI: https://docs.openclaw.ai/cli/devices

Optional but recommended (because you’re behind a reverse proxy)

You also had: “Proxy headers detected from untrusted address…”. If your proxy is on the same box (your logs showed remote=::1), trust it:

openclaw config set gateway.trustedProxies '["127.0.0.1","::1"]' --json
systemctl --user restart openclaw-gateway.service

This doesn’t replace pairing, but it fixes local/remote detection behind the proxy.

#

If openclaw devices list shows no pending requests, paste its output (it doesn’t include secrets) and we’ll see whether the UI is hitting a different gateway/profile.

tender egret Feb 14, 2026, 1:03 AM

#

ermmm its finally working but my openclaw has no memory of me?

knotty micaBOT Feb 14, 2026, 1:05 AM

#

That usually means you’re now running the Gateway under a different state dir / OS user / profile than before, so it’s looking at an empty sessions store.

OpenClaw’s “memory” (chat history + sessions) lives on disk under:

$OPENCLAW_STATE_DIR (default: ~/.openclaw)
specifically: $OPENCLAW_STATE_DIR/agents/<agentId>/sessions/

In your debugging we ended up running the gateway as root (HOME=/root), so your state dir is very likely /root/.openclaw now — while your old history might be in /home/openclaw/.openclaw (or your normal user’s home).

Quick check: where is the old history?

Run these and paste the output:

ls -la /root/.openclaw/agents 2>/dev/null | head
ls -la /home/openclaw/.openclaw/agents 2>/dev/null | head

#

find /root/.openclaw -path '*/sessions/*.jsonl' 2>/dev/null | wc -l
find /home/openclaw/.openclaw -path '*/sessions/*.jsonl' 2>/dev/null | wc -l

How to “get memory back”

Whichever path has the big *.jsonl count is where your old sessions are. Then you have two options:

Run the Gateway under that same user/state dir (recommended), or
Point your current service at the old state dir by setting OPENCLAW_STATE_DIR (and restarting the service).

Once you show me which directory has the sessions, I’ll give you the exact one-liner to switch the systemd unit over cleanly (without re-breaking tokens again).

tender egret Feb 14, 2026, 1:07 AM

#

root@Gilbotron6900:~# ls -la /root/.openclaw/agents 2>/dev/null | head
ls -la /home/openclaw/.openclaw/agents 2>/dev/null | head
total 12
drwxr-xr-x 3 root root 4096 Feb 12 07:06 .
drwx------ 13 root root 4096 Feb 14 00:31 ..
drwxr-xr-x 4 root root 4096 Feb 12 07:59 main
total 12
drwxr-xr-x 3 openclaw openclaw 4096 Feb 11 12:45 .
drwx------ 9 openclaw openclaw 4096 Feb 12 18:51 ..
drwxr-xr-x 3 openclaw openclaw 4096 Feb 11 12:45 main

root@Gilbotron6900:~# find /root/.openclaw -path '/sessions/.jsonl' 2>/dev/null | wc -l
find /home/openclaw/.openclaw -path '/sessions/.jsonl' 2>/dev/null | wc -l
2
18

knotty micaBOT Feb 14, 2026, 1:07 AM

#

There it is: your “real” history is under the openclaw user, not root.

/root/.openclaw/... has 2 session jsonl files
/home/openclaw/.openclaw/... has 18 session jsonl files ← this is the memory you want back

Right now the gateway service you fixed is running as root, so it’s reading /root/.openclaw and looks “new”.

Best fix: run the gateway as the `openclaw` user again

On Linux, a systemd user service always runs as that user. So you want the gateway service under openclaw’s systemd --user, not root’s.

1) Stop/disable the root user service

(as root)

systemctl --user disable --now openclaw-gateway.service

2) Switch to the openclaw account and start the user service there

#

(as root)

su - openclaw
whoami
echo $HOME
systemctl --user enable --now openclaw-gateway.service
openclaw gateway status

If systemctl --user ... fails under su - openclaw (common if linger isn’t enabled), enable linger once:

exit # back to root
loginctl enable-linger openclaw
su - openclaw
systemctl --user enable --now openclaw-gateway.service

#

3) Update your proxy/UI token

When you switch users, the gateway token may also switch (because it’ll read /home/openclaw/.openclaw/openclaw.json + that service’s env). If the Control UI says unauthorized again, just paste the new token into the UI settings.

If you want, paste the output of this (run as openclaw after su - openclaw):

systemctl --user status openclaw-gateway.service --no-pager
openclaw gateway status

Once it’s running under openclaw, your old sessions/memory should show up again.

tender egret Feb 14, 2026, 1:09 AM

#

root@Gilbotron6900:~# systemctl --user disable --now openclaw-gateway.service
Removed "/root/.config/systemd/user/default.target.wants/openclaw-gateway.service".
root@Gilbotron6900:~# su - openclaw
whoami
echo $HOME
systemctl --user enable --now openclaw-gateway.service
openclaw gateway status
openclaw@Gilbotron6900:~$ systemctl --user status openclaw-gateway.service --no-pager
openclaw gateway status
Failed to connect to bus: No medium found

🦞 OpenClaw 2026.2.9 (33c75cb) — If it works, it's automation; if it breaks, it's a "learning opportunity."

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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 (Error: systemctl --user unavailable: Failed to connect to bus: No medium found)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /home/openclaw/.openclaw/openclaw.json

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 14, 2026, 1:12 AM

#

Yep — that “no memory of me” is because you ended up running the Gateway as root, so it’s using /root/.openclaw (which only had 2 session files). Your real history is under the openclaw user:

/home/openclaw/.openclaw/... has 18 session .jsonl files

So we need the Gateway to run using /home/openclaw/.openclaw again.

Fix: get systemd user services working for the `openclaw` user (headless-safe)

Your su - openclaw failed with Failed to connect to bus: No medium found because there’s no user systemd instance running for that user yet.

Run this as root:

# 1) Make sure root's gateway user-service is stopped so it doesn't steal the port
systemctl --user disable --now openclaw-gateway.service || true

# 2) Enable lingering so openclaw gets a user systemd even without a login session

#

loginctl enable-linger openclaw

# 3) Start the openclaw user manager
UID_OPENCLAW="$(id -u openclaw)"
systemctl start "user@${UID_OPENCLAW}.service"

# 4) Now systemctl --user should work for openclaw if we point XDG_RUNTIME_DIR correctly
sudo -u openclaw XDG_RUNTIME_DIR="/run/user/${UID_OPENCLAW}" systemctl --user status --no-pager

If that last command works (no “No medium found”), start the gateway service as the openclaw user:

sudo -u openclaw XDG_RUNTIME_DIR="/run/user/${UID_OPENCLAW}" systemctl --user enable --now openclaw-gateway.service
sudo -u openclaw openclaw gateway status

#

At that point the Gateway will be using /home/openclaw/.openclaw again, and your sessions/memory should reappear.

One more thing you’ll likely see again: “pairing required”

When you switch back to the openclaw state dir, the device pairing database also switches, so the Control UI / TUI may need re-approval once:

sudo -u openclaw openclaw devices list
sudo -u openclaw openclaw devices approve <requestId>

If any step errors, paste only:

the exact error line(s)
output of: systemctl status user@$(id -u openclaw).service --no-pager

tender egret Feb 14, 2026, 1:17 AM

#

root@Gilbotron6900:~# sudo -u openclaw XDG_RUNTIME_DIR="/run/user/${UID_OPENCLAW}" systemctl --user status --no-pager
● Gilbotron6900
State: running
Units: 159 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 0 units
Since: Sat 2026-02-14 01:15:43 UTC; 26s ago
systemd: 255.4-1ubuntu8.12
CGroup: /user.slice/user-1000.slice/user@1000.service
└─init.scope
├─149427 /usr/lib/systemd/systemd --user
└─149428 "(sd-pam)"
root@Gilbotron6900:~# sudo -u openclaw XDG_RUNTIME_DIR="/run/user/${UID_OPENCLAW}" systemctl --user enable --now openclaw-gateway.service
sudo -u openclaw openclaw gateway status
Failed to enable unit: Unit file openclaw-gateway.service does not exist.

#

OpenClaw 2026.2.9 (33c75cb) — Your inbox, your infra, your rules.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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 (Error: systemctl --user unavailable: Failed to connect to bus: No medium found)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /home/openclaw/.openclaw/openclaw.json

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 14, 2026, 1:17 AM

#

Great — systemd --user is now working for the openclaw user. The only remaining issue is simply: the OpenClaw gateway user-service was never installed for that user, so openclaw-gateway.service doesn’t exist in /home/openclaw/.config/systemd/user/.

0) Make sure the root gateway isn’t still holding the port

Run as root:

ss -lptn 'sport = :18789' || true

If you see an openclaw-gateway PID there (owned by root), stop it first:

systemctl --user stop openclaw-gateway.service || true
pkill -f 'openclaw-gateway' || true

1) Install the gateway service as the openclaw user

Run as root (this writes the unit into /home/openclaw/.config/systemd/user/ and enables it):

#

UID_OPENCLAW="$(id -u openclaw)"

sudo -u openclaw -H XDG_RUNTIME_DIR="/run/user/${UID_OPENCLAW}" \
openclaw gateway install --force --port 18789

2) Start it + verify it’s using the openclaw state dir (your “memory”)

sudo -u openclaw -H XDG_RUNTIME_DIR="/run/user/${UID_OPENCLAW}" \
systemctl --user restart openclaw-gateway.service

sudo -u openclaw -H openclaw gateway status

At this point the gateway should be running with Config: /home/openclaw/.openclaw/openclaw.json and your old sessions should be back.

#

3) If the web UI says “pairing required” again

That’s normal after switching which state dir is active. Approve it once:

sudo -u openclaw -H openclaw devices list
sudo -u openclaw -H openclaw devices approve <requestId>

If gateway install fails, paste the exact error line and:

sudo -u openclaw -H ls -la /home/openclaw/.config/systemd/user | head
sudo -u openclaw -H which openclaw

#

That output is happening because you’re running openclaw gateway status as the openclaw user without a working systemd user D-Bus environment (so systemctl --user … can’t talk to the user manager → “No medium found”).

You already proved the user manager exists (user@1000.service is running). Now you just need to run OpenClaw with the same env that lets systemctl --user connect.

Run OpenClaw as `openclaw` with the correct env (headless-safe)

As root:

UID_OPENCLAW="$(id -u openclaw)"
XDG_RUNTIME_DIR="/run/user/${UID_OPENCLAW}"
DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

# sanity check: bus socket should exist
ls -la "${XDG_RUNTIME_DIR}/bus"

# now run openclaw commands with that env

#

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR" \
DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" \
openclaw gateway status

Install + start the gateway service for the openclaw user (to get your memory back)

(You previously hit “unit file … does not exist”, so we need to install it under /home/openclaw/.config/systemd/user/.)

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR" \
DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" \
openclaw gateway install --force --port 18789

#

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR" \
DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" \
systemctl --user enable --now openclaw-gateway.service

Then verify (this should show config under /home/openclaw/.openclaw/... and your sessions/memory should be back):

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR" \
DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" \
openclaw gateway status

If ls -la /run/user/1000/bus fails (bus socket missing), paste that error +:

#

systemctl status "user@${UID_OPENCLAW}.service" --no-pager

tender egret Feb 14, 2026, 1:34 AM

#

root@Gilbotron6900:~# sudo -u openclaw -H env
XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR"
DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS"
openclaw gateway install --force --port 18789

🦞 OpenClaw 2026.2.9 (33c75cb) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to bus: Permission denied

knotty micaBOT Feb 14, 2026, 1:34 AM

#

That “Failed to connect to bus: Permission denied” is almost certainly because your sudo -u openclaw … command is still pointing at root’s D-Bus (/run/user/0/bus) instead of openclaw’s (/run/user/1000/bus). In your pasted command you’re passing:

XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR"
DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS"

…but in your root shell those vars are either empty or set for UID 0.

Run this exactly (copy/paste) as root:

UID_OPENCLAW="$(id -u openclaw)"
echo "UID_OPENCLAW=$UID_OPENCLAW"

# sanity check: openclaw's bus should exist and be owned by openclaw
ls -la "/run/user/$UID_OPENCLAW" | head
ls -la "/run/user/$UID_OPENCLAW/bus"

#


# prove systemctl --user works for openclaw when pointed at the right bus
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user status --no-pager

If that works, then install the gateway service for the openclaw user:

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw gateway install --force --port 18789

#

If the ls -la /run/user/$UID_OPENCLAW/bus command fails or shows weird perms, paste that output and also:

systemctl status "user@${UID_OPENCLAW}.service" --no-pager

tender egret Feb 14, 2026, 1:39 AM

#

root@Gilbotron6900:~# sudo -u openclaw -H env
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW"
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus"
systemctl --user status --no-pager
● Gilbotron6900
State: running
Units: 161 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 0 units
Since: Sat 2026-02-14 01:15:43 UTC; 22min ago
systemd: 255.4-1ubuntu8.12
CGroup: /user.slice/user-1000.slice/user@1000.service
├─app.slice
│ └─openclaw-gateway.service
│ └─149845 openclaw-gateway
└─init.scope
├─149427 /usr/lib/systemd/systemd --user
└─149428 "(sd-pam)"
root@Gilbotron6900:~# sudo -u openclaw -H env
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW"
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus"
openclaw gateway install --force --port 18789

🦞 OpenClaw 2026.2.9 (33c75cb) — Less middlemen, more messages.

Gateway service already enabled.
Reinstall with: openclaw gateway install --force

wait for more...

#

OpenClaw 2026.2.9 (33c75cb) — IPC, but it's your phone.

│
gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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: stopped (state inactive, sub dead, last exit 0, reason 0)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
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: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 149845 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
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

knotty micaBOT Feb 14, 2026, 1:40 AM

#

Nice — you’re past the hard part.

That output means:

systemctl --user for openclaw works (good bus env)
openclaw-gateway.service is already running under openclaw (pid 149845)
and the gateway service is already enabled/installed (so you don’t need to reinstall)

So now you should have your “memory” back, because this gateway instance will use /home/openclaw/.openclaw/....

Verify it’s the right state dir + that sessions exist

Run (as openclaw, via sudo with the same env):

UID_OPENCLAW="$(id -u openclaw)"

#

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw gateway status

In the output, confirm it says:

Config: /home/openclaw/.openclaw/openclaw.json (or similar)

And check the sessions count quickly:

sudo -u openclaw -H find /home/openclaw/.openclaw -path '*/sessions/*.jsonl' | wc -l

If the UI/TUI says “pairing required” again

That’s expected after switching back to the openclaw state dir. Approve once:

#

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw devices list

Then:

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw devices approve <requestId>

When you say “wait for more…”: there shouldn’t be more — you’re basically done. What’s the current symptom now: “memory still missing”, Control UI disconnected, or TUI not connecting?

#

You’re accidentally running the CLI as root, so it’s using /root/.openclaw/openclaw.json (wrong token + empty-ish session store). Meanwhile the actual gateway that’s listening on :18789 is running as the openclaw user (pid 149845), using /home/openclaw/.openclaw/ (your real “memory”).

That’s why you see:

Config: /root/.openclaw/openclaw.json (CLI)
listener is openclaw: openclaw-gateway (Gateway)

Use the openclaw user for all OpenClaw commands (recommended)

Run as root, but execute OpenClaw as openclaw with the correct user-bus env:

UID_OPENCLAW="$(id -u openclaw)"

oc() {
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \

#

DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw "$@"
}

oc gateway status
oc tui

That should connect cleanly and you’ll see your old sessions again.

If you insist on running the CLI as root

Then you must explicitly pass the token that the openclaw gateway expects:

TOKEN="$(sudo -u openclaw -H openclaw config get gateway.auth.token | tr -d '\n')"

#

openclaw gateway status --url ws://127.0.0.1:18789 --token "$TOKEN"

…but I’d avoid this, because it keeps mixing “root config” with “openclaw gateway”.

Tell me: after running oc tui, do you see your prior session/history?

tender egret Feb 14, 2026, 1:44 AM

#

root@Gilbotron6900:~# sudo -u openclaw -H env
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW"
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus"
openclaw gateway status

🦞 OpenClaw 2026.2.9 (33c75cb) — Your .env is showing; don't worry, I'll pretend I didn't see it.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.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 149845, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@Gilbotron6900:~# sudo -u openclaw -H find /home/openclaw/.openclaw -path '/sessions/.jsonl' | wc -l
find: Failed to restore initial working directory: /root: Permission denied
18

knotty micaBOT Feb 14, 2026, 1:45 AM

#

Nice — you’re back in a good state now:

Gateway is running as openclaw (pid 149845)
RPC probe is ok
/home/openclaw/.openclaw has 18 session .jsonl files → your history is there.

That find: Failed to restore initial working directory: /root: Permission denied is harmless; it just means you ran sudo -u openclaw … while your current directory was /root. Fix by doing cd / first, or run via a login shell:

sudo -u openclaw -H bash -lc 'find ~/.openclaw -path "*/sessions/*.jsonl" | wc -l'

“No memory of me” = you’re likely in a new session

The data exists, but your TUI/UI might be opening a fresh session key.

Run this to list sessions from the openclaw state store:

#

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw sessions --active 10080

Then in the TUI you can switch to the old session:

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw tui

#

In the TUI:

press Ctrl+P (session picker), or
type /sessions then /session <key>

One more common gotcha

If you previously chatted via the web Control UI at https://164.92.159.153, it may be a different “device/session” view (and it may require device pairing once). If it says pairing required:

sudo -u openclaw -H bash -lc 'openclaw devices list'
sudo -u openclaw -H bash -lc 'openclaw devices approve <requestId>'

Tell me: when you run openclaw sessions --active 10080, do you see your older session(s) listed? If yes, I’ll tell you exactly which /session ... to jump to.

tender egret Feb 14, 2026, 1:47 AM

#

root@Gilbotron6900:~# sudo -u openclaw -H bash -lc 'find ~/.openclaw -path "/sessions/.jsonl" | wc -l'
find: Failed to restore initial working directory: /root: Permission denied
18

my dashboard also shows disconnected (1008): unauthorized: gateway token mismatch (open the dashboard URL and paste the token in Control UI settings)

knotty micaBOT Feb 14, 2026, 1:47 AM

#

You’re basically there. Two separate things:

1) That `find: Failed to restore initial working directory: /root: Permission denied`

Harmless — it happens because the command starts in /root and then drops privileges to openclaw.

Just cd somewhere readable inside the subshell:

sudo -u openclaw -H bash -lc 'cd ~; find ~/.openclaw -path "*/sessions/*.jsonl" | wc -l'

2) Dashboard: `disconnected (1008): unauthorized: gateway token mismatch`

That means the browser Control UI still has the OLD token saved (localStorage), but your gateway is now using a different token (you changed it during the fix / switched users).

Get the CURRENT token (don’t paste it here)

Run on the server:

#

sudo -u openclaw -H bash -lc 'openclaw config get gateway.auth.token'

(or if you prefer the systemd env token that the service is using:)

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user show openclaw-gateway.service -p Environment --value | tr " " "\n" | rg OPENCLAW_GATEWAY_TOKEN

Paste it into the Control UI settings

Open your dashboard at https://164.92.159.153/ → click the gear / Settings → paste the token into the token field (it’s sent as connect.params.auth.token) → reconnect/refresh.

If the UI won’t “forget” the old token, nuke it from the browser:

DevTools → Console:

#

localStorage.removeItem("openclaw.control.settings.v1"); location.reload();

Important: tokens are stored per origin, so http://127.0.0.1:18789/ and https://164.92.159.153/ each need their own token set.

If after updating the token it switches to “pairing required”, that’s the next (normal) step and you’ll just approve the device once with openclaw devices list / openclaw devices approve <requestId>.

tender egret Feb 14, 2026, 1:51 AM

#

ok the gateway and dashboard seem to be working/connected, but my openclaw is not responding (stuck on "...")

knotty micaBOT Feb 14, 2026, 1:52 AM

#

If the dashboard is connected but a chat message just sits on “…” forever, the next step is: look at the Gateway logs while you send one message. That will tell us whether it’s (a) model/auth, (b) routing/session stuck, or (c) a crash.

Run this on the server (as root, but executing the CLI as the openclaw user):

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw logs --follow

Then, while that’s running, send a short message from the dashboard (e.g. “ping”), wait ~10 seconds, and paste the first error stack / warning lines that appear in the logs right after you hit send (usually ~10–30 lines).

Also answer one thing: is the “…” happening in the web dashboard chat, or in the console TUI?

If the logs show model/auth issues, we’ll likely fix it with:

#

sudo -u openclaw -H openclaw models status --probe --plain

…but let’s see the log error first so we don’t guess.

tender egret Feb 14, 2026, 1:55 AM

#

that log request finished with logs from over an hours ago and gave: Log tail truncated (increase --max-bytes).

knotty micaBOT Feb 14, 2026, 1:56 AM

#

“Log tail truncated (increase --max-bytes)” isn’t an error — it just means the initial chunk was big, so it clipped the backlog. For the “stuck on …” issue, we need a live tail while you click send, so we capture the new error lines.

Run this (as the openclaw user, so tokens/config match the running gateway):

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw logs --follow --limit 80 --max-bytes 2000000

Leave that running, then in the dashboard send a short message like ping. Wait ~10s and paste the next ~30 lines that appear after you hit send.

Also run this in another terminal and paste the output (it’s usually the culprit when responses hang):

#

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw models status --probe --plain

While we’re debugging: if the UI has a Stop/Abort button, click it once to cancel the stuck run, then try ping again.

tender egret Feb 14, 2026, 1:59 AM

#

root@Gilbotron6900:~# UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW"
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus"
openclaw logs --follow --limit 80 --max-bytes 2000000

🦞 OpenClaw 2026.2.9 (33c75cb) — Automation with claws: minimal fuss, maximal pinch.

Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/openclaw/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.

#

sudo -u openclaw -H env
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW"
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus"
openclaw models status --probe --plain

#

root@Gilbotron6900:~# su openclaw
openclaw@Gilbotron6900:/root$ UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW"
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus"
openclaw logs --follow --limit 80 --max-bytes 2000000
openclaw is not in the sudoers file.

knotty micaBOT Feb 14, 2026, 2:00 AM

#

“Stuck on …” almost always means the Gateway accepted the message, but the agent run is stalled (model/auth error, tool hang, or it’s waiting on something) — we need the error line that happens right after you hit send.

Two reliable ways to capture it:

Option A (best): tail the gateway file log locally (no RPC/auth needed)

Run this on the server:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
tail -n 80 -f "$LOG"

Then in the dashboard, send a short message (“ping”). Paste the next ~30 lines that appear after you hit send.

Option B: use `openclaw logs`, but show the real error

Your openclaw logs --follow printed “Gateway not reachable” but hid the underlying exception. Run it in JSON mode so it includes the error string:

#

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw logs --json --limit 5

If it fails, paste that JSON (it will include the actual reason).

Also run this (very common culprit)

If the model provider auth is broken/expired, runs can hang or instantly error:

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \

#

XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
openclaw models status --probe --plain

One clarifier: is the “…” happening in the dashboard chat UI, or are you expecting replies back in Discord/Telegram/etc? The next step differs slightly.

#

When the dashboard is connected but replies are stuck on “…” the gateway is usually fine — it’s the agent run failing/hanging, and we need the live error line right after you hit send.

Also: openclaw gateway status can say “RPC probe: ok” even when openclaw logs says “Gateway not reachable”, because gateway status can use the token from the systemd service env, while openclaw logs won’t unless you pass the token explicitly.

1) Get the gateway token from the running service (don’t paste it)

Run as root:

UID_OPENCLAW="$(id -u openclaw)"
TOKEN="$(
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p'
)"

#

echo "token length: ${#TOKEN}"

2) Tail logs live while you send “ping”

Option A (simplest, no RPC/auth involved)

tail -n 200 -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Option B (RPC logs, but with explicit token)

sudo -u openclaw -H openclaw logs --follow --limit 80 --max-bytes 2000000 --token "$TOKEN"

Now send ping from the dashboard and paste the next ~30 lines that appear after you hit send.

#

3) Check model/provider auth (very common cause of “…”)

Run (and paste the output; it shouldn’t include your raw keys):

sudo -u openclaw -H openclaw models status --probe --plain

4) If a run is wedged, abort it once

From CLI (as openclaw):

sudo -u openclaw -H openclaw gateway call chat.abort --params '{"sessionKey":"main"}'

Tell me: is the “…” happening in the dashboard chat, or are you expecting a reply back in Discord/Telegram/etc?

tender egret Feb 14, 2026, 2:04 AM

#

nothing came up in the logs when i sent a ping message.

root@Gilbotron6900:~# sudo -u openclaw -H openclaw models status --probe --plain

🦞 OpenClaw 2026.2.9 (33c75cb) — Ship fast, log faster.

Error: --probe cannot be used with --plain output.
root@Gilbotron6900:~# sudo -u openclaw -H openclaw gateway call chat.abort --params '{"sessionKey":"main"}'

🦞 OpenClaw 2026.2.9 (33c75cb) — Greetings, Professor Falken

│
◇
Gateway call: chat.abort
{
"ok": true,
"aborted": false,
"runIds": []
}

knotty micaBOT Feb 14, 2026, 2:09 AM

#

If you sent “ping” in the dashboard and (a) nothing new showed up in logs, and (b) chat.abort says there are no active runs, then the key question is: did the message ever reach the Gateway (chat.send), or is the UI stuck client‑side?

Let’s check that directly (no guessing).

1) Did the Gateway receive your “ping” at all?

Run this before and after you click Send in the dashboard:

sudo -u openclaw -H openclaw gateway call chat.history --params '{"sessionKey":"main","limit":20}'

If your “ping” does not appear in the second output → the dashboard isn’t successfully calling chat.send (UI/proxy/WebSocket issue).
If it does appear but there’s no assistant reply after ~30–60s → the agent/model is failing/hanging.

2) Bypass the dashboard: can the Gateway run a chat turn from CLI?

This forces a chat.send directly:

#

ID="$(uuidgen | tr -d '\n')"
sudo -u openclaw -H openclaw gateway call chat.send --params "{\"sessionKey\":\"main\",\"message\":\"ping (from cli)\",\"idempotencyKey\":\"$ID\"}"
sleep 5
sudo -u openclaw -H openclaw gateway call chat.history --params '{"sessionKey":"main","limit":20}'

If this works (you eventually see an assistant message in history) → the backend is fine, the dashboard is the problem.
If this does not produce an assistant reply → it’s a model/provider/auth/config issue.

3) Check model/provider health (your command just had incompatible flags)

Run (no --plain when using --probe):

sudo -u openclaw -H openclaw models status --probe

#

Paste whatever errors it reports (missing/expired keys, provider failures, etc.).

If (1) shows the dashboard “ping” never reaches chat.history

Then it’s almost always the reverse proxy/WebSocket path or the dashboard JS is wedged. Quick checks:

try an incognito window (fresh localStorage)
open DevTools → Console and see if it logs any WS errors on send
confirm your proxy is forwarding WebSocket Upgrade properly (since Control UI uses WS for chat.send)

Reply with the result of (1) (does “ping” show up in chat.history?), and whether (2) works. That will narrow it to either “UI transport” or “model/runtime” immediately.

tender egret Feb 14, 2026, 2:13 AM

#

root@Gilbotron6900:~# sudo -u openclaw -H openclaw models status --probe

🦞 OpenClaw 2026.2.9 (33c75cb) — The only bot that stays out of your training set.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-3-5-sonnet-20241022
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-3-5-sonnet-20241022

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

Missing auth

anthropic Run claude setup-token, then openclaw models auth setup-token or openclaw configure.

OAuth/token status

none

Auth probes

none

knotty micaBOT Feb 14, 2026, 2:13 AM

#

There’s your “stuck on …” root cause: you have no model auth configured, so the agent can’t actually call Anthropic.

Key line:

Missing auth – anthropic
“Providers w/ OAuth/tokens (0)”

So the UI sends the message, the run can’t start properly, and you end up with “…” / no response.

Fix: add an Anthropic API key (token) to OpenClaw

You have a few ways; pick one.

Option A (recommended): interactive config wizard

sudo -u openclaw -H openclaw configure

Go to the models/auth section and add your Anthropic key.

#

Option B: add via models auth command

The output suggests:

claude setup-token
sudo -u openclaw -H openclaw models auth setup-token

(Follow the prompts; this stores it into ~/.openclaw/agents/main/agent/auth-profiles.json.)

Option C: put it in the gateway service environment (systemd)

If you prefer env vars, set ANTHROPIC_API_KEY for the openclaw user’s systemd service environment (not root), then restart the service. (I can give exact commands once you tell me whether you want “env var” or “auth profiles”.)

Verify

After adding the key:

sudo -u openclaw -H openclaw models status --probe

You should see an auth profile and an auth probe for anthropic.

#

Then try your dashboard “ping” again — it should respond.

If you want, tell me which option you prefer (wizard vs models auth vs env var) and whether this is a personal server or shared/multi-user box (security choice).

tender egret Feb 14, 2026, 2:16 AM

#

ok now my openclaw replies with a blank message (no "...")

root@Gilbotron6900:~# sudo -u openclaw -H openclaw models status --probe

🦞 OpenClaw 2026.2.9 (33c75cb) — Your .env is showing; don't worry, I'll pretend I didn't see it.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-3-5-sonnet-20241022
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-3-5-sonnet-20241022

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=sk-ant-a...HsNcIQAA

OAuth/token status

none

Auth probes
┌──────────────────────────────────────┬─────────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ anthropic/claude-3-5-sonnet-20241022 │ anthropic:default (api_key) │ unknown · 723ms │
│ │ │ ↳ EACCES: permission denied, chdir '~/.openclaw/workspace' -> '/root' │
└──────────────────────────────────────┴─────────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────┘
Probed 1 target in 755ms

knotty micaBOT Feb 14, 2026, 2:18 AM

#

That models status --probe output is telling you exactly what’s wrong:

EACCES: permission denied, chdir '~/.openclaw/workspace' -> '/root'

So the Anthropic key is configured, but OpenClaw (or the probe) is trying to chdir into /root at some point, which the openclaw user can’t access. When agent runs can’t chdir to their workspace, you’ll often see “blank reply” / immediate failure with no useful UI output.

1) Stop running OpenClaw commands from `/root`

Because sudo -u openclaw … inherits the current working directory. If you’re sitting in /root, things get weird.

Run this instead (forces a sane cwd):

sudo -u openclaw -H bash -lc 'cd ~; pwd; openclaw models status --probe'

2) Check what workspace is configured (and fix it if it points at /root)

#

sudo -u openclaw -H bash -lc 'openclaw config get agents.defaults.workspace'

If that prints /root (or something under /root), set it to something owned by openclaw, e.g.:

sudo -u openclaw -H bash -lc 'openclaw config set agents.defaults.workspace "/home/openclaw/.openclaw/workspace"'
sudo -u openclaw -H bash -lc 'mkdir -p /home/openclaw/.openclaw/workspace'

Then restart the gateway (as openclaw’s user service, from root):

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \

#

systemctl --user restart openclaw-gateway.service

3) Confirm the agent can actually produce a reply (bypass dashboard)

ID="cli-$(date +%s)"
sudo -u openclaw -H bash -lc "openclaw gateway call chat.send --params '{\"sessionKey\":\"main\",\"message\":\"ping\",\"idempotencyKey\":\"$ID\"}'"
sleep 2
sudo -u openclaw -H bash -lc 'openclaw gateway call chat.history --params "{\"sessionKey\":\"main\",\"limit\":20}\"'

If the CLI chat.send works but the dashboard still shows blank, then it’s a dashboard/proxy UI issue. If the CLI send also produces no assistant message, we’ll tail /tmp/openclaw/openclaw-*.log right when you send and catch the exact error line.

Run step (1) and paste the new models status --probe output (it should no longer show that chdir /root error).

tender egret Feb 14, 2026, 2:21 AM

#

root@Gilbotron6900:~# sudo -u openclaw -H openclaw models status --probe

🦞 OpenClaw 2026.2.9 (33c75cb) — Your .env is showing; don't worry, I'll pretend I didn't see it.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-3-5-sonnet-20241022
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-3-5-sonnet-20241022

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=sk-ant-a...HsNcIQAA

OAuth/token status

none

Auth probes
┌──────────────────────────────────────┬─────────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────────────────────┼─────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ anthropic/claude-3-5-sonnet-20241022 │ anthropic:default (api_key) │ unknown · 723ms │
│ │ │ ↳ EACCES: permission denied, chdir '~/.openclaw/workspace' -> '/root' │
└──────────────────────────────────────┴─────────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────┘
Probed 1 target in 755ms

#

root@Gilbotron6900:~# ID="cli-$(date +%s)"
sudo -u openclaw -H bash -lc "openclaw gateway call chat.send --params '{"sessionKey":"main","message":"ping","idempotencyKey":"$ID"}'"
sleep 2
sudo -u openclaw -H bash -lc 'openclaw gateway call chat.history --params "{"sessionKey":"main","limit":20}"'

🦞 OpenClaw 2026.2.9 (33c75cb) — OpenAI-compatible, not OpenAI-dependent.

│
◇
Gateway call: chat.send
{
"runId": "cli-1771035627",
"status": "started"
}
bash: -c: line 1: unexpected EOF while looking for matching `"'

knotty micaBOT Feb 14, 2026, 2:23 AM

#

That models status --probe error is the key:

EACCES: permission denied, chdir '~/.openclaw/workspace' -> '/root'

It means the probe is trying to change directories back to /root at some point (because you’re running the command from /root and then dropping to the openclaw user). That can also cause “blank replies” / immediate failures.

1) Re-run the probe from a safe working dir (this should remove the chdir error)

Run:

sudo -u openclaw -H bash -lc 'cd ~; openclaw models status --probe'

If auth is truly good, you should now see the Anthropic probe come back as ok (or at least a real API error like 401/429, not a chdir permission error).

2) Make the gateway service itself use a safe WorkingDirectory (recommended)

Check if the unit has a bad WorkingDirectory:

#

sudo -u openclaw -H bash -lc 'rg -n "WorkingDirectory|Environment=HOME" ~/.config/systemd/user/openclaw-gateway.service || true'

Regardless, you can force it to something sane with a drop-in:

cat > /home/openclaw/.config/systemd/user/openclaw-gateway.service.d/workingdir.conf <<'EOF'
[Service]
WorkingDirectory=/home/openclaw
EOF
chown -R openclaw:openclaw /home/openclaw/.config/systemd/user/openclaw-gateway.service.d

Then restart the service as the openclaw user (via its user-bus):

#

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user daemon-reload

sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user restart openclaw-gateway.service

3) If dashboard still shows blank replies: confirm backend can reply via CLI

ID="cli-$(date +%s)"

#

sudo -u openclaw -H bash -lc "cd ~; openclaw gateway call chat.send --params '{\"sessionKey\":\"main\",\"message\":\"ping\",\"idempotencyKey\":\"$ID\"}'"
sleep 2
sudo -u openclaw -H bash -lc 'cd ~; openclaw gateway call chat.history --params "{\"sessionKey\":\"main\",\"limit\":20}\"'

If the CLI send produces a real assistant reply in history, then the gateway/model is fine and we’ll focus on the dashboard/proxy UI. If it doesn’t, we’ll tail the file log right when you send and grab the exact error line.

Run step (1) first and paste the new models status --probe output.

#

Good: chat.send returning { status: "started" } means the Gateway did receive the message. Your follow-up command just broke due to quoting.

Run these exactly (copy/paste) to fetch history and see whether an assistant reply was generated:

# 1) Send a ping
ID="cli-$(date +%s)"
sudo -u openclaw -H bash -lc "cd ~; openclaw gateway call chat.send --params '{\"sessionKey\":\"main\",\"message\":\"ping\",\"idempotencyKey\":\"$ID\"}'"

# 2) Wait a bit (model calls can take >2s)
sleep 8

# 3) Fetch recent history (this should now include your ping + (hopefully) an assistant reply)
sudo -u openclaw -H bash -lc "cd ~; openclaw gateway call chat.history --params '{\"sessionKey\":\"main\",\"limit\":30}'"

If you see your `ping` but NO assistant message in history

#

Then the agent/model run is failing silently. Tail the gateway file log while you send another ping:

tail -n 200 -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Send a ping from dashboard again and paste the first error lines that appear.

One more thing (important): your `models status --probe` is failing because you run commands from `/root`

That’s why you saw chdir ... -> /root. Quick fix: do this before probing:

cd /
sudo -u openclaw -H openclaw models status --probe

(or keep using bash -lc "cd ~; ...", like above)

#

Paste the output of the chat.history call (step 3) and we’ll know immediately whether it’s a model-run failure or a dashboard/proxy issue.

tender egret Feb 14, 2026, 3:04 AM

#

i am now getting this is in the dashboard and similar in the tui:

disconnected (1008): unauthorized: gateway token mismatch (open the dashboard URL and paste the token in Control UI settings)

knotty micaBOT Feb 14, 2026, 3:05 AM

#

That means the Gateway token changed again (or you’re now connecting to a different origin), and both the dashboard and TUI are still sending the old token.

1) Get the actual token the running gateway expects (source of truth)

Run on the server (as root):

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p'

Copy that value (don’t paste it in chat).

2) Fix the dashboard (browser)

#

Open the dashboard at the exact URL you use (e.g. https://164.92.159.153/).

Click Settings (gear)
Paste the token into the token field
Reconnect / refresh

If it keeps reusing an old token, clear the stored settings in the browser:

localStorage.removeItem("openclaw.control.settings.v1"); location.reload();

Important: the token is stored per origin, so http://127.0.0.1:18789/ and https://164.92.159.153/ each have their own saved token.

3) Fix the TUI

Make sure you’re not running the TUI as root. Run it as openclaw, passing the token explicitly:

#

TOKEN="<paste token from step 1>"
sudo -u openclaw -H openclaw tui --url ws://127.0.0.1:18789 --token "$TOKEN"

4) Make it stop flipping (optional but recommended)

Align config to the same token systemd is using, so you don’t end up with “service token vs config token” drift:

UID_OPENCLAW="$(id -u openclaw)"
SVC_TOKEN="$(
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user show openclaw-gateway.service -p Environment --value \
| tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p'

#

)"
sudo -u openclaw -H openclaw config set gateway.auth.token "$SVC_TOKEN"
sudo -u openclaw -H openclaw config set gateway.remote.token "$SVC_TOKEN"

If after step (2) you get “pairing required”, that’s normal—approve once via openclaw devices list / openclaw devices approve <requestId>.

tender egret Feb 14, 2026, 3:10 AM

#

im still getting the same error and also received this:

root@Gilbotron6900:~# sudo -u openclaw openclaw gateway restart

🦞 OpenClaw 2026.2.9 (33c75cb) — One CLI to rule them all, and one more restart because you changed the port.

Gateway service check failed: Error: systemctl --user unavailable: Failed to connect to bus: No medium found

knotty micaBOT Feb 14, 2026, 3:11 AM

#

That No medium found happens because you ran the restart as the openclaw user but without its systemd user-bus environment, so systemctl --user can’t be reached.

Use this exact wrapper (so every command hits `openclaw`’s user service correctly)

Run as root:

UID_OPENCLAW="$(id -u openclaw)"
ocsys() {
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
"$@"
}

Now restart the gateway service (this is the reliable way, instead of openclaw gateway restart):

#

ocsys systemctl --user restart openclaw-gateway.service
ocsys openclaw gateway status

You’re still seeing token mismatch: verify you’re connecting to the same gateway

Check which user owns the listener on 18789:

ss -lptn 'sport = :18789'
# then:
ps -fp <PID_FROM_SS>

It must show user openclaw (not root). If it’s root, stop root’s service so it stops stealing the port:

systemctl --user stop openclaw-gateway.service

#

Get the actual token the running gateway expects (source of truth):

TOKEN="$(ocsys systemctl --user show openclaw-gateway.service -p Environment --value | tr ' ' '\n' | sed -n 's/^OPENCLAW_GATEWAY_TOKEN=//p')"
echo "token starts with: ${TOKEN:0:6}"

Then in the browser Control UI (your https://164.92.159.153/ origin), open Settings and paste the full token. If it keeps reusing the old token, run in browser devtools:

localStorage.removeItem("openclaw.control.settings.v1"); location.reload();

For the TUI, pass the token explicitly:

ocsys openclaw tui --url ws://127.0.0.1:18789 --token "$TOKEN"

If you paste just:

#

the ss -lptn 'sport = :18789' output
and ps -fp <pid>
…I can tell you immediately if you’re still accidentally hitting a root gateway vs the openclaw gateway.

tender egret Feb 14, 2026, 3:14 AM

#

ok its the dashboard shows connected again now, but my openclaw still responds with a blank message

knotty micaBOT Feb 14, 2026, 3:15 AM

#

If the dashboard is connected but replies are blank, the fastest way to pinpoint it is to see what actually got written to the session transcript + what the gateway logged during the run.

1) Check what the gateway thinks the last messages are

Run (as openclaw):

sudo -u openclaw -H bash -lc 'cd ~; openclaw gateway call chat.history --params "{\"sessionKey\":\"main\",\"limit\":30}"'

Look for:

your user message (ping)
an assistant message with content / text

If the assistant message exists but text is empty, that’s why the UI shows blank (it’s receiving an empty payload).

2) Tail the gateway file log while you send one message

This doesn’t rely on openclaw logs RPC at all:

#

tail -n 200 -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Now send a message from the dashboard (e.g. hello). Paste the first error/warn lines that appear after you hit send.

3) Most common cause given your earlier issue: workspace/cwd permissions

If the gateway is still trying to run the agent in a workspace it can’t access, it may fail in a way that produces no reply.

Check the configured workspace:

sudo -u openclaw -H bash -lc 'openclaw config get agents.defaults.workspace'

If it’s unset or weird, set it to a writable dir:

#

sudo -u openclaw -H bash -lc 'openclaw config set agents.defaults.workspace "/home/openclaw/.openclaw/workspace"'
sudo -u openclaw -H bash -lc 'mkdir -p /home/openclaw/.openclaw/workspace'

Then restart the gateway service (openclaw user bus):

UID_OPENCLAW="$(id -u openclaw)"
sudo -u openclaw -H env \
XDG_RUNTIME_DIR="/run/user/$UID_OPENCLAW" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$UID_OPENCLAW/bus" \
systemctl --user restart openclaw-gateway.service

Reply with the output of (1) (chat.history), and we’ll know whether the agent is producing empty messages vs the UI is dropping them.

tender egret Feb 14, 2026, 3:23 AM

#

{
"role": "user",
"content": [
{
"type": "text",
"text": "hello"
}
],
"timestamp": 1771039338158
},
{
"role": "assistant",
"content": [],
"api": "anthropic-messages",
"provider": "anthropic",
"model": "claude-3-5-sonnet-20241022",
"usage": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0,
"totalTokens": 0,
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0,
"total": 0
}
},
"stopReason": "error",
"timestamp": 1771039338169,
"errorMessage": "404 {"type":"error","error":{"type":"not_found_error","message":"model: claude-3-5-sonnet-20241022"},"request_id":"req_011CY7F5CepxURrYpVY9DP2X"}"
},
{
"role": "user",
"content": [
{
"type": "text",
"text": "hello"
}
],
"timestamp": 1771039340792
},
{
"role": "assistant",
"content": [],
"api": "anthropic-messages",
"provider": "anthropic",
"model": "claude-3-5-sonnet-20241022",
"usage": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0,
"totalTokens": 0,
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0,
"total": 0
}
},
"stopReason": "error",
"timestamp": 1771039340796,
"errorMessage": "404 {"type":"error","error":{"type":"not_found_error","message":"model: claude-3-5-sonnet-20241022"},"request_id":"req_011CY7F5PcdqBGKVcrCicAKT"}"
}
],
"thinkingLevel": "off"
}
}

knotty micaBOT Feb 14, 2026, 3:24 AM

#

That blank “reply” is because the model call is erroring, and the UI isn’t rendering the error nicely. Your chat.history shows the real cause:

404 ... not_found_error ... "model: claude-3-5-sonnet-20241022"

So Anthropic is telling you: that model name isn’t available for your key/account (or it’s been renamed/removed).

Fix: switch your default model to one your Anthropic key can actually use

List Anthropic models your install knows about (pick one to try):

sudo -u openclaw -H openclaw models list --all --provider anthropic

Set the default to a model from that list:

sudo -u openclaw -H openclaw models set <model-id-from-the-list>

#Gateway token mismatch error

1) Quick triage (please paste output, but do not paste the tokens)

2) The most common fix

3) If it still fails: config/env mismatch between “CLI” and the running service

Fix: make it one Gateway instance on that port

1) Identify who is actually listening on 18789

2) Check both systemd services

3) Stop/disable the extra one (pick ONE to keep)

If you still see “token mismatch” after that

The fix: run exactly ONE gateway, under ONE user

1) Check which services are active

2) Stop/disable the system one (if it’s enabled)

3) Restart your user gateway

4) Verify only one listener exists

Do this (and paste output)

A) First confirm which user you are

B) Check whether anything is listening on 18789

C) Get the gateway service logs (this is the key)

1) Identify the process that owns the port

2) Stop the other gateway instance (most likely the system service)

3) Important: don’t run the CLI with sudo

Do this and paste the output (no tokens involved)

Most common fix

Fix (get to ONE gateway + ONE user)

Step A — confirm you’re not root

Step B — stop the root-owned gateway that’s on 18789

Step C — start your normal user gateway and test (NO sudo)

1) Decide: do you want the Gateway to run as root, or as a normal user?

If you want the normal-user gateway

2) If you insist on running everything as root

What I need from you

What’s wrong (specific)

Fix (sync the tokens)

If you’d rather just reset to a fresh token (often fastest)

One more gotcha to rule out (env override)

Option A (recommended): remove the env var and use config only

Option B: keep the env var, but set it to the same value

Quick “no editor” workaround (force-clear env var via systemd override)

Console-only way (no editor): add a systemd drop-in override

Important note

Force config to match the token systemd is using (no editing unit files)

If it still errors

1) Confirm what those two PIDs are

2) Stop the supervised service, then kill the stray listener

3) Start ONE gateway with ONE token (fastest “make it work” reset)

Do this “hard reset” of the listener (console-only)

If it STILL says token mismatch

What you’re looking for in the output

If you want to stop it from respawning

If your real issue is still the token mismatch

Fix: disable the rescue gateway, keep only the normal one

If you still get token mismatch after that

1) Show me what units exist right now

2) Stop/disable the rescue gateway (this is the one that was stealing the port)

3) Re-enable/start the normal gateway

4) Verify only ONE PID is listening, then re-test

1) Confirm whether the service is still getting an env token

2) Force systemd’s token to match the config token (console-only)

If it STILL says token mismatch

First, show hashes (no secrets) so we know which one differs

Fastest fix: set ONE fresh token everywhere (service + config + shell)

1) Also make sure gateway.auth.token matches (so CLI + service can’t diverge later)

2) Your current failure is “port not listening”, so we need the journal

1) Fix the Control UI token (this is the actual “token_mismatch” now)

2) Fix the reverse proxy warning (recommended)

Quick confirmation

If your problem is: “Control UI / browser says unauthorized / keeps reconnecting”

If your problem is still: “openclaw gateway status fails”

If you want the “why is proxy untrusted” bit fixed

Fast fix (once we confirm which one differs)

What’s happening

Fix: make the main unit file token match the real token

Quick verification (no secrets)

Fix: approve the device pairing request

Optional but recommended (because you’re behind a reverse proxy)

Quick check: where is the old history?

How to “get memory back”

Best fix: run the gateway as the openclaw user again

1) Stop/disable the root user service

2) Switch to the openclaw account and start the user service there

1) Also make sure `gateway.auth.token` matches (so CLI + service can’t diverge later)

If your problem is still: “`openclaw gateway status` fails”

Best fix: run the gateway as the `openclaw` user again

Fix: get systemd user services working for the `openclaw` user (headless-safe)

Run OpenClaw as `openclaw` with the correct env (headless-safe)

1) That `find: Failed to restore initial working directory: /root: Permission denied`

2) Dashboard: `disconnected (1008): unauthorized: gateway token mismatch`

Option B: use `openclaw logs`, but show the real error

1) Stop running OpenClaw commands from `/root`

If you see your `ping` but NO assistant message in history

One more thing (important): your `models status --probe` is failing because you run commands from `/root`

Use this exact wrapper (so every command hits `openclaw`’s user service correctly)