gateway error. | Friends of the Crustacean 🦞🤝 | Page 1

peak kilnBOT Apr 27, 2026, 2:31 PM

#

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

unborn peakBOT Apr 27, 2026, 2:32 PM

#

That “version mismatch” is probably a symptom, not the root cause — the CLI can’t query the gateway because nothing is actually listening on 127.0.0.1:18789.

The key line is:

Gateway port 18789 is not listening (service appears running)

So the systemd service exists and Node is alive, but OpenClaw likely failed/hung before binding the gateway port.

Please paste these next:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager
cat ~/.openclaw/logs/gateway-restart.log
tail -n 200 /tmp/openclaw/openclaw-2026-04-27.log

#

openclaw doctor

Also, because the machine says *** System restart required *** and your SSH connection reset, I’d do a full reboot if you can:

sudo reboot

Then after reconnecting:

openclaw gateway status --deep

Docs for the gateway troubleshooting ladder: https://docs.openclaw.ai/gateway/troubleshooting 🦐

fleet basalt Apr 27, 2026, 2:33 PM

#

ive actually used this gateway? as node to connect vps with local windows to use browser control. was thsi the problem?

unborn peakBOT Apr 27, 2026, 2:34 PM

#

Not directly, no.

Using a Windows node for browser control is a valid setup. But a node failing to connect should not stop the VPS gateway from listening on 127.0.0.1:18789.

What is suspicious:

Gateway: bind=loopback (127.0.0.1)
Gateway port 18789 is not listening

So there are two layers:

Current blocker: VPS gateway itself is not binding/listening. Need the logs from:
```
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
```

#

   cat ~/.openclaw/logs/gateway-restart.log
   tail -n 200 /tmp/openclaw/openclaw-2026-04-27.log

After gateway is healthy: your Windows browser node cannot connect directly to a loopback-only VPS gateway unless you use SSH tunnel / Tailscale / proper remote access. Loopback means “only clients on the VPS itself.”

For Windows-as-browser-node, the intended shape is: VPS runs Gateway, Windows runs node host, browser actions proxy through that node. Docs: https://docs.openclaw.ai/nodes and https://docs.openclaw.ai/gateway/remote 🦐

#

Yep — now we have the real cause, and it’s not the Windows node.

Gateway startup is failing because of hook config validation:

hooks.allowedSessionKeyPrefixes is required when a hook mapping sessionKey uses templates

Fix it with either option:

If you use hooks/Gmail/webhooks:

openclaw config set hooks.allowRequestSessionKey true --strict-json
openclaw config set hooks.allowedSessionKeyPrefixes '["hook:","hook:gmail:"]' --strict-json
openclaw config validate

#

openclaw gateway restart

If you don’t use hooks:

openclaw config set hooks.enabled false --strict-json
openclaw config validate
openclaw gateway restart

Don’t paste your full hooks config here unless you redact tokens. If you want to inspect safely:

openclaw config get hooks.presets --json

#

openclaw config get hooks.mappings --json

Docs: https://docs.openclaw.ai/gateway/configuration-reference#hooks 🦐

fleet basalt Apr 27, 2026, 2:37 PM

#

what is hook?

unborn peakBOT Apr 27, 2026, 2:38 PM

#

A hook is an external trigger into OpenClaw.

Example: some service sends an HTTP request to your gateway like:

POST /hooks/gmail

…and OpenClaw wakes an agent, creates/uses a session, and optionally replies somewhere.

Common uses:

Gmail/webhook notifications
custom automations
“when X happens, wake OpenClaw and tell it Y”

Your error means your config has hooks enabled with a templated session key, probably something like:

#

hook:gmail:{{messages[0].id}}

OpenClaw now requires you to explicitly allow what session key prefixes are safe.

If you don’t know what hooks are / didn’t mean to use them, just disable them:

openclaw config set hooks.enabled false --strict-json
openclaw gateway restart

This won’t break your Windows browser node setup. Browser nodes do not need hooks.

Docs: https://docs.openclaw.ai/gateway/configuration-reference#hooks 🦐

fleet basalt Apr 27, 2026, 2:39 PM

#

Im using VPS, and im not using window broswer node right now

unborn peakBOT Apr 27, 2026, 2:39 PM

#

Yep, then the Windows node is irrelevant here.

Your gateway is failing before it even starts because hooks are enabled in config. If you’re not intentionally using webhook/Gmail hooks, disable them:

openclaw config set hooks.enabled false --strict-json
openclaw config validate
openclaw gateway restart
openclaw gateway status --deep

If that comes back healthy, you’re done.

If it still fails, paste the new last error from:

#

tail -n 100 /tmp/openclaw/openclaw-2026-04-27.log

Docs: https://docs.openclaw.ai/gateway/configuration-reference#hooks 🦐

fleet basalt Apr 27, 2026, 2:41 PM

#

my oauth providers token refresh failed and sht.. does this matter?

unborn peakBOT Apr 27, 2026, 2:41 PM

#

For this specific gateway-not-listening error, probably no.

OAuth token-refresh failures can break model calls later, but your gateway is currently dying at startup because of this config error:

hooks.allowedSessionKeyPrefixes is required...

So fix the hook config first:

openclaw config set hooks.enabled false --strict-json
openclaw config validate
openclaw gateway restart
openclaw gateway status --deep

#

After the gateway is healthy, then check OAuth/model auth separately:

openclaw models status
openclaw doctor

If OAuth is still broken, re-run the relevant provider setup/configure flow — but don’t chase that until Connectivity probe: ok first. 🦐

shut trout Apr 27, 2026, 2:42 PM

#

what hooks are used for?

unborn peakBOT Apr 27, 2026, 2:42 PM

#

Hooks are for event-driven automation — letting something outside OpenClaw wake or trigger it.

Examples:

Gmail/webhook notifications: “new email arrived → wake an agent”
Custom webhooks: GitHub, Stripe, your own app, etc. sends POST /hooks/...
Startup/session hooks: run extra instructions or setup when a session/gateway starts
Automation glue: “when this external event happens, send this message to an agent/session”

They’re optional. For a normal VPS gateway + Discord/Telegram/chat setup, you often don’t need them.

In Paul’s case, hooks are only relevant because the config has them enabled and invalid, so the gateway refuses to start. If he’s not intentionally using webhooks/Gmail hooks, disabling them is the right quick fix.

#

Good — this is progress. It’s no longer ECONNREFUSED; now the gateway is listening:

Listening: 127.0.0.1:18789
pid 1985645 ubuntu: openclaw-gateway

So don’t change ports. The “port already in use” is just the gateway itself.

Now it’s either still warming up or hanging during startup. Wait ~30s, then run:

openclaw gateway status --deep
curl -sS -m 5 http://127.0.0.1:18789/healthz ; echo
curl -sS -m 5 http://127.0.0.1:18789/readyz ; echo
tail -n 120 /tmp/openclaw/openclaw-2026-04-27.log

#

If healthz works but readyz fails/timeouts, the server is alive but some startup piece is stuck. The log tail should show which one. Also since your VPS says *** System restart required ***, a full reboot is still a reasonable cleanup step if this keeps hanging.

#

That log tail is still showing the same hooks config error, so first make sure the config change actually applied.

Run these exactly:

openclaw config set hooks.enabled false --strict-json
openclaw config get hooks.enabled --json
openclaw config validate

You want hooks.enabled to print:

false

Then do a clean service restart:

#

systemctl --user restart openclaw-gateway.service
sleep 10
openclaw gateway status --deep

If it still says timeout, paste the newest log lines with timestamps:

tail -n 200 /tmp/openclaw/openclaw-2026-04-27.log
journalctl --user -u openclaw-gateway.service -n 100 --no-pager

Also: since the VPS says *** System restart required ***, if the config validates but the gateway stays half-alive/listening-but-timeout, reboot the VPS once. That can clear a stuck systemd/process state.

fleet basalt Apr 27, 2026, 2:46 PM

#

how do i check gateway health

unborn peakBOT Apr 27, 2026, 2:46 PM

#

Use these, in order:

openclaw gateway status --deep

Then direct HTTP health endpoints:

curl -sS -m 5 http://127.0.0.1:18789/healthz ; echo
curl -sS -m 5 http://127.0.0.1:18789/readyz ; echo

And the WS health command:

#

openclaw health --verbose

Healthy signs:

Connectivity probe: ok
Capability: ...

/healthz = basic server is alive.
/readyz = gateway finished startup and is ready.

In your case, fix the hook config first, then re-check:

#

openclaw config set hooks.enabled false --strict-json
openclaw config validate
openclaw gateway restart
openclaw gateway status --deep

#

You’re not crazy — this state is confusing.

What’s wrong right now:

ECONNREFUSED changed to timeout
port 18789 is now owned by openclaw-gateway
but health/WebSocket doesn’t respond

So the gateway process is alive enough to bind the port, but hung/not ready enough to answer requests.

Do this cleanly:

openclaw config get hooks.enabled --json
openclaw config validate

#

If hooks.enabled is not false, run:

openclaw config set hooks.enabled false --strict-json
openclaw config validate

Then fully stop/start the service:

systemctl --user stop openclaw-gateway.service
sleep 5
ss -ltnp | grep 18789 || true
systemctl --user start openclaw-gateway.service
sleep 15
openclaw gateway status --deep

#

If ss still shows something on 18789 after stop, the old process is stuck. Since your VPS already says *** System restart required ***, I’d honestly reboot once:

sudo reboot

Then after reconnect:

openclaw gateway status --deep
tail -n 120 /tmp/openclaw/openclaw-2026-04-27.log

Don’t change ports — the “port already in use” is just the gateway itself.

fleet basalt Apr 27, 2026, 2:56 PM

#

ive tried all.

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/ubuntu/.npm-global/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 1938, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

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

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

unborn peakBOT Apr 27, 2026, 2:56 PM

#

Okay — stop re-running gateway status for a moment. It’s only telling us the symptom now: systemd process exists, but gateway never binds the port.

We need the startup error.

Run this exact block and paste the output:

openclaw config get hooks.enabled --json
openclaw config validate

journalctl --user -u openclaw-gateway.service -n 250 --no-pager
cat ~/.openclaw/logs/gateway-restart.log
tail -n 200 /tmp/openclaw/openclaw-2026-04-27.log

If those still don’t show a fresh error, do a foreground startup test:

#

systemctl --user stop openclaw-gateway.service
sleep 3
OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --port 18789 --verbose

Let it sit ~30 seconds, then paste the last error/output. That will show what startup phase is hanging or crashing. Right now we’re missing the actual cause after the hook fix.

fleet basalt Apr 27, 2026, 2:59 PM

#

yes. it siads false. and the log is too fucking long for me to paste.

unborn peakBOT Apr 27, 2026, 2:59 PM

#

Yeah, don’t paste the whole log — that’s miserable.

Since hooks.enabled is now false, we need just the new error lines. Run this:

journalctl --user -u openclaw-gateway.service --since "15 minutes ago" --no-pager -o cat \
  | grep -Ei 'error|failed|fatal|exception|uncaught|startup|timeout|warn' \
  | tail -n 80

And this:

grep -Ei '"logLevelName":"(ERROR|WARN)"|Gateway failed|startup_failed|Unhandled|uncaught|fatal|Error:' \
  /tmp/openclaw/openclaw-2026-04-27.log \
  | tail -n 80

#

If that’s still too much, use the diagnostics export instead:

openclaw gateway diagnostics export --output ~/openclaw-diagnostics.zip

Then attach ~/openclaw-diagnostics.zip here. It’s meant for sharing and redacts sensitive stuff.

Right now the important fact is: the old hook issue is fixed, but the gateway still crashes/hangs before listening, so we need the next startup error. 🦐

shut trout Apr 27, 2026, 3:05 PM

#

interesting that I'm facing simular problem...

unborn peakBOT Apr 27, 2026, 3:05 PM

#

Could be same symptom, but not necessarily same cause. The important distinction is:

ECONNREFUSED = nothing is listening on the port
timeout while port is owned by openclaw-gateway = process is alive but hung/not answering
The actual cause is usually in the startup logs

For your setup, first run:

openclaw --version
openclaw gateway status --deep
openclaw config validate

Then grab only the useful log lines:

#

journalctl --user -u openclaw-gateway.service --since "15 minutes ago" --no-pager -o cat \
  | grep -Ei 'error|failed|fatal|exception|uncaught|startup|timeout|warn' \
  | tail -n 80

And:

grep -Ei '"logLevelName":"(ERROR|WARN)"|Gateway failed|startup_failed|Unhandled|uncaught|fatal|Error:' \
  /tmp/openclaw/openclaw-$(date +%F).log \
  | tail -n 80

If you see the same hooks error, fix is:

#

openclaw config set hooks.enabled false --strict-json
openclaw config validate
openclaw gateway restart

But paste your exact filtered error first if it’s different. Similar gateway symptoms can come from totally different config failures.

shut trout Apr 27, 2026, 3:44 PM

#

my problem is with slack! Somehow slack makes my Gateway go kaboom

unborn peakBOT Apr 27, 2026, 3:44 PM

#

Yeah, Slack can absolutely be the startup trigger if the Slack channel plugin crashes/hangs during init.

First isolate it:

openclaw --version
openclaw config set channels.slack.enabled false --strict-json
openclaw config validate
openclaw gateway restart
openclaw gateway status --deep

If the gateway becomes healthy after that, we know Slack config/runtime is the culprit.

Then grab the Slack-specific errors only:

#

journalctl --user -u openclaw-gateway.service --since "30 minutes ago" --no-pager -o cat \
  | grep -Ei 'slack|bolt|socket|xapp|xoxb|error|failed|fatal|exception' \
  | tail -n 100

Also check Slack config shape without leaking tokens:

openclaw config get channels.slack.enabled --json
openclaw config get channels.slack.mode --json
openclaw channels status --probe

Do not paste xoxb-, xapp-, or signing secrets.

Common Slack things to verify:

#gateway error.