Gateway not starting after updating to Openclaw 2026.4.25 | Friends of the Crustacean 🦞🤝 | Page 1

cinder swan Apr 27, 2026, 1:02 PM

#

schergr@theclaw2:~$ OPENCLAW_GATEWAY_STARTUP_TRACE=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789

🦞 OpenClaw 2026.4.25 (aa36ee6) — Your task has been queued; your dignity has been deprecated.

│
◇
08:57:43 [gateway] startup trace: cli.server-import 2.1ms total=2.1ms
08:57:43 [gateway] loading configuration…
08:57:44 [gateway] startup trace: cli.config-load 369.6ms total=383.7ms
08:57:44 [gateway] startup trace: cli.config-snapshot 366.2ms total=750.9ms
08:57:44 [gateway] resolving authentication…
08:57:44 [gateway] startup trace: cli.auth-resolve 0.3ms total=754.3ms
08:57:44 [gateway] starting...
08:57:44 [gateway] startup trace: cli.gateway-loop 1.7ms total=756.0ms
08:57:46 [gateway] startup trace: config.snapshot 620.2ms total=620.2ms
08:57:48 [gateway] startup trace: config.auth 2543.5ms total=3165.6ms
08:57:48 [gateway] startup trace: control-ui.seed 0.1ms total=3167.1ms
08:57:53 [gateway] startup trace: plugins.bootstrap 4362.0ms total=7529.9ms
08:57:53 [gateway] startup trace: runtime.config 4.1ms total=7535.0ms
08:57:53 [gateway] startup trace: control-ui.root 0.9ms total=7537.7ms
08:57:53 [gateway] startup trace: tls.runtime 0.1ms total=7538.7ms
08:57:53 [gateway] starting HTTP server...
08:57:53 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/schergr/.openclaw/canvas)

trail zephyrBOT Apr 27, 2026, 1:02 PM

#

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

cinder swan Apr 27, 2026, 1:03 PM

#

09:00:56 [ws] closed before connect conn=022f0954-65f1-4bd8-a1fd-8ddfedf82099 peer=127.0.0.1:56740->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
09:00:56 [ws] closed before connect conn=57802912-8594-4655-8727-b9cb9e2189bb peer=127.0.0.1:55554->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
09:00:56 [telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 67 commands visible.
09:00:57 [telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 66 commands visible.
09:00:57 [telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 73 commands visible.
09:00:57 [telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 66 commands visible.
09:00:57 [ws] closed before connect conn=46b794ab-b70e-411f-b4bc-96673edaa7c6 peer=127.0.0.1:40340->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
09:00:57 [telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
09:00:57 [slack] socket mode connected
09:00:57 [sessions/store] backed up session store file before rotation
09:00:57 [sessions/store] cleaned up old session store backups
09:00:59 [discord] client initialized as 1466954213090132180 (Jinx); awaiting gateway readiness
09:01:01 [whatsapp] [default] starting provider (+16784699029)
09:01:02 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
09:01:14 [discord] discord: gateway was not ready after 15000ms; restarting gateway
09:01:58 [telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)

#

09:00:57 [ws] closed before connect conn=46b794ab-b70e-411f-b4bc-96673edaa7c6 peer=127.0.0.1:40340->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a

slow falconBOT Apr 27, 2026, 1:06 PM

#

That trace is useful. You’re on 2026.4.25 / aa36ee6, so version is confirmed. (github.com)

It’s stopping before the usual runtime.state / http.bound / ready traces, right after Canvas mounts. So I’d check whether it’s actually bound or hanging before the HTTP listener:

openclaw status --all
openclaw gateway status --deep
curl -v http://127.0.0.1:18789/healthz
ss -ltnp | grep ':18789' || true

Those are the right first diagnostics per the FAQ/debug flow. (docs.openclaw.ai)

If there’s no listener, try this once:

#

OPENCLAW_GATEWAY_STARTUP_TRACE=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789 --bind lan

Only use --bind lan if you have gateway auth configured, since it listens beyond loopback. If --bind lan gets past this point, it smells like a loopback/IPv6 bind-probe regression on this host. If it still hangs, please paste openclaw status --all plus the last ~100 log lines.

#

Ah — this changes the diagnosis: the Gateway did bind/start. The ws closed before connect lines are local probes while startup is still not “ready”.

The blocker now looks like startup sidecars/channels, with Telegram network timeouts and Discord timing out waiting for readiness:

[telegram] ... ETIMEDOUT,ENETUNREACH
[discord] gateway was not ready after 15000ms

Quick isolation:

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789
curl -fsS http://127.0.0.1:18789/healthz
curl -fsS http://127.0.0.1:18789/readyz

#

If that becomes ready, it’s definitely a channel startup issue. I’d try Telegram IPv4-only next:

OPENCLAW_TELEGRAM_DISABLE_AUTO_SELECT_FAMILY=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789

If that fixes it, persist:

openclaw config set --batch-json '[{"path":"channels.telegram.network.autoSelectFamily","value":false}]'
openclaw gateway restart

Docs ref: https://docs.openclaw.ai/channels/telegram#troubleshooting

#

That specific ws ... closed before connect ... code=1006 line is probably not the root cause.

It means something on localhost opened the WebSocket and dropped before completing OpenClaw’s connect/auth handshake — often gateway status, Control UI, health probes, or a client retrying while the Gateway is still in startup.

The useful split is:

curl -i http://127.0.0.1:18789/healthz
curl -i http://127.0.0.1:18789/readyz

healthz OK = HTTP server is up.
readyz 503 with startup-sidecars / channel names = Gateway is alive but blocked waiting on sidecars/channels.

Given the later Telegram/Discord lines, I’d still isolate with:

#

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789

cinder swan Apr 27, 2026, 1:07 PM

#

schergr@theclaw2:~$ curl -i http://127.0.0.1:18789/healthz
curl -i http://127.0.0.1:18789/readyz
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Date: Mon, 27 Apr 2026 13:07:36 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 27

{"ok":true,"status":"live"}HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Date: Mon, 27 Apr 2026 13:07:36 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 45

{"ready":true,"failing":[],"uptimeMs":582956}

slow falconBOT Apr 27, 2026, 1:08 PM

#

Good news: the Gateway is started and ready now.

/healthz = live and /readyz = ready:true, failing:[] means the HTTP server + startup sidecars/channels are healthy. The uptimeMs:582956 is ~9m43s, so that foreground openclaw gateway ... process has been running since the earlier start.

Two notes:

openclaw gateway ... staying in the terminal is normal — it’s running the server in foreground.
The ws closed before connect ... 1006 line is probe/client noise, not fatal by itself.

Next verify:

openclaw gateway status
openclaw channels status --probe

If the browser UI is the thing that still looks offline, run:

#

openclaw dashboard

Docs: https://docs.openclaw.ai/help/faq

cinder swan Apr 27, 2026, 1:12 PM

#

schergr@theclaw2:~$ openclaw gateway status

🦞 OpenClaw 2026.4.25 (aa36ee6) — Your task has been queued; your dignity has been deprecated.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /home/schergr/.nvm/versions/node/v25.8.0/bin/node /home/schergr/.nvm/versions/node/v25.8.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/schergr/.nvm/versions/node/v25.8.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/schergr/.nvm/versions/node/v25.8.0/bin/node)
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 (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 1)
Connectivity probe: ok
Capability: admin-capable

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Restart attempts: /home/schergr/.openclaw/logs/gateway-restart.log

#

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
schergr@theclaw2:~$ openclaw channels status --probe

🦞 OpenClaw 2026.4.25 (aa36ee6) — The lobster in your shell. 🦞

│
◇
Gateway reachable.

Discord default: enabled, configured, running, connected, bot:@Jinx, token:config, intents:content=limited, works
Slack default: enabled, configured, running, connected, bot:config, app:config, works
Telegram default: enabled, not configured, stopped, mode:polling, error:not configured
Telegram elliot: enabled, configured, running, connected, mode:polling, bot:@Elliot_mrro_bot, token:config, works
Telegram harvey: enabled, configured, running, connected, mode:polling, bot:@myharveybot, token:config, works
Telegram jinx: enabled, configured, running, connected, in:3m ago, mode:polling, bot:@jinxassistant_bot, token:config, works
Telegram ozzy: enabled, configured, running, connected, mode:polling, bot:@OzzyBand_bot, token:config, works
WhatsApp default: enabled, configured, linked, running, connected, dm:allowlist, allow:+19176285535,+14703348233

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
schergr@theclaw2:~$

slow falconBOT Apr 27, 2026, 1:12 PM

#

Yep, now we’ve got the real issue: split state.

Connectivity probe: ok = the foreground openclaw gateway ... you started manually is healthy.
Runtime: stopped = the systemd service is not running.
The service is pointing at nvm Node v25.8.0, and status is warning that this is non-standard/fragile. OpenClaw docs recommend Node 24 or Node 22 LTS.

I’d fix the service, not the gateway itself:

# stop the foreground gateway first: Ctrl+C in that terminal

nvm install 24
nvm alias default 24
nvm use 24
npm install -g openclaw@latest

#

openclaw doctor --repair
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

If it still says Runtime: stopped, paste:

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

Docs: https://docs.openclaw.ai/help/faq

#

Nice, that confirms the Gateway itself is healthy now. All the real channels look connected/working; the only oddity is Telegram default: enabled, not configured, which is harmless if you’re using the named Telegram accounts instead.

Remaining fix is just the daemon/autostart split:

Stop the foreground gateway with Ctrl+C
Then repair/reinstall the service:

openclaw doctor --repair
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

If gateway status then shows Runtime: running + Connectivity probe: ok, you’re done. If it still says Runtime: stopped, paste:

#

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

cinder swan Apr 27, 2026, 1:19 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — Self-hosted, self-updating, self-aware (just kidding... unless?).

│
09:18:46 [memory] qmd memory unavailable; falling back to builtin: Cannot find package 'chokidar' imported from /home/schergr/.openclaw/plugin-runtime-deps/openclaw-2026.4.25-9292a9b437df/dist/qmd-manager-FuXCtSYP.js
Did you mean to import "chokidar/index.js"?
◇
│
◇
OpenClaw status

Overview
│ OS │ linux 6.18.7-surface-1 (x64) · node 24.15.0 │
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale exposure │ off
│ Channel │ stable (config)
│ Update │ pnpm · up to date · npm latest 2026.4.25
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (timeout) │
│ Gateway service │ systemd installed · enabled · running (pid 16120, state active)
│ Node service │ systemd not installed
│ Agents │ 6 · no bootstrap files · sessions 573 · default jinx active 7m ago │
│ Memory │ enabled (plugin memory-core) · unavailable
│ Plugin compatibility │ none
│ Probes │ skipped (use --deep)
│ Events │ none │
│ Tasks │ 0 active · 0 queued · 0 running · 123 issues · audit 4 warn · 804 tracked │
│ Heartbeat │ 30m (jinx), disabled (charlie), disabled (elliot), disabled (family), disabled (harvey), disabled (ozzy) │
│ Sessions │ 573 active · default gpt-5.5 (200k ctx) · 6 stores

slow falconBOT Apr 27, 2026, 1:20 PM

#

Nice, Node/service looks fixed now (node 24.15.0, service active). This is a new blocker:

qmd memory unavailable ... Cannot find package 'chokidar'
... ~/.openclaw/plugin-runtime-deps/...
Gateway unreachable (timeout)

That smells like a broken/stale bundled plugin runtime-deps staging dir.

Try this first:

openclaw gateway stop
openclaw doctor --repair
openclaw gateway restart

#

openclaw status --deep

If it still complains about chokidar, rebuild that cache/stage dir:

openclaw gateway stop
mv ~/.openclaw/plugin-runtime-deps ~/.openclaw/plugin-runtime-deps.bak.$(date +%s)
openclaw doctor --repair
openclaw gateway restart
openclaw status --deep

If you don’t intentionally need QMD memory, you can also bypass that path:

#

openclaw config set memory.backend builtin
openclaw gateway restart

If it still times out after that, paste:

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

Refs: https://docs.openclaw.ai/cli/doctor and https://docs.openclaw.ai/install/updating#advanced-npm-install-topics

cinder swan Apr 27, 2026, 1:23 PM

#

Gateway service config ──────────────────────────────────────────────────────────────────╮
│ │
│ - Gateway service entrypoint does not match the current install. │
│ (/home/schergr/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/index.js -> │
│ /home/schergr/.nvm/versions/node/v25.8.0/lib/node_modules/openclaw/dist/index.js)

slow falconBOT Apr 27, 2026, 1:23 PM

#

Yep — that message is exactly the remaining service mismatch:

current install: Node v24 path
systemd service: still points at old Node v25 path

Reinstall the service from the Node 24 environment:

# stop any foreground gateway first with Ctrl+C

nvm use 24
hash -r

node -v
which node
which openclaw

#


pnpm add -g openclaw@latest

openclaw gateway install --force
systemctl --user daemon-reload
openclaw gateway restart
openclaw gateway status

If it still points at v25.8.0, paste:

which -a openclaw
systemctl --user cat openclaw-gateway.service

#

We’re very close — Gateway works; systemd just needs to stop launching the stale v25 install. 🦐

cinder swan Apr 27, 2026, 1:25 PM

#

schergr@theclaw2:~$ nvm use 24
Now using node v24.15.0 (npm v11.12.1)
schergr@theclaw2:~$ hash -r
schergr@theclaw2:~$ node -v
v24.15.0
schergr@theclaw2:~$ which node
/home/schergr/.nvm/versions/node/v24.15.0/bin/node
schergr@theclaw2:~$ which openclaw
/home/schergr/.nvm/versions/node/v24.15.0/bin/openclaw

slow falconBOT Apr 27, 2026, 1:25 PM

#

Perfect — shell is now using the right Node/OpenClaw path.

Next run the service reinstall from that same shell:

pnpm add -g openclaw@latest

openclaw gateway install --force
systemctl --user daemon-reload
openclaw gateway restart
openclaw gateway status

If the status still mentions the old v25.8.0 path after that, show:

#

systemctl --user cat openclaw-gateway.service
which -a openclaw

cinder swan Apr 27, 2026, 1:25 PM

#

schergr@theclaw2:~$ pnpm add -g openclaw@latest
Command 'pnpm' not found, did you mean:
command 'npm' from deb npm (9.2.0~ds1-3)
Try: sudo apt install <deb name>

slow falconBOT Apr 27, 2026, 1:26 PM

#

No worries — Node 24 ships with Corepack, so enable pnpm first:

corepack enable
corepack prepare pnpm@latest --activate
pnpm -v

Then continue:

pnpm add -g openclaw@latest

openclaw gateway install --force
systemctl --user daemon-reload
openclaw gateway restart

#

openclaw gateway status

If corepack isn’t found, paste:

which corepack
node -p "process.execPath"

Don’t use the system npm from apt here — we want the install/service to stay under the same Node 24/nvm environment.

cinder swan Apr 27, 2026, 1:29 PM

#

schergr@theclaw2:~$ pnpm add -g openclaw@latest
openclaw gateway install --force
systemctl --user daemon-reload
openclaw gateway restart
ERR_PNPM_NO_GLOBAL_BIN_DIR Unable to find the global bin directory
Run "pnpm setup" to create it automatically, or set the global-bin-dir setting, or the PNPM_HOME env variable. The global bin directory should be in the PATH.
🦞 OpenClaw 2026.4.25 (aa36ee6) — Making 'I'll automate that later' happen now.
Installed systemd service: /home/schergr/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /home/schergr/.config/systemd/user/openclaw-gateway.service.bak
🦞 OpenClaw 2026.4.25 (aa36ee6) — The only open-source project where the mascot could eat the competition.
Restarted systemd service: openclaw-gateway.service
schergr@theclaw2:~$ openclaw gateway status
🦞 OpenClaw 2026.4.25 (aa36ee6) — iMessage green bubble energy, but for everyone.
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /home/schergr/.nvm/versions/node/v24.15.0/bin/node /home/schergr/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789
Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/schergr/.nvm/versions/node/v24.15.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/schergr/.nvm/versions/node/v24.15.0/bin/node)
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 (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 17044, 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
timeout
Capability: unknown
Port 18789 is already in use.

pid 17044 schergr: 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

slow falconBOT Apr 27, 2026, 1:29 PM

#

Good — the important part is fixed: the service now points at v24.15.0, not the old v25 path.

The pnpm error only means the global pnpm setup isn’t initialized; it didn’t block the service reinstall.

Can you paste the rest of openclaw gateway status after Probe note? The key lines are:

Runtime:
Connectivity probe:
Capability:

If it says Connectivity probe: ok, you’re basically done despite the “non-standard” warning.

For the pnpm warning, later you can fix it with:

#

pnpm setup
source ~/.bashrc
pnpm -v

For now I’d run:

openclaw doctor --repair
openclaw gateway restart
openclaw gateway status

Docs: https://docs.openclaw.ai/help/faq

#

This is progress: systemd is now running the v24 service and owns the port. The “Port 18789 is already in use” line is expected because the service itself is listening there.

But Connectivity probe: failed timeout means the process is bound but not answering the OpenClaw WS handshake yet. Give it ~30 seconds once, then rerun:

openclaw gateway status
curl -i http://127.0.0.1:18789/healthz
curl -i http://127.0.0.1:18789/readyz

If healthz/readyz work but WS still times out, paste:

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

If healthz also hangs, paste:

#

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

Likely remaining suspect is that broken plugin runtime deps / QMD memory error from earlier, but let’s confirm with the log before changing more.

cinder swan Apr 27, 2026, 1:35 PM

#

Runtime: running (pid 17044, 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
timeout
Capability: unknown

Port 18789 is already in use.

pid 17044 schergr: 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

slow falconBOT Apr 27, 2026, 1:35 PM

#

Since it’s still timing out after several minutes, it’s not just warm-up. The service is bound, but the Gateway control plane isn’t completing the WS probe.

Please grab HTTP + logs now:

curl -m 5 -i http://127.0.0.1:18789/healthz
curl -m 5 -i http://127.0.0.1:18789/readyz
tail -n 160 /tmp/openclaw/openclaw-2026-04-27.log

Given the earlier qmd memory unavailable ... Cannot find package 'chokidar' message, I’d also try the fastest safe bypass:

openclaw config set memory.backend builtin
openclaw gateway restart
openclaw gateway status

#

If the status becomes OK after that, QMD/plugin runtime deps were wedging startup and we can repair them separately.

cinder swan Apr 27, 2026, 1:37 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'm like tmux: confusing at first, then suddenly you can't live without me.
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /home/schergr/.nvm/versions/node/v24.15.0/bin/node /home/schergr/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789
Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/schergr/.nvm/versions/node/v24.15.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/schergr/.nvm/versions/node/v24.15.0/bin/node)
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 (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 17044, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

#

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Date: Mon, 27 Apr 2026 13:36:16 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 27

{"ok":true,"status":"live"}HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Date: Mon, 27 Apr 2026 13:36:16 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 45

{"ready":true,"failing":[],"uptimeMs":502616}

slow falconBOT Apr 27, 2026, 1:37 PM

#

Nice — that’s the green state. 🎉

Runtime: running
Connectivity probe: ok
Capability: admin-capable

So the Gateway is up and the systemd service is now working.

The remaining “non-standard” warning is because the service uses nvm’s Node path. It’s not fatal, but it can break when nvm versions change. For now I’d leave it alone unless you want to move to a system Node install later.

Final sanity check:

openclaw channels status --probe

#

openclaw status --deep

If those look good, you’re fixed.

#Gateway not starting after updating to Openclaw 2026.4.25