error while updating | Friends of the Crustacean 🦞🤝 | Page 1

thick breach Apr 27, 2026, 2:44 PM

#

kmandve@server:~$ openclaw update
Updating OpenClaw...

│
◇ ✓ Updating via package manager (18.26s)
│
◇ ✓ Running doctor checks (59.4s)

Update Result: ERROR
Root: /home/kmandve/.npm-global/lib/node_modules/openclaw
Reason: global install verify
Before: 2026.4.15
After: 2026.4.25

Total time: 78.28s
kmandve@server:~$

shadow oakBOT Apr 27, 2026, 2:44 PM

#

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

rapid flameBOT Apr 27, 2026, 2:45 PM

#

That summary is missing the important part: which file failed global install verify.

It did update from 2026.4.15 → 2026.4.25, but the package verification failed before the normal post-update follow-up.

Please run:

openclaw --version
openclaw update status
openclaw update --json --no-restart

Paste the JSON/error from the last command.

Likely recovery path, if you just want to repair the global npm install:

#

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm
openclaw doctor
openclaw gateway restart
openclaw health

Docs: https://docs.openclaw.ai/install/updating

Your ~/.openclaw state/config should be preserved; this is repairing the installed package tree under ~/.npm-global/lib/node_modules/openclaw.

thick breach Apr 27, 2026, 3:07 PM

#

kmandve@server:~$ openclaw update
Updating OpenClaw...

│
◇ ✓ Updating via package manager (8.7s)
│
◇ ✓ Running doctor checks (79.45s)

Update Result: OK
Root: /home/kmandve/.npm-global/lib/node_modules/openclaw
Before: 2026.4.25
After: 2026.4.25

Total time: 88.64s

Updating plugins...
No plugin updates needed.
Completion cache update failed: Error: spawnSync /home/linuxbrew/.linuxbrew/Cellar/node/25.7.0/bin/node ETIMEDOUT

Restarting service...
Gateway did not become healthy after restart.
Gateway version mismatch: expected 2026.4.25, running gateway reported unavailable.
Service runtime: status=running, state=active, pid=4836, lastExit=0
Gateway port 18789 status: free.
Restart log: /home/kmandve/.openclaw/logs/gateway-restart.log
Run openclaw gateway status --deep for details.

kmandve@server:~$

my openclaw isnt replying either and the terminal doesnt seem to be up

rapid flameBOT Apr 27, 2026, 3:08 PM

#

Update itself is OK now. The real problem is here:

service active, but gateway port 18789 is free

So the service wrapper is running, but the Gateway never actually started/listened. The completion-cache timeout is probably secondary.

Run/paste these:

openclaw --version
node --version
which node
which openclaw
openclaw gateway status --deep
tail -200 ~/.openclaw/logs/gateway-restart.log

#

Also try the repair path from the troubleshooting docs:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

One suspicious bit: it’s using Node 25.7.0. OpenClaw recommends Node 24, with Node 22.14+ supported; Node 25 may be causing weird startup behavior. Docs: https://docs.openclaw.ai/install/node and https://docs.openclaw.ai/gateway/troubleshooting#split-brain-installs-and-newer-config-guard

thick breach Apr 27, 2026, 3:08 PM

#

kmandve@server:~$ openclaw --version
node --version
which node
which openclaw
openclaw gateway status --deep
tail -200 ~/.openclaw/logs/gateway-restart.log
OpenClaw 2026.4.25 (aa36ee6)
v25.7.0
/home/linuxbrew/.linuxbrew/bin/node
/home/kmandve/.npm-global/bin/openclaw

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /home/linuxbrew/.linuxbrew/opt/node/bin/node /home/kmandve/.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 4854, 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
[2026-04-27T15:00:51Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-27T15:00:51Z] openclaw restart done source=update
[2026-04-27T15:04:21Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-27T15:04:21Z] openclaw restart done source=update
kmandve@server:~$

rapid flameBOT Apr 27, 2026, 3:09 PM

#

Good news: your Gateway is up now.

This part is healthy:

Runtime: running
Connectivity probe: ok
Listening: 127.0.0.1:18789
Capability: admin-capable

So the update/restart recovered. The completion-cache timeout is probably non-fatal.

For “not replying”, next check the channel/routing layer:

#

openclaw status --all
openclaw channels status --probe
openclaw pairing list discord
openclaw logs --follow

While openclaw logs --follow is running, send your bot a fresh test message and look for drops like mention required, pairing request, blocked, allowlist, or provider/model errors.

Also: you’re on Node 25.7.0. Gateway is alive, so don’t change five things at once, but if weird timeouts continue I’d move to Node 24 or 22 LTS and reinstall the gateway service afterward.

If by “terminal isn’t up” you mean the Dashboard/Control UI from another machine: your Gateway is loopback-only, so 127.0.0.1:18789 only works on the server itself. From your local machine, use:

ssh -N -L 18789:127.0.0.1:18789 kmandve@server

#

then open:

http://127.0.0.1:18789/

Docs: https://docs.openclaw.ai/channels/troubleshooting and https://docs.openclaw.ai/web/dashboard

thick breach Apr 27, 2026, 3:12 PM

#

15:04:20+00:00 info Gateway did not become healthy after restart.
15:04:20+00:00 info Gateway version mismatch: expected 2026.4.25, running gateway reported unavailable.
15:04:20+00:00 info Service runtime: status=running, state=active, pid=4836, lastExit=0
15:04:20+00:00 info Gateway port 18789 status: free.
15:04:20+00:00 info Restart log: /home/kmandve/.openclaw/logs/gateway-restart.log
15:04:20+00:00 info Run openclaw gateway status --deep for details.
15:04:20+00:00 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"25.7.0","hostname":"unknown","name":"openclaw","date":"2026-04-27T15:04:20.218Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/kmandve/.npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:152:46","fileName":"subsystem-BI-xRI3F.js","fileNameWithLine":"subsystem-BI-xRI3F.js:152","fileColumn":"46","fileLine":"152","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:152","method":"console.log"}},"time":"2026-04-27T15:04:20.219+00:00"}
15:04:24+00:00 info gateway {"subsystem":"gateway"} loading configuration…
15:04:24+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
15:04:24+00:00 info gateway {"subsystem":"gateway"} starting...
15:04:42+00:00 info gateway {"subsystem":"gateway"} starting HTTP server...
15:04:42+00:00 info gateway/canvas {"subsystem":"gateway/canvas"} canvas host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/kmandve/.openclaw/canvas)
15:04:42+00:00 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
15:04:43+00:00 info sessions/store {"subsystem":"sessions/store"}

rapid flameBOT Apr 27, 2026, 3:12 PM

#

This log actually confirms the Gateway did start, just slowly:

15:04:24 gateway starting...
15:04:42 starting HTTP server...
15:04:42 canvas host mounted at http://127.0.0.1:18789

So the update health check likely timed out before startup finished. Since gateway status --deep now says Connectivity probe: ok, the Gateway itself is fine.

Now troubleshoot the Discord/reply side:

openclaw status --all
openclaw channels status --probe
openclaw pairing list discord

#

openclaw logs --follow

While logs are following, send your OpenClaw bot a fresh message. Look for lines like:

mention required
pairing request
blocked
allowlist
model/provider error

If the “terminal” means the dashboard/control UI: it’s only on the server’s localhost. Use openclaw dashboard on the server, or SSH tunnel from your computer:

ssh -N -L 18789:127.0.0.1:18789 kmandve@server

#

then open http://127.0.0.1:18789/.

And yeah, Node 25.7.0 is suspicious. Once replies are fixed, I’d switch to Node 24 LTS and reinstall the gateway service.

thick breach Apr 27, 2026, 3:13 PM

#

im using telegram not discord, its replying just really slowly

rapid flameBOT Apr 27, 2026, 3:13 PM

#

Ah, got it — Telegram, not Discord. If it does reply but slowly, that’s a different path.

Check where the delay is:

openclaw channels status --probe
openclaw logs --follow

Then send one Telegram test message and watch timestamps. The important question is whether the delay is:

Telegram inbound/polling delay — logs don’t show your message quickly
→ likely Telegram polling/network/DNS/IPv6/proxy issue.
Agent/model delay — logs show the message quickly, then it thinks for ages
→ model/provider/tool latency, not Telegram.

#

Outbound send delay — final answer is ready in logs, but Telegram receives it late
→ Telegram API egress issue.

Given you’re on Node 25.7.0 and already saw spawnSync ... ETIMEDOUT, I’d strongly consider moving to Node 24 soon. But first grab the log timing so we don’t chase the wrong layer.

Telegram docs: https://docs.openclaw.ai/channels/telegram#troubleshooting

thick breach Apr 27, 2026, 3:14 PM

#

i think we need to fix gtihs:

15:13:01+00:00 info sessions/store {"subsystem":"sessions/store"} {"storePath":"/home/kmandve/.openclaw/agents/orbit-mini/sessions/sessions.json","before":949,"after":500,"pruned":1,"capped":448,"maxEntries":500} applied load-time maintenance to oversized session store

rapid flameBOT Apr 27, 2026, 3:14 PM

#

I don’t think that line is the thing to “fix” — it’s OpenClaw fixing it automatically.

It means:

before: 949 session entries
after: 500
pruned: 1 stale
capped: 448 old overflow entries

So sessions.json was oversized, and OpenClaw trimmed it back to the default maxEntries: 500. That could explain slow startup after restart, but not usually slow replies after the gateway is already running.

For slow Telegram replies, I’d check if the active chat session/context is huge. In Telegram send:

#

/status

Then try a fresh session:

/new

If replies become fast after /new, the issue was a heavy/old conversation context.

If you want to inspect cleanup safely:

openclaw sessions cleanup --agent orbit-mini --dry-run

#

Only if you’re okay removing old session entries/transcripts:

openclaw sessions cleanup --agent orbit-mini --enforce

Don’t manually edit sessions.json unless we have to. Docs: https://docs.openclaw.ai/cli/sessions

thick breach Apr 27, 2026, 3:15 PM

#

so how do i fix whatever issues im facing with it replying super slow

rapid flameBOT Apr 27, 2026, 3:15 PM

#

Fastest fix path: isolate the slow layer, then reset the expensive bits.

1) Reset the current Telegram session/context

In Telegram, send:

/status
/new

Then send a simple test like “ping”. If it gets fast, the old chat context/session was heavy.

2) Watch the timing

On the server:

#

openclaw logs --follow

Send one Telegram message and check:

message appears in logs late → Telegram polling/network issue
message appears immediately, but answer takes long → model/context/tool issue
answer is ready in logs, but Telegram receives late → Telegram API egress issue

3) Check Telegram health

openclaw channels status --probe
openclaw status --all

#

Look for polling stalls, Telegram API errors, provider/model latency, or tool hangs.

4) Strong recommendation: stop using Node 25

You’re on v25.7.0, and you already hit a Node timeout. OpenClaw recommends Node 24 / supports 22.14+. After switching to Node 24, reinstall/restart the service:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

The session-store line is probably not the problem — it already capped old entries from 949 to 500. The likely causes are big active context, model latency, Telegram polling/API latency, or Node 25 weirdness.

thick breach Apr 27, 2026, 3:16 PM

#

plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/vydra/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/web-readability/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/webhooks/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/whatsapp/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/xai/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/xiaomi/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/zai/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/zalo/openclaw.plugin.json
plugins: plugin: plugin manifest not found: /home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/zalouser/openclaw.plugin.json

rapid flameBOT Apr 27, 2026, 3:17 PM

#

Yep, that is fix-worthy. Missing bundled plugin manifests means the installed package tree is probably weird/corrupt or you have stale plugin load paths pointing into old bundled dirs.

Do this first:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --no-onboard
openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw status --all

If those manifest errors remain, check for stale plugin paths:

openclaw config get plugins.load.paths

#

openclaw plugins list --verbose

If plugins.load.paths contains paths under:

/home/kmandve/.npm-global/lib/node_modules/openclaw/dist/extensions/...

those should be removed — bundled plugins don’t need manual load paths.

After that, test Telegram with /new once. If it’s still super slow after the plugin errors are gone, I’d switch off Node 25 and use Node 24 next.

thick breach Apr 27, 2026, 3:26 PM

#

Diagnosis (read-only)

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

✓ Config: /home/kmandve/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 6249 kmandve: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: serve · daemon unknown · server.tail209771.ts.net
https: https://server.tail209771.ts.net
✓ Skills: 38 eligible · 0 missing · /home/kmandve/.openclaw/workspace
✓ Plugin compatibility (none)

Gateway restart attempts (tail): /home/kmandve/.openclaw/logs/gateway-restart.log
[2026-04-27T15:00:51Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-27T15:00:51Z] openclaw restart done source=update
[2026-04-27T15:04:21Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-27T15:04:21Z] openclaw restart done source=update
! Channel issues skipped (gateway unreachable)

Gateway health:
timeout

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

◇
kmandve@server:~$

rapid flameBOT Apr 27, 2026, 3:26 PM

#

That means the Gateway process is listening but not responding:

Port 18789 in use by openclaw-gateway
Gateway health: timeout
Channel issues skipped (gateway unreachable)

So fix the hung gateway first:

openclaw gateway stop
sleep 5
openclaw gateway start
openclaw gateway status --deep
openclaw health --verbose

#

If it still times out, grab the real failure:

openclaw logs --follow

and in another terminal run:

openclaw gateway restart

If stop doesn’t clear the port, check what’s stuck:

ps -p 6249 -o pid,ppid,stat,etime,cmd

#

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

At this point I’d also seriously move off Node 25.7.0 to Node 24. You’ve got startup timeouts + spawn timeouts + health timeouts, and Node 25 is the weird variable here. After switching Node, run:

npm i -g openclaw@latest
openclaw gateway install --force
openclaw gateway restart
openclaw status --all

thick breach Apr 27, 2026, 7:44 PM

#

how can i disable all crons

rapid flameBOT Apr 27, 2026, 7:45 PM

#

To pause all cron execution without deleting jobs, set the global scheduler off:

openclaw config set cron.enabled false --strict-json
openclaw gateway restart
openclaw cron status

That keeps the jobs saved, but they won’t run automatically.

To re-enable later:

openclaw config set cron.enabled true --strict-json
openclaw gateway restart

#

You can verify what exists, including disabled jobs:

openclaw cron list --all

There’s also an env override, OPENCLAW_SKIP_CRON=1, but for your case I’d use cron.enabled: false in config so it persists cleanly.

Docs: https://docs.openclaw.ai/automation/cron-jobs

thick breach Apr 27, 2026, 7:48 PM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /home/linuxbrew/.linuxbrew/opt/node/bin/node /home/kmandve/.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 9386, 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
kmandve@server:~$

rapid flameBOT Apr 27, 2026, 7:48 PM

#

That state means: systemd wrapper is alive, but Gateway hasn’t bound the port yet. So Telegram will be dead/slow until this is fixed.

First verify cron is actually disabled:

openclaw config get cron.enabled

If it prints false, crons are not the current blocker.

Now get the startup failure/hang logs:

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

#

If you want a quick clean restart:

openclaw gateway stop
sleep 5
openclaw gateway start
sleep 20
openclaw gateway status --deep

If it still says “service running but port not listening”, run it in foreground so the real error is visible:

openclaw gateway stop
OPENCLAW_SKIP_CRON=1 openclaw gateway --port 18789

#

Paste the last ~100 lines from that. Also, I’m increasingly suspicious of Node 25.7.0 here — once we see logs, the likely stable fix is switching to Node 24 and reinstalling the service.

thick breach Apr 27, 2026, 7:49 PM

#

{"0":"{"subsystem":"gateway"}","1":"starting channels and sidecars...","_meta":{"runtime":"node","runtimeVersion":"25.7.0","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T19:47:54.961Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/kmandve/.npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328:14","fileName":"subsystem-BI-xRI3F.js","fileNameWithLine":"subsystem-BI-xRI3F.js:328","fileColumn":"14","fileLine":"328","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328","method":"logToFile"}},"time":"2026-04-27T19:47:54.961+00:00"}
{"0":"{"subsystem":"gateway/tailscale"}","1":"serve enabled: https://server.tail209771.ts.net/ (WS via wss://server.tail209771.ts.net)","_meta":{"runtime":"node","runtimeVersion":"25.7.0","hostname":"unknown","name":"{"subsystem":"gateway/tailscale"}","parentNames":["openclaw"],"date":"2026-04-27T19:47:55.144Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/kmandve/.npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328:14","fileName":"subsystem-BI-xRI3F.js","fileNameWithLine":"subsystem-BI-xRI3F.js:328","fileColumn":"14","fileLine":"328","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-BI-xRI3F.js:328","method":"logToFile"}},"time":"2026-04-27T19:47:55.144+00:00"}
{"0":"{"subsystem":"gateway/hooks"}","1":"loaded 4 internal hook handlers","_meta":{"runtime":"node","runtimeVersion":"25.7.0","hostname":"unknown","name":"{"subsystem":"gateway/hooks"}","parentNames":["openclaw"],"date":"2026-04-27T19:47:55.167Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///h

rapid flameBOT Apr 27, 2026, 7:49 PM

#

That snippet isn’t enough yet — it shows startup reached “channels and sidecars”, not the failure.

For now, I’d isolate the two optional things that can slow/hang startup: cron and Tailscale Serve.

Run:

openclaw gateway stop
openclaw config set cron.enabled false --strict-json
openclaw config set gateway.tailscale.mode off
openclaw gateway start
sleep 20
openclaw gateway status --deep

If it still doesn’t listen, run foreground with startup tracing:

#

openclaw gateway stop
OPENCLAW_SKIP_CRON=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway --port 18789 --tailscale off

Then paste the lines after:

starting channels and sidecars...

especially any warn, error, startup trace, or last line before it stalls.

If disabling Tailscale makes it healthy, the issue is around Serve/Tailscale. If it’s still stuck with cron + Tailscale off, we’re looking at channel/plugin startup or Node 25.

thick breach Apr 27, 2026, 7:50 PM

#

wait lets degrade node to whatever is correct, help me do that then lets try this out

rapid flameBOT Apr 27, 2026, 7:50 PM

#

Yep — use Node 24. OpenClaw recommends Node 24; Node 22.14+ is supported, but don’t use Node 25 here.

Since your current Node is Linuxbrew, try this:

openclaw gateway stop

brew install node@24
brew unlink node
brew link --force --overwrite node@24

hash -r
node --version
which node

You want node --version to show v24.x.x.

#

Then reinstall OpenClaw under that Node and refresh the systemd service:

npm config set prefix "$HOME/.npm-global"
export PATH="$HOME/.npm-global/bin:$PATH"

npm i -g openclaw@latest

openclaw --version
node --version

openclaw gateway install --force
openclaw gateway restart
sleep 20
openclaw gateway status --deep
openclaw status --all

#

If brew link node@24 refuses because it’s keg-only, use this instead:

export PATH="$(brew --prefix node@24)/bin:$HOME/.npm-global/bin:$PATH"
node --version
npm i -g openclaw@latest
openclaw gateway install --force
openclaw gateway restart

After this, the service command should no longer point at Node 25.7.0.

thick breach Apr 27, 2026, 7:56 PM

#

Diagnosis (read-only)

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

✓ Config: /home/kmandve/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 14799 kmandve: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: serve · daemon unknown · server.tail209771.ts.net
https: https://server.tail209771.ts.net
✓ Skills: 38 eligible · 0 missing · /home/kmandve/.openclaw/workspace
✓ Plugin compatibility (none)

Gateway restart attempts (tail): /home/kmandve/.openclaw/logs/gateway-restart.log
[2026-04-27T15:00:51Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-27T15:00:51Z] openclaw restart done source=update
[2026-04-27T15:04:21Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-27T15:04:21Z] openclaw restart done source=update
! Channel issues skipped (gateway unreachable)

Gateway health:
timeout

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

◇
kmandve@server:~$

rapid flameBOT Apr 27, 2026, 7:56 PM

#

Still hung: it’s listening, but health RPC times out. Two things stand out:

Tailscale Serve is still enabled
Gateway is still not reachable enough to check channels

Disable Serve for now and restart cleanly:

openclaw config set gateway.tailscale.mode off
openclaw config set cron.enabled false --strict-json

openclaw gateway stop
sleep 5
openclaw gateway start
sleep 30

#

openclaw gateway status --deep
openclaw health --verbose

If health still times out, run foreground with trace:

openclaw gateway stop
OPENCLAW_SKIP_CRON=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway --port 18789 --tailscale off

Also confirm the Node switch actually stuck:

node --version

#

which node
openclaw gateway status --deep

In gateway status, the Command: line should point to Node 24, not /home/linuxbrew/.linuxbrew/Cellar/node/25.7.0/....

thick breach Apr 27, 2026, 8:03 PM

#

kmandve@server:~$ openclaw gateway status --deep
openclaw health --verbose

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /home/linuxbrew/.linuxbrew/opt/node@24/bin/node /home/kmandve/.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 15171, 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

rapid flameBOT Apr 27, 2026, 8:03 PM

#

Nice — this is the first actually healthy-looking state 🎉

Key wins:

Command: .../node@24/bin/node ...
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789

So Node 24 fixed the Gateway startup/health issue.

Next checks:

#

openclaw health --verbose
openclaw channels status --probe
openclaw status --all

Then test Telegram. If it’s still slow:

In Telegram send:

/new

On server watch timing:

#

openclaw logs --follow

Crons/Tailscale are likely still disabled from earlier. Confirm with:

openclaw config get cron.enabled
openclaw config get gateway.tailscale.mode

I’d keep Tailscale off until Telegram is stable. Re-enable crons later with:

openclaw config set cron.enabled true --strict-json
openclaw gateway restart

#

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

thick breach Apr 27, 2026, 8:04 PM

#

no matter what i say in telegram nothing is happening, even the typing indicator isnt starting

rapid flameBOT Apr 27, 2026, 8:05 PM

#

No typing indicator usually means Telegram updates aren’t reaching OpenClaw at all — not model slowness.

Run this bundle and paste the output, but do not paste your bot token:

openclaw channels status --probe
openclaw pairing list telegram
openclaw config get channels.telegram.enabled
openclaw config get channels.telegram.webhookUrl
openclaw logs --follow

Then, while logs are following, send the bot a Telegram DM like ping.

What to look for:

channels.telegram.enabled is not true → enable it:

#

  openclaw config set channels.telegram.enabled true --strict-json
  openclaw gateway restart

pairing list telegram shows a pending request → approve it.
webhookUrl is set unexpectedly → Telegram may be in webhook mode instead of polling.
logs show getUpdates, 409 conflict, fetch failed, or Telegram network errors → polling/token/network issue.
logs show nothing at all when you message Telegram → most likely Telegram channel isn’t started, wrong bot token/account, webhook conflict, or bot messages are going somewhere else.

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

thick breach Apr 27, 2026, 8:07 PM

#

kmandve@server:~$ openclaw channels status --probe
openclaw pairing list telegram
openclaw config get channels.telegram.enabled
openclaw config get channels.telegram.webhookUrl
openclaw logs --follow

🦞 OpenClaw 2026.4.25 (aa36ee6) — Greetings, Professor Falken

│
◇
Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/kmandve/.openclaw/openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: /home/kmandve/.openclaw/openclaw.json
Mode: local

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

🦞 OpenClaw 2026.4.25 (aa36ee6) — Less clicking, more shipping, fewer "where did that file go" moments.

No pending telegram pairing requests.

🦞 OpenClaw 2026.4.25 (aa36ee6) — I keep secrets like a vault... unless you print them in debug logs again.

true

🦞 OpenClaw 2026.4.25 (aa36ee6) — The only open-source project where the mascot could eat the competition.

Config path not found: channels.telegram.webhookUrl

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

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

rapid flameBOT Apr 27, 2026, 8:08 PM

#

Right — the Telegram checks are blocked because the Gateway wedged again:

Gateway not reachable: gateway timeout after 30000ms

So first isolate whether channel startup is hanging the Gateway.

Run this exactly:

openclaw gateway stop
sleep 5

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_CRON=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
  openclaw gateway --port 18789 --tailscale off

#

Leave that running, then in another terminal:

openclaw gateway status --deep
openclaw health --verbose

Interpret it

If health is OK with OPENCLAW_SKIP_CHANNELS=1 → a channel is hanging startup, probably Telegram.
If health still times out → core Gateway/plugin startup is hanging.

For logs, don’t use openclaw logs --follow while Gateway is unreachable. Use:

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

#

tail -250 /tmp/openclaw/openclaw-2026-04-27.log

If skip-channels works, temporarily disable Telegram to confirm:

openclaw config set channels.telegram.enabled false --strict-json
openclaw gateway restart
openclaw gateway status --deep

Then we can re-enable Telegram and fix the Telegram-specific issue.

thick breach Apr 27, 2026, 8:09 PM

#

Runtime: stopped (state inactive, sub dead, last exit 0, reason 1)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

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/kmandve/.openclaw/logs/gateway-restart.log

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

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

│
◇
[openclaw] Failed to start CLI: Error: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/kmandve/.openclaw/openclaw.json
Bind: loopback

Possible causes:

Gateway not yet ready to accept connections (retry after a moment)
TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
Gateway crashed or was terminated unexpectedly
Run openclaw doctor for diagnostics.
at Object.onClose (file:///home/kmandve/.npm-global/lib/node_modules/openclaw/dist/call-DkJ_z7yy.js:279:10)
at WebSocket.<anonymous> (file:///home/kmandve/.npm-global/lib/node_modules/openclaw/dist/client-BcOgCTuB.js:2359:23)
at WebSocket.emit (node:events:509:28)
at WebSocket.emitClose (/home/kmandve/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:263:12)
at emitErrorAndClose (/home/kmandve/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:1047:13)
at ClientRequest.<anonymous> (/home/kmandve/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:886:5)
at ClientRequest.emit (node:events:509:28)
at emitErrorEvent (node:_http_client:109:11)
at Socket.socketErrorListener (node:_http_client:593:5)
at Socket.emit (node:events:509:28)
kmandve@server:~$

rapid flameBOT Apr 27, 2026, 8:10 PM

#

That output is from checking the systemd service, but the foreground test I suggested won’t show as the service. If you ran:

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_CRON=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway ...

it needs to stay running in that terminal. If it exited, we need the error printed above/below it.

Please run:

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

Also restart normally once so we’re not left stopped:

#

openclaw gateway start
sleep 20
openclaw gateway status --deep

If it stops immediately again, paste the journal tail. The 1006 abnormal closure is just the CLI trying to connect to a gateway that isn’t actually running — not the root cause.

thick breach Apr 27, 2026, 8:10 PM

#

20:09:47 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/kmandve/.openclaw/canvas)
20:09:47 [gateway] startup trace: runtime.state 5.7ms total=17180.2ms
20:09:47 [gateway] startup trace: runtime.early 39.8ms total=17222.4ms
20:09:47 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
20:09:48 [sessions/store] applied load-time maintenance to oversized session store
20:09:49 [gateway] startup trace: http.bound 1492.9ms total=18715.4ms
20:09:49 [gateway] agent model: anthropic/claude-sonnet-4-6
20:09:49 [gateway] ready (7 plugins: acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice; 20.3s)
20:09:49 [gateway] log file: /tmp/openclaw/openclaw-2026-04-27.log
20:09:49 [gateway] security warning: dangerous config flags enabled: browser.ssrfPolicy.dangerouslyAllowPrivateNetwork=true. Run openclaw security audit.
20:09:49 [gateway] startup trace: post-attach.log 199.4ms total=18916.1ms
20:09:49 [gateway] startup trace: post-attach.update-check 1.2ms total=18918.2ms
20:09:49 [gateway] starting channels and sidecars...
20:09:49 [gateway] startup trace: sidecars.session-locks 9.7ms total=18930.4ms
20:09:49 [gateway] startup trace: sidecars.gmail-watch 0.0ms total=18931.5ms
20:09:49 [gateway] startup trace: sidecars.gmail-model 0.1ms total=18932.4ms
20:09:49 [hooks] loaded 4 internal hook handlers
20:09:49 [gateway] startup trace: sidecars.internal-hooks 360.8ms total=19294.0ms
20:09:49 [gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)

rapid flameBOT Apr 27, 2026, 8:10 PM

#

Perfect — that proves the core Gateway is healthy when channels are skipped. So the blocker is channel startup, and since Telegram is your only active channel target, it’s very likely Telegram startup/polling is hanging.

Now disable Telegram temporarily and start normally:

openclaw config set channels.telegram.enabled false --strict-json
openclaw gateway restart
sleep 20
openclaw gateway status --deep

If that’s healthy, re-enable Telegram with network-safe settings:

openclaw config set channels.telegram.enabled true --strict-json
openclaw config set channels.telegram.network.autoSelectFamily false --strict-json

#

openclaw gateway restart
sleep 30
openclaw gateway status --deep
openclaw channels status --probe

If it hangs again, Telegram network startup is the culprit. Then check Telegram egress:

dig +short api.telegram.org A
dig +short api.telegram.org AAAA
curl -I https://api.telegram.org
tail -200 /tmp/openclaw/openclaw-2026-04-27.log | grep -iE 'telegram|getUpdates|polling|fetch|network|409|error'

Also make sure you’re not still launching the normal service with OPENCLAW_SKIP_CHANNELS=1 in its env — the skip line should only appear for that foreground test, not normal operation.

thick breach Apr 27, 2026, 8:11 PM

#

lets try downgrading to another stable version, this is 4.25. do you know the most stable previous version

rapid flameBOT Apr 27, 2026, 8:12 PM

#

I’d try 2026.4.23, not 2026.4.24.

Reason: 2026.4.24/4.25 are both close to the plugin/runtime-deps + sidecar startup changes you’re tripping over. 2026.4.23 is the last stable before that cluster.

Run:

openclaw gateway stop
npm i -g openclaw@2026.4.23
openclaw --version
openclaw gateway install --force
openclaw gateway restart
sleep 30
openclaw gateway status --deep
openclaw channels status --probe

#error while updating

1) Reset the current Telegram session/context

2) Watch the timing

3) Check Telegram health

4) Strong recommendation: stop using Node 25

Interpret it