Active memory always timesout | Friends of the Crustacean 🦞🤝 | Page 1

junior dagger Apr 27, 2026, 2:57 PM

#

I try to use active memory but it always says timeout on my discord when i activate /verbose and trace

delicate pierBOT Apr 27, 2026, 2:57 PM

#

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

junior dagger Apr 27, 2026, 2:58 PM

#

"active-memory": {
"enabled": true,
"config": {
"enabled": true,
"agents": [
"main"
],
"allowedChatTypes": [
"direct"
],
"queryMode": "recent",
"promptStyle": "balanced",
"timeoutMs": 15000,
"maxSummaryChars": 220,
"persistTranscripts": false,
"logging": false
}
}

forest flowerBOT Apr 27, 2026, 2:58 PM

#

First thing: can you paste openclaw --version?

/trace probably isn’t causing the timeout — it’s just making the Active Memory timeout visible. Usually this means the Active Memory sub-agent or memory search backend is too slow / stuck.

Please run:

openclaw memory status --deep

Also check your Active Memory config has logging on while debugging:

plugins: {
  entries: {
    "active-memory": {

#

      enabled: true,
      config: {
        enabled: true,
        logging: true,
        queryMode: "recent",
        timeoutMs: 15000
      }
    }
  }
}

Then restart the gateway and watch logs for active-memory, memory sync failed, or embedding provider errors.

Two common fixes:

If you’re using a slow/local model, pin Active Memory to a fast model via config.model.

#

If memory search is timing out, fix the embedding provider/index first; Active Memory uses the normal memory_search pipeline.

Docs: https://docs.openclaw.ai/concepts/active-memory

#

This config is the safe default: direct messages only.

If you’re testing Active Memory inside a Discord server/thread/channel, this line means it should not run there:

"allowedChatTypes": ["direct"]

For Discord server/thread testing, try:

"allowedChatTypes": ["direct", "channel"],
"logging": true

Then restart the gateway.

#

Also, you still need to paste:

openclaw --version
openclaw memory status --deep

If it’s genuinely showing Active Memory: status=timeout, then /trace isn’t the problem — it’s just exposing the timeout. The likely causes are:

Active Memory is inheriting a slow main model.
memory_search / embeddings are slow or unhealthy.
timeoutMs: 15000 is too low for your setup.

For debugging, temporarily try:

#

"timeoutMs": 30000,
"logging": true

Docs: https://docs.openclaw.ai/concepts/active-memory

junior dagger Apr 27, 2026, 3:01 PM

#

OpenClaw 2026.4.24 (cbcfdf6)

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Making 'I'll automate that later' happen now.

│
◇
Memory Search (main)
Provider: qmd (requested: qmd)
Model: qmd
Sources: memory, sessions
Indexed: 225/38 files · 225 chunks
Dirty: no
Store: ~/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/workspace
Dreaming: 17 4 * * * (Europe/Madrid) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
Embeddings: ready
By source:
memory · 184/13 files · 184 chunks
sessions · 41/25 files · 41 chunks
Vector: ready
Batch: disabled (failures 0/0)
Recall store: 3 entries · 0 promoted · 3 concept-tagged · 2 spaced · scripts=3 latin
Recall path: ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-14T12:10:12.858Z
QMD audit: ~/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite · 36102144 bytes · 3 collections
Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent
Dream corpus: ~/.openclaw/workspace/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/memory/.dreams/session-ingestion.json

forest flowerBOT Apr 27, 2026, 3:02 PM

#

Your memory status --deep looks healthy: QMD ready, embeddings ready, vector ready, dirty=no. So I’d stop looking at the index first.

The timeout is probably the Active Memory sub-agent model call not finishing inside 15s.

Try this:

"active-memory": {
  "enabled": true,
  "config": {
    "enabled": true,
    "agents": ["main"],
    "allowedChatTypes": ["direct", "channel"],
    "queryMode": "message",
    "promptStyle": "balanced",
    "timeoutMs": 30000,

#

    "maxSummaryChars": 220,
    "persistTranscripts": false,
    "logging": true
  }
}

Then restart the gateway.

If that works, the important change was probably one of:

timeoutMs: 30000
queryMode: "message" — less context for the recall sub-agent
logging: true so logs show the resolved Active Memory provider/model

Also: you’re on 2026.4.24. There are memory/QMD fixes after that, so I’d update to latest first if possible.

#

After restart, send one test message with:

/verbose on
/trace on

Then paste the gateway log lines containing active-memory: — especially the one showing activeProvider= / activeModel=. That will tell us if it’s using a slow/local main model.

junior dagger Apr 27, 2026, 3:14 PM

#

no my gateway is locked...

forest flowerBOT Apr 27, 2026, 3:15 PM

#

Ah — if it says the Gateway is locked, that usually means another gateway is already listening on the port, not that there’s a stale lock file to delete.

Run:

openclaw gateway status

Look for:

Runtime: running
Connectivity probe: ok/failed
Listening: ...
Last gateway error: ...

If the error is another gateway instance is already listening / EADDRINUSE, fix is one of:

#

openclaw gateway restart

or close the other foreground openclaw gateway terminal/app instance.

Important: don’t delete random lock files — the gateway lock is the TCP port bind, default 18789.

Docs: https://docs.openclaw.ai/gateway/gateway-lock and https://docs.openclaw.ai/help/faq#gateway-ports-already-running-and-remote-mode

junior dagger Apr 27, 2026, 3:17 PM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/luisadmin/.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 7056, 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

forest flowerBOT Apr 27, 2026, 3:18 PM

#

That status means the problem is not Active Memory right now — the service process is “running”, but the Gateway socket is not listening:

Connectivity probe: failed
connect ECONNREFUSED 127.0.0.1:18789
Gateway port 18789 is not listening

Do this first:

openclaw gateway restart
sleep 10
openclaw gateway status

If it still says ECONNREFUSED, paste these logs:

#

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

Also, since you’re on 2026.4.24, I’d update once the gateway is stable:

openclaw update

Docs: https://docs.openclaw.ai/help/faq#gateway-ports-already-running-and-remote-mode

junior dagger Apr 27, 2026, 3:19 PM

#

this happen when i updated a few minutes ago when you suggest it

#

luisadmin@AE7:~$ openclaw gateway restart
sleep 10
openclaw gateway status

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

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.25 (aa36ee6) — Open source means you can see exactly how I judge your config.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/luisadmin/.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 7131, 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 7131 luisadmin: 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

forest flowerBOT Apr 27, 2026, 3:19 PM

#

Oof, sorry — if the update made the gateway stop listening, let’s stabilize that first and ignore Active Memory for a minute.

Please don’t run openclaw update again yet. Grab the actual startup error:

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

If you just need to get back online quickly, rollback to the last version that worked:

npm i -g openclaw@2026.4.24
openclaw doctor

#

openclaw gateway restart
openclaw gateway status

Use the same package manager you originally installed OpenClaw with; your service path looks like an npm global install.

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

#

Yep, this is a different failure now. The gateway is listening on 18789, but the probe times out, so it’s likely wedged during startup rather than “locked”:

pid 7131 openclaw-gateway
Listening: 127.0.0.1:18789
Connectivity probe: timeout

Sorry — pause the Active Memory changes for now. Please grab the startup logs:

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

Look for lines around:

#

starting channels and sidecars
ready
plugin
runtime deps
failed
error

If you need Discord back quickly, rollback to the last version that at least started:

npm i -g openclaw@2026.4.24
openclaw doctor
openclaw gateway restart
openclaw gateway status

Then we can return to Active Memory once the gateway is reachable again.

junior dagger Apr 27, 2026, 3:23 PM

#

the log is huge
runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-04-27T15:13:03.753Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/luisadmin/.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-27T17:13:03.754+02:00"}
{"0":"{"subsystem":"gateway"}","1":"starting HTTP server...","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T15:13:04.176Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/luisadmin/.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-27T17:13:04.177+02:00"}
{"0":"{"subsystem":"gateway/canvas"}","1":"canvas host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/luisadmin/.openclaw/canvas)","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway/canvas"}","parentNames":["openclaw"],"date":"2026-04-27T15:13:04.180Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/luisadmin/.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-

forest flowerBOT Apr 27, 2026, 3:23 PM

#

No need to paste the whole log — that snippet only shows early startup. We need the last relevant errors / where startup gets stuck.

Run these filtered commands:

LOG=/tmp/openclaw/openclaw-2026-04-27.log

grep -Ei 'ERROR|WARN|failed|timeout|ready|starting channels|sidecars|plugin|runtime deps|uncaught|unhandled|discord' "$LOG" | tail -n 200

And service logs:

journalctl --user -u openclaw-gateway.service --since "20 minutes ago" --no-pager \
  | grep -Ei 'ERROR|WARN|failed|timeout|ready|starting channels|sidecars|plugin|runtime deps|uncaught|unhandled|discord' \
  | tail -n 200

#

Also useful:

openclaw status --all

The key thing we’re looking for is whether it reaches ready and then hangs at starting channels and sidecars, or whether a plugin/channel crashes during startup.

junior dagger Apr 27, 2026, 3:24 PM

#

still huge grep -Ei 'ERROR|WARN|failed|timeout|ready|starting channels|sidecars|plugin|runtime deps|uncaught|unhandled|discord' "$LOG" | tail -n 200
{"0":"{"subsystem":"gateway"}","1":"ready (8 plugins: acpx, active-memory, browser, device-pair, discord, memory-core, phone-control, talk-voice; 5.8s)","meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T10:22:44.544Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/luisadmin/.npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy.js:337:14","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T12:22:44.544+02:00"}
{"0":"{"subsystem":"gateway"}","1":"security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.","meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T10:22:44.547Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/luisadmin/.npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy.js:337:14","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T12:22:44.547+02:00"}
{"0":"{"subsystem":"gateway"}","1":"starting channels and sidecars...","_meta":

forest flowerBOT Apr 27, 2026, 3:25 PM

#

That line is actually useful — it reaches:

ready (... 5.8s)
starting channels and sidecars...

Then the gateway probe times out. So the hang is likely channel/sidecar startup, not Active Memory.

To avoid huge logs, try this cleaner extractor:

LOG=/tmp/openclaw/openclaw-2026-04-27.log
node -e '
const fs=require("fs");
for (const l of fs.readFileSync(process.argv[1],"utf8").split(/\n/)) {

#

  try {
    const j=JSON.parse(l);
    const msg=j["1"] || "";
    if (/ready|starting channels|sidecars|channel startup failed|ERROR|WARN|timeout|discord|telegram|whatsapp|plugin/i.test(msg))
      console.log(`${j.time || ""} ${msg}`);
  } catch {}
}
' "$LOG" | tail -n 80

Next isolation test: temporarily skip channel startup and see if the gateway becomes reachable:

systemctl --user set-environment OPENCLAW_SKIP_CHANNELS=1
openclaw gateway restart

#

sleep 10
openclaw gateway status

If that makes Connectivity probe: ok, we know one channel/sidecar is wedging startup. Then undo it:

systemctl --user unset-environment OPENCLAW_SKIP_CHANNELS

Don’t forget that with OPENCLAW_SKIP_CHANNELS=1, Discord/Telegram/etc won’t start — it’s just a diagnostic.

junior dagger Apr 27, 2026, 3:28 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — Welcome to the command line: where dreams compile and confidence segfaults.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/luisadmin/.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 7331, 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 7331 luisadmin: 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
luisadmin@AE7:~$

forest flowerBOT Apr 27, 2026, 3:29 PM

#

That still looks like the same startup wedge. Did you run the OPENCLAW_SKIP_CHANNELS=1 test before this status?

Please run this exact sequence so we know it applied:

systemctl --user stop openclaw-gateway.service
systemctl --user set-environment OPENCLAW_SKIP_CHANNELS=1
systemctl --user show-environment | grep OPENCLAW_SKIP_CHANNELS
systemctl --user start openclaw-gateway.service
sleep 10
openclaw gateway status

Then check for the skip log:

#

journalctl --user -u openclaw-gateway.service --since "5 minutes ago" --no-pager \
  | grep -Ei 'ready|starting channels|skipping channel start|channel startup failed|error|timeout'

If OPENCLAW_SKIP_CHANNELS=1 makes the probe OK, a channel/sidecar is hanging. If it still times out, rollback for now:

npm i -g openclaw@2026.4.24
openclaw doctor
openclaw gateway restart

And when you’re done testing, remove the skip env:

#

systemctl --user unset-environment OPENCLAW_SKIP_CHANNELS

junior dagger Apr 27, 2026, 3:30 PM

#

openclaw gateway status
OPENCLAW_SKIP_CHANNELS=1

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

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/luisadmin/.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 7448, 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 7448 luisadmin: 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
luisadmin@AE7:~$

forest flowerBOT Apr 27, 2026, 3:30 PM

#

OPENCLAW_SKIP_CHANNELS=1 didn’t apply there — it was printed after openclaw gateway status, and it won’t affect an already-running systemd service.

Run exactly:

systemctl --user stop openclaw-gateway.service
systemctl --user set-environment OPENCLAW_SKIP_CHANNELS=1
systemctl --user show-environment | grep OPENCLAW_SKIP_CHANNELS
systemctl --user start openclaw-gateway.service
sleep 15
openclaw gateway status

If that shows Connectivity probe: ok, then a channel/sidecar is hanging startup.

If it still times out, I’d rollback now:

#

npm i -g openclaw@2026.4.24
openclaw doctor
openclaw gateway restart

After testing, remove the diagnostic env:

systemctl --user unset-environment OPENCLAW_SKIP_CHANNELS

junior dagger Apr 27, 2026, 3:32 PM

#

luisadmin@AE7:~$ systemctl --user stop openclaw-gateway.service
systemctl --user set-environment OPENCLAW_SKIP_CHANNELS=1
systemctl --user show-environment | grep OPENCLAW_SKIP_CHANNELS
systemctl --user start openclaw-gateway.service
sleep 15
openclaw gateway status
OPENCLAW_SKIP_CHANNELS=1

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'm not AI-powered, I'm AI-possessed. Big difference.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/luisadmin/.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 7510, 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 7510 luisadmin: 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

forest flowerBOT Apr 27, 2026, 3:32 PM

#

Ok, that confirms it: even with OPENCLAW_SKIP_CHANNELS=1, the gateway still times out. So this is probably not Discord/Telegram/channel startup anymore — looks like a 2026.4.25 startup regression / gateway event-loop wedge.

I’d rollback now:

systemctl --user unset-environment OPENCLAW_SKIP_CHANNELS

npm i -g openclaw@2026.4.24
openclaw doctor
openclaw gateway restart
sleep 15
openclaw gateway status

If 2026.4.24 also stays wedged, go one version lower:

#Active memory always timesout