Help! Help!

[bronze tulip]

Help! Help! Why has my OpenCLAW agent stopped working continuously and proactively? It claims to keep working after each conversation but actually stops working. It won't send me messages proactively, nor will it complete the tasks set in the role configuration. Also, I want to ask: do multiple agents use the same port, or do they need different separate ports?

[sinful shoal]

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

[jaunty birch]

OpenClaw doesn’t “run continuously” just because the role/agent description says it should. By default it’s reactive (runs when a message/event comes in). Anything “proactive” needs one of the scheduler mechanisms and the Gateway must be up 24/7.

Why it “stops working” / no proactive messages

Most common causes:

1. Gateway isn’t running as a daemon 24/7

• If you started it in a terminal and the terminal closes, or your laptop sleeps/reboots, background work stops.
• Check:

  openclaw gateway status
  

2. Heartbeats are running but not delivering anywhere
   Heartbeat is the built-in “check periodically” mechanism — but delivery defaults to none.
   So it can run and do nothing visible.

To actually get proactive pings, set (global or per-agent):

{
  agents: {
    defaults: {
      heartbeat: {
        every: "30m",
        target: "last" // key bit: deliver to your last chat; default is "none"
      }
    }
  }
}

Docs: https://docs.openclaw.ai/gateway/heartbeat

3. You expected “role tasks” to execute automatically
   The role/system prompt influences behavior when the agent runs, but it won’t self-trigger runs. For scheduled work use:

• Heartbeat (periodic “check + nudge”)

• Cron jobs (exact schedules)
  Docs: https://docs.openclaw.ai/automation/cron-jobs and https://docs.openclaw.ai/automation/cron-vs-heartbeat

Ports: multiple agents vs multiple gateways

• Multiple agents inside one Gateway: they all share the same Gateway port (default 18789) because the Gateway multiplexes everything.
• Multiple Gateways on the same machine: they must use different ports and separate state/workspace (usually via profiles).
  FAQ section: https://docs.openclaw.ai/help/faq#what-port-does-the-gateway-use and https://docs.openclaw.ai/help/faq#can-i-run-multiple-gateways-on-the-same-host

Fastest debug info to paste here

Run these and paste output (they redact secrets):

openclaw --version
openclaw status --all
openclaw gateway status

Also: which channel are you expecting proactive messages on (Telegram/WhatsApp/Discord/etc.)? That matters for where heartbeat/crons should deliver.

[bronze tulip]

yunshenjia@yunshenjia3:~$ openclaw --version
OpenClaw 2026.3.13 (61d171a)
yunshenjia@yunshenjia3:~$ openclaw status --all

🦞 OpenClaw 2026.3.13 (61d171a) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

12:41:48 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
│
12:41:51 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
◑ Checking services….[qqbot] resolveAllowFrom: accountId=liuyi, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liuer, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liusan, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liusi, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liuwu, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=xiaodi, allowFrom=[""]
OpenClaw status --all

Overview
│ Version │ 2026.3.13 │
│ OS │ linux 6.8.0-106-generic (x64) │
│ Node │ 22.22.1 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://192.168.1.163:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.3.13 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (connect failed: connect ECONNREFUSED 127.0.0.1:18789) │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown
│ Gateway service │ systemd installed · enabled · stopped
│ Node service │ systemd not installed
│ Agents │ 7 total · 1 bootstrapping · 3 active · 13 sessions

[jaunty birch]

Your openclaw --version looks fine (2026.3.13). But the openclaw status --all output you pasted never reached the actual “gateway health / RPC probe / models / channels” part — it stopped at “Checking services…”. That usually means the CLI is either:

• stuck waiting for the Gateway RPC/WebSocket, or
• the Gateway is unhealthy / not running continuously.

1) First: confirm the Gateway is actually up (this is the #1 cause of “it stops working”)

Please run and paste:

openclaw gateway status

What matters in that output:

• whether RPC probe is ok
• what Probe target URL it’s trying
• any Last gateway error

If RPC probe is failing, proactive/cron/heartbeat won’t run because there’s no always-on process.

Docs (same checklist): https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken

---

2) Why you get no proactive messages even when things are working

Heartbeat exists for “proactive” behavior — but delivery defaults to off.

From the Heartbeat docs: target default is "none" (run heartbeat, but don’t send messages anywhere).
So you can be thinking “it’s running” while you receive nothing.

Check your current heartbeat config:

openclaw config get agents.defaults.heartbeat

If you want it to message you proactively, set e.g.:

openclaw config set agents.defaults.heartbeat.target "last"
openclaw config set agents.defaults.heartbeat.every "30m"
openclaw gateway restart

Docs: https://docs.openclaw.ai/gateway/heartbeat

Quick test (forces an immediate heartbeat run)

After setting target: "last", send yourself a message once (so “last” is defined), then run:

openclaw system event --text "heartbeat test: send me a message now" --mode now

---

3) “Tasks in the role configuration” won’t execute by themselves

Role/system prompt influences behavior when the agent runs, but it won’t self-trigger runs.

If you want “continue working after the conversation” you typically do one of:

• Heartbeat + a small HEARTBEAT.md checklist (lightweight ongoing assistant behavior)
• Cron jobs for real scheduled tasks (exact times, reliable)
  Docs: https://docs.openclaw.ai/automation/cron-jobs and https://docs.openclaw.ai/automation/cron-vs-heartbeat

---

4) Ports: multiple agents vs multiple gateways

• Multiple agents under one Gateway: same port (default 18789) — they’re internal.
• Multiple gateways on one host: need different ports + separate state/workspaces (profiles).

FAQ: https://docs.openclaw.ai/help/faq#what-port-does-the-gateway-use

---

If you paste openclaw gateway status, I can tell you immediately whether this is (a) gateway not actually running, (b) remote-mode/probe target mismatch, or (c) heartbeat delivery just set to none.

That output explains the whole “it stops / not proactive” behavior:

Gateway: unreachable (ECONNREFUSED 127.0.0.1:18789)
Gateway service: systemd installed · enabled · stopped

If the Gateway service is stopped, nothing can run in the background (no heartbeats, no cron, no “keep working after the chat”).

Fix 1: start (and keep) the Gateway running

On Linux, do:

openclaw gateway start
openclaw gateway status

If it still shows “stopped” or it starts then immediately stops, grab logs:

openclaw logs --follow
# or (systemd user unit)
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Important (common VPS gotcha): systemd user services stop after logout

If this is a VPS/SSH box, you usually need lingering so it stays up 24/7:

sudo loginctl enable-linger $USER

Docs: https://docs.openclaw.ai/gateway#supervision-and-service-lifecycle

Fix 2: “proactive messages” need heartbeat delivery

Even when the Gateway is running, heartbeat delivery defaults to target: "none", so you won’t receive messages unless you set a target.

Quick enable:

openclaw config set agents.defaults.heartbeat.target "last"
openclaw config set agents.defaults.heartbeat.every "30m"
openclaw gateway restart

Docs: https://docs.openclaw.ai/gateway/heartbeat

(And if you want it to do specific tasks, put them in HEARTBEAT.md or use cron jobs.)

Port question (again, but confirmed)

• Multiple agents on one Gateway: same port (default 18789).
• Multiple gateways on same host: need different ports + separate profiles/state/workspaces.

Once you run openclaw gateway start, paste openclaw gateway status — especially if it stops again — and we can tell whether it’s crashing (often a plugin error) vs just not being kept alive after logout.

[bronze tulip]

┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ QQ Bot │ ON │ OK │ configured · accounts 6/6

QQ Bot accounts
┌───────────────────────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├───────────────────────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ liuyi (六一（总经理）) │ OK │ token:config · allow:* │
│ liuer (六二（技术总监）) │ OK │ token:config · allow:* │
│ liusan (六三（股票总监）) │ OK │ token:config · allow:* │
│ liusi (六四（情报总监）) │ OK │ token:config · allow:* │
│ liuwu (六五（写作总监）) │ OK │ token:config · allow:* │
│ xiaodi (小弟（专属陪伴）) │ OK │ token:config · allow:*

Agents
┌───────────────────────────┬────────────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├───────────────────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────┤
│ main │ PRESENT │ 7 │ 7m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
│ liuer (六二（技术总监）) │ ABSENT │ 1 │ 26m ago │ ~/.openclaw/agents/liuer/sessions/sessions.json │
│ liusan (六三（股票总监）) │ ABSENT │ 1 │ 10m ago │ ~/.openclaw/agents/liusan/sessions/sessions.json │
│ liusi (六四（情报总监）) │ ABSENT │ 1 │ 15m ago │ ~/.openclaw/agents/liusi/sessions/sessions.json │
│ liuwu (六五（写作总监）) │ ABSENT │ 1 │ 1m ago │ ~/.openclaw/agents/liuwu/sessions/sessions.json │
│ liuyi (六一（总经理）) │ ABSENT │ 1 │ 1m ago │ ~/.openclaw/agents/liuyi/sessions/sessions.json │
│ xiaodi (小弟（专属陪伴）) │ ABSENT │ 1 │ 15h ago │ ~/.openclaw/agents/xiaodi/sessions/sessions.json

Diagnosis (read-only)

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

✓ Config: /home/yunshenjia/.openclaw/openclaw.json
✓ Restart sentinel: none
✓ Port 18789
! Tailscale: off · unknown
error: Error: spawn tailscale ENOENT
✓ Skills: 8 eligible · 0 missing · /home/yunshenjia/.openclaw/workspace
! Channel issues skipped (gateway unreachable)

Gateway health:
connect failed: connect ECONNREFUSED 127.0.0.1:18789

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

yunshenjia@yunshenjia3:~$ openclaw gateway status

🦞 OpenClaw 2026.3.13 (61d171a) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.qqbot: multiple accounts are configured but no explicit default is set. Set │
│ channels.qqbot.defaultAccount or add channels.qqbot.accounts.default to avoid fallback │
│ routing. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
12:42:06 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.

12:42:06 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-17.log
Command: /usr/bin/node /home/yunshenjia/.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.1.163:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

[jaunty birch]

Nice — that shows the QQ Bot channel config is loaded and looks sane (ON · OK · accounts 6/6).

But it doesn’t change the key issue from your earlier status --all:

Gateway service was stopped + ws://127.0.0.1:18789 was ECONNREFUSED

Channels can be “configured OK” while the Gateway is down — and if the Gateway is down, nothing runs (no proactive sends, no background work).

Next 2 checks (please paste both)

1) Is the Gateway running right now?

openclaw gateway status

2) Can the CLI actually reach it?

openclaw status

If gateway status says it starts and then stops again, paste logs:

openclaw logs --follow
# or:
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

After the Gateway is up: make “proactive” actually deliver somewhere

Please also paste:

openclaw config get agents.defaults.heartbeat

For most people the fix is simply:

• heartbeat is enabled, but target is "none", so you never receive anything.

Setting target: "last" is the easiest way to verify proactive works (it will message the last chat you used, e.g. QQ if that’s where you talk to it).

Once you share openclaw gateway status + openclaw config get agents.defaults.heartbeat, I can tell you exactly what to change for your setup.

[bronze tulip]

Runtime: stopped (state inactive, sub dead, last exit 0, reason 1)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /home/yunshenjia/.openclaw/openclaw.json

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-03-17.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

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

[jaunty birch]

Yep — those QQ Bot accounts are configured and “OK” (tokens present, allow:*). That’s good, but it’s not the reason you’re not getting proactive messages.

Your earlier status --all already showed the real blocker:

• Gateway unreachable (ECONNREFUSED 127.0.0.1:18789)
• Gateway service: … stopped

If the Gateway is stopped, the QQ bot (and heartbeats/cron) can’t run in the background, no matter how many accounts are configured.

Please run these 2 commands (these are the ones that matter)

openclaw gateway status
openclaw status

If it’s still stopped, start it:

openclaw gateway start
openclaw gateway status

If it starts and then stops again, paste logs:

openclaw logs --follow
# or:
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Then we fix “proactive”

Also paste:

openclaw config get agents.defaults.heartbeat

Because by default heartbeat delivery is target: "none", so even a healthy gateway may never message you proactively until you set target: "last" (or a specific channel).

One more note (not the current bug, just important): allow:* means anyone can message/control those QQ accounts. Once things work, you probably want to tighten that allowlist.

That “Agents” table is just telling us you have 7 agents + their session stores on disk. 👍 It doesn’t mean the Gateway is currently running.

The one line that matters for “continuous / proactive” is still from your Overview:

Gateway … unreachable (ECONNREFUSED 127.0.0.1:18789)
Gateway service … stopped

If the Gateway is stopped, none of those agents can run in the background.

Do this now (Linux)

1) Start the Gateway service

Prefer the systemd “enable + start now” form:

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

(or the OpenClaw wrapper)

openclaw gateway start

2) Confirm it’s actually reachable

openclaw gateway status
openclaw status

3) If it stops again, paste the reason

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

To keep it running after you logout (needed for “continuous”)

On many VPS/SSH setups, systemd user services stop on logout unless lingering is enabled:

sudo loginctl enable-linger $USER

Docs: https://docs.openclaw.ai/gateway#supervision-and-service-lifecycle

After the Gateway is up: enable proactive delivery

Please paste this (so we can see if delivery is set to none):

openclaw config get agents.defaults.heartbeat

(Heartbeat commonly “works” but sends nothing because target defaults to "none".)

---

Also answering your port question clearly: all 7 agents use the same Gateway port (18789 by default). Only multiple gateways need separate ports.

If you paste openclaw gateway status after starting, we can finish this quickly.

This is still the same root issue:

Gateway health: connect ECONNREFUSED 127.0.0.1:18789
Meaning: nothing is listening on port 18789 (Gateway is not running, or it crashed immediately).

Also important detail from your diagnosis:

Bind: lan

When gateway.bind is lan, the Gateway will refuse to start unless auth is configured (token/password). If auth is missing/misconfigured, systemd will start → crash → end up “stopped”, and you get ECONNREFUSED.

Next step (most useful output)

Please run and paste:

openclaw gateway status

That command usually prints “Last gateway error” which tells us exactly why it won’t stay up (auth required, port in use, plugin crash, etc.).

If openclaw gateway status isn’t informative enough, paste:

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

If the error is “refusing to bind … without auth” (common with bind: lan)

Then fix is:

1. Ensure you have a token (Doctor can generate one into config):

openclaw doctor --generate-gateway-token

2. Confirm auth is set (paste output):

openclaw config get gateway.auth

3. Restart:

openclaw gateway restart

Docs for the bind/auth rule: https://docs.openclaw.ai/help/faq#i-set-gatewaybind-lan-or-tailnet-and-now-nothing-listens-the-ui-says-unauthorized

Once the Gateway is actually running, then we can fix the “proactive” part (heartbeat delivery target), but right now you’re blocked at “Gateway not up.”

That openclaw gateway status paste is cut off before the important part (the table that shows Runtime, Listening, RPC probe, and Last gateway error). Right now we only see warnings, not the actual gateway/service state.

Please re-run it in a paste-friendly way and paste the full output:

Option A (best): JSON (no spinner / no truncation)

openclaw gateway status --json

Option B: service-only view (skips the RPC probe that can “hang”)

openclaw gateway status --no-probe --no-color

Why this matters: we need to see one of these in the output:

• Gateway service: stopped (then you just need to start it / enable linger), or
• Last gateway error: refusing to bind … without auth (common with bind: lan), or

• Port in use / crash loop (often from a plugin), etc.

Also: the QQBot “no explicit default account” warning is real (you should set channels.qqbot.defaultAccount eventually), but it won’t cause ECONNREFUSED. The refused connection means the Gateway is not listening at all.

Paste gateway status --json and we’ll know exactly what’s killing it.

[bronze tulip]

yunshenjia@yunshenjia3:~$ systemctl --user status openclaw-gateway.service --no-pager
● openclaw-gateway.service - OpenClaw Gateway (v2026.3.13)
Loaded: loaded (/home/yunshenjia/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: active (running) since Tue 2026-03-17 12:52:59 CST; 3s ago
Main PID: 8419 (node)
Tasks: 7 (limit: 115860)
Memory: 228.0M (peak: 228.0M)
CPU: 5.084s
CGroup: /user.slice/user-1000.slice/[e-mail]/app.slice/openclaw-gateway.service
└─8419 /usr/bin/node /home/yunshenjia/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789

3月 17 12:52:59 yunshenjia3 systemd[1541]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.3.13).

[jaunty birch]

Perfect — the Gateway service is running now:

Active: active (running) … openclaw … gateway --port 18789

That was the hard blocker. With the Gateway stopped you’ll never get “continuous/proactive”.

1) Confirm the CLI can reach the running Gateway now

Please run:

openclaw status
# or:
openclaw gateway status --no-probe --no-color

If it still says ECONNREFUSED 127.0.0.1:18789 even though systemd shows it running, then the Gateway is likely not listening on loopback (only on your LAN IP). Quick check:

ss -ltnp | grep 18789

You should see something like 127.0.0.1:18789 or 0.0.0.0:18789 (either is fine). If it’s only bound to 192.168.1.163:18789, that explains why loopback probes fail.

2) Make it “continuous” across logout/reboot (Linux systemd user service)

If this is a VPS/SSH box: user services often stop when you log out unless lingering is enabled:

sudo loginctl enable-linger $USER

Docs: https://docs.openclaw.ai/gateway#linux-systemd-user

3) Make it “proactive” (this is separate from “gateway is running”)

Now you need heartbeat/cron delivery. Paste this so we can see what you have:

openclaw config get agents.defaults.heartbeat

Common situation: heartbeat is enabled but target is "none" (so it runs but never messages you). The usual starter config is:

• every: "30m"
• target: "last"

Also: since you have 7 agents, decide which agent should be proactive (running heartbeats on all 7 can get expensive/noisy). If you tell me “I want only xiaodi to be proactive”, I can show the clean per-agent heartbeat config for that.

Once you run openclaw status + ss -ltnp | grep 18789 + your heartbeat config, we can finish the setup.

[bronze tulip]

yunshenjia@yunshenjia3:~$ openclaw config set agents.defaults.heartbeat.target "last"

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

│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.qqbot: multiple accounts are configured but no explicit default is set. Set │
│ channels.qqbot.defaultAccount or add channels.qqbot.accounts.default to avoid fallback │
│ routing. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
12:55:45 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
Config overwrite: /home/yunshenjia/.openclaw/openclaw.json (sha256 72b746960e85741cc68c79b0ed33a0d0adde84192c503108f47697f2739934fb -> ae28441e011f89dc559d6b017e4bc6b9b755f2a7ba491a84df4442f560752981, backup=/home/yunshenjia/.openclaw/openclaw.json.bak)
Updated agents.defaults.heartbeat.target. Restart the gateway to apply.

yunshenjia@yunshenjia3:~$ openclaw config set agents.defaults.heartbeat.every "30m"

🦞 OpenClaw 2026.3.13 (61d171a) — Half butler, half debugger, full crustacean.

│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.qqbot: multiple accounts are configured but no explicit default is set. Set │
│ channels.qqbot.defaultAccount or add channels.qqbot.accounts.default to avoid fallback │
│ routing. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
12:55:55 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
Config overwrite: /home/yunshenjia/.openclaw/openclaw.json (sha256 ae28441e011f89dc559d6b017e4bc6b9b755f2a7ba491a84df4442f560752981 -> f22b2e6812a676a9df57cf962ff26bb7182c159221da6bb204cb70f6c3872d34, backup=/home/yunshenjia/.openclaw/openclaw.json.bak)
Updated agents.defaults.heartbeat.every. Restart the gateway to apply.

[jaunty birch]

Good — you’ve now set agents.defaults.heartbeat.target = "last". ✅
And the CLI is telling you the next required step:

“Restart the gateway to apply.”

1) Restart the Gateway

openclaw gateway restart

Then verify it’s reachable:

openclaw status

2) (Strongly recommended) Fix the QQBot “no default account” warning

This warning can bite you later when OpenClaw needs to pick an account for outbound sends.

Pick one of your QQ bot accounts to be the default (for example the one you mainly use), then:

openclaw config set channels.qqbot.defaultAccount "xiaodi"
openclaw gateway restart

(Replace "xiaodi" with whichever account you want as default.)

3) Quick “does proactive delivery work?” test

After restart, send a message to the bot on QQ (so QQ becomes the “last” chat), then force a heartbeat tick:

openclaw system event --text "Heartbeat test: send me a short message now (not HEARTBEAT_OK)" --mode now

If you still get nothing after this, paste:

openclaw config get agents.defaults.heartbeat
openclaw status

One more heads-up: setting heartbeat under agents.defaults means all 7 agents may start running heartbeats (cost/noise). Once it works, we can narrow it to only the one agent you actually want to be proactive.

Great — now you’ve set both the delivery target and the interval. ✅ You’re at the “apply it” step for both changes: ## 1) Restart the gateway (required) bash openclaw gateway restart Then sanity-check the merged heartbeat config: bash openclaw config get agents.defaults.heartbeat openclaw status ## 2) (Recommended) Set a default QQBot account to remove the warning Pick the one you want OpenClaw to use when it can’t infer an account: bash openclaw config set channels.qqbot.defaultAccount "xiaodi" openclaw gateway restart ## 3) Quick test (force a heartbeat run + message) 1) Send any message to the bot on QQ (so QQ becomes the “last” chat) 2) Then run: bash openclaw system event --text "Heartbeat test: send me a short message now (not HEARTBEAT_OK)" --mode now If that still doesn’t produce an outbound message, paste: bash openclaw config get agents.defaults.heartbeat openclaw logs --follow (At that point it’s usually either “last target can’t be resolved to a concrete QQ destination/account” or heartbeats are firing but the reply is getting suppressed as ``.)

[bronze tulip]

yunshenjia@yunshenjia3:~$ openclaw system event --text "Heartbeat test: send me a short message now (not HEARTBEAT_OK)" --mode now

🦞 OpenClaw 2026.3.13 (61d171a) — I read logs so you can keep pretending you don't have to.

│
13:10:58 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
gateway connect failed: Error: gateway closed (1000):
◇
Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/yunshenjia/.openclaw/openclaw.json
Bind: lan
yunshenjia@yunshenjia3:~$

[jaunty birch]

That error is progress: you’re no longer getting ECONNREFUSED — you are reaching something on 127.0.0.1:18789, but the WebSocket is being closed immediately:

gateway closed (1000 normal closure)

The two most common reasons for this in OpenClaw are:

1. Gateway auth mismatch / missing token in your CLI environment (service has a token, but your CLI call isn’t sending it), or
2. You’re connecting to the wrong listener/interface (less common, but possible with bind: lan).

Let’s pin down which one it is.

A) Confirm what address is actually listening on 18789

Run:

ss -ltnp | grep 18789

• If you see 127.0.0.1:18789 or 0.0.0.0:18789 → good (loopback is reachable)
• If you only see 192.168.x.x:18789 → loopback probes can behave weird; you should target that IP explicitly.

B) Check your gateway auth mode (don’t paste the token value)

Run these and paste output but redact the token if it prints one:

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

What we’re looking for:

• mode is usually "token"
• token should be present (not null/empty)

Why this matters

Your Gateway service can be running with a token coming from systemd env / env files, while your interactive shell doesn’t have it. In that case, CLI commands (like openclaw system event) connect but then get closed because they’re unauthenticated.

C) Get the gateway status in service-only mode (no probe)

This prints the service view without trying to RPC-probe:

openclaw gateway status --no-probe --no-color

Paste that whole output.

---

Once we confirm auth is the issue, the clean fix is: make sure the same token is available to both

• the service and
• your CLI shell (usually by putting it in ~/.openclaw/openclaw.json under gateway.auth.token or in ~/.openclaw/.env), then restart the gateway.

Also: the plugins.allow is empty warning is just noise here; it won’t cause the 1000 close by itself.

[bronze tulip]

yunshenjia@yunshenjia3:~$ ss -ltnp | grep 18789
LISTEN 0 511 0.0.0.0:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=9555,fd=22))
yunshenjia@yunshenjia3:~$

[jaunty birch]

Good — that confirms the bind/listener is fine:

LISTEN 0.0.0.0:18789 … openclaw-gateway

So the earlier failure:

gateway closed (1000 normal closure) … Gateway target ws://127.0.0.1:18789 … Bind: lan

is almost certainly gateway auth (token/password) — the Gateway is up, but it’s closing the WS because the CLI connect isn’t authenticated (or token drift between service vs CLI).

1) Check your gateway auth mode (safe to paste)

Run and paste:

openclaw config get gateway.auth.mode

2) Check whether token/password is coming from config or env (DO NOT paste the secret)

Run locally and just tell us what “shape” it is:

openclaw config get gateway.auth

• If it shows a literal token: "..." → don’t paste the value (redact it)
• If it shows a SecretRef (like env/file/exec) → you can paste that, it’s safe

3) Quick confirm: does your CLI have the same token as the service?

If the service is using OPENCLAW_GATEWAY_TOKEN but your shell isn’t, CLI calls will get closed.

You can inspect the service env (don’t paste secrets, just confirm whether it contains a token var):

systemctl --user show openclaw-gateway.service -p Environment

4) Fast test (no guessing): pass the token explicitly once

After you retrieve the correct token on the gateway host (from config or service env), try:

openclaw system event --mode now --text "test" --token "<YOUR_TOKEN>"

(Again: don’t paste the token into Discord.)

Once the CLI can connect successfully, your heartbeat settings (target: last, every: 30m) will actually be able to deliver.

If you paste gateway.auth.mode + a redacted gateway.auth block (or tell us whether it’s env-based), we can tell you the cleanest way to eliminate token drift (usually: put the token in ~/.openclaw/openclaw.json or ~/.openclaw/.env, then restart).

[bronze tulip]

yunshenjia@yunshenjia3:~$ openclaw config get gateway.auth.mode

🦞 OpenClaw 2026.3.13 (61d171a) — Your task has been queued; your dignity has been deprecated.

token
13:19:17 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
yunshenjia@yunshenjia3:~$ openclaw config get gateway.auth

🦞 OpenClaw 2026.3.13 (61d171a) — Your .env is showing; don't worry, I'll pretend I didn't see it.

{
"mode": "token",
"token": "OPENCLAW_REDACTED"
}
13:19:54 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
yunshenjia@yunshenjia3:~$ systemctl --user show openclaw-gateway.service -p Environment
Environment=HOME=/home/yunshenjia TMPDIR=/tmp PATH=/home/yunshenjia/.local/bin:/home/yunshenjia/.npm-global/bin:/home/yunshenjia/bin:/home/yunshenjia/>
lines 1-1/1 (END)

[jaunty birch]

Awesome — this basically confirms “auth is configured” and it’s not coming from systemd env drift:

• gateway.auth.mode = token
• gateway.auth shows token present (redacted)
• systemctl --user show … Environment does not include OPENCLAW_GATEWAY_TOKEN (fine)

And we already know the port is listening on 0.0.0.0:18789, so bind/interface isn’t the issue.

So the remaining question is: why does the gateway close the WS immediately (1000) when the CLI tries to connect?
At this point we need the gateway’s own explanation (it will log it).

1) Paste service-only gateway status (shows config drift info)

This is the “don’t hang on probe” version and should include Config (cli) vs Config (service):

openclaw gateway status --no-probe --no-color

2) Tail gateway logs while reproducing the failure

In terminal A:

openclaw logs --follow

In terminal B (retry your command):

openclaw system event --text "Heartbeat test: send me a short message now (not HEARTBEAT_OK)" --mode now

Then paste the new log lines that appear right when it closes (they usually include an auth detail code like AUTH_TOKEN_MISSING, AUTH_TOKEN_MISMATCH, device-nonce/signature errors, etc.).

Those log lines will tell us exactly which bucket this is:

• shared token mismatch, or

• device auth v2 nonce/signature issue, or
• connecting to a different gateway instance/config than you think.

Once we see that snippet, the fix is usually 1–2 commands (either token alignment or device token rotate/approve), but we need that log reason first.

[bronze tulip]

yunshenjia@yunshenjia3:~$ openclaw gateway status --no-probe --no-color

🦞 OpenClaw 2026.3.13 (61d171a) — I've seen your commit messages. We'll work on that together.

13:23:48 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-17.log
Command: /usr/bin/node /home/yunshenjia/.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.1.163:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 9555, state active, sub running, last exit 0, reason 0)
Port 18789 is already in use.

• pid 9555 yunshenjia: openclaw-gateway (*:18789)
• Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
  Listening: *:18789
  Troubles: run openclaw status
  Troubleshooting: https://docs.openclaw.ai/troubleshooting

yunshenjia@yunshenjia3:~$ openclaw logs --follow

🦞 OpenClaw 2026.3.13 (61d171a) — Your second brain, except this one actually remembers where you left things.

13:24:20 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
gateway connect failed: Error: gateway closed (1000):
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/yunshenjia/.openclaw/openclaw.json
Bind: lan
Hint: run openclaw doctor.
yunshenjia@yunshenjia3:~$ openclaw system event --text "Heartbeat test: send me a short message now (not HEARTBEAT_OK)" --mode now

🦞 OpenClaw 2026.3.13 (61d171a) — iMessage green bubble energy, but for everyone.

│
13:24:44 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
gateway connect failed: Error: gateway closed (1000):
◇
Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/yunshenjia/.openclaw/openclaw.json
Bind: lan

[jaunty birch]

Nice — this output confirms the Gateway is healthy at the service level:

• Runtime: running … Listening: *:18789
• Config (cli) == Config (service) (so no config-path drift)
• bind=lan (0.0.0.0) (so loopback should work)

So we’re down to just one thing: why does the Gateway close the WS (1000) when the CLI tries to connect for system event?

That is almost always “token not being sent / token mismatch” (because with token auth the server can just close the socket).

1) Quick decisive test: pass the token explicitly once

Run this on the gateway host (don’t paste the token to Discord):

openclaw system event \
  --mode now \

  --text "heartbeat test: reply with a short message" \
  --url ws://127.0.0.1:18789 \
  --token "$(openclaw config get gateway.auth.token)"

• If this works → the Gateway token is fine, but your CLI call path wasn’t picking it up automatically in the earlier run (we can then focus on why).
• If this still closes → it’s not just “missing token”, and we need the gateway logs for the exact close reason.

2) If it still fails: grep the gateway log for the close reason

Your gateway status already told us the file log:

/tmp/openclaw/openclaw-2026-03-17.log

Run:

grep -E "AUTH_|DEVICE_AUTH|PAIRING_REQUIRED|TOKEN|nonce|signature|connect\\.challenge" \
  /tmp/openclaw/openclaw-2026-03-17.log | tail -n 80

Paste the output (it shouldn’t include secrets; if it does, redact).

That will tell us if it’s:

• AUTH_TOKEN_MISSING / AUTH_TOKEN_MISMATCH
• device nonce/signature issues
• pairing/device-token drift

Once we have that line, the fix is straightforward.

[bronze tulip]

yunshenjia@yunshenjia3:~$ openclaw system event
--mode now \

openclaw system event
--mode now
--text "heartbeat test: reply with a short message"
--url ws://127.0.0.1:18789
--token "$(openclaw config get gateway.auth.token)"
[plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.

error: too many arguments for 'event'. Expected 0 arguments but got 3.

[jaunty birch]

Great — now we know for sure the Gateway is listening properly (0.0.0.0:18789) and the service/config paths match.

Given that, the behavior you’re seeing:

• openclaw system event … → WS connects then immediately closes (1000)
• openclaw logs --follow → same

is exactly what happens when the Gateway is in token auth mode and the client doesn’t send the shared token. With token auth, the Gateway can simply close the socket (often with no close reason), so the CLI just reports “closed (1000)”.

You already confirmed the Gateway is configured with:

{ "mode": "token", "token": "...(redacted)..." }

Fix: make your CLI send the gateway token

On the gateway host, set OPENCLAW_GATEWAY_TOKEN in your shell to the same value as gateway.auth.token (don’t paste the token here).

Option A (quick test in current shell)

1. Open your config file and copy the token value locally:

• file is: ~/.openclaw/openclaw.json
• key is: gateway.auth.token

2. Then:

export OPENCLAW_GATEWAY_TOKEN="(paste token here)"
openclaw status
openclaw system event --text "Heartbeat test: say hi" --mode now

Option B (durable, recommended for daemons + CLI)

Put it in ~/.openclaw/.env (same token value), then restart gateway:

# edit ~/.openclaw/.env and add:

# OPENCLAW_GATEWAY_TOKEN=...

openclaw gateway restart

After that: your heartbeat settings will actually work

You already set:

• agents.defaults.heartbeat.target = "last"
• agents.defaults.heartbeat.every = "30m"

After the token is working, openclaw system event --mode now should finally be able to trigger the heartbeat and deliver to the “last” chat.

If you do Option A and it still closes, paste the last ~30 lines of /tmp/openclaw/openclaw-2026-03-17.log around the time you run the command (redact secrets) — but I’m betting this is simply “CLI not sending token.”

[bronze tulip]

13:32:42 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
│
13:32:45 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
◒ Probing gateway….[qqbot] resolveAllowFrom: accountId=liuyi, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liuer, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liusan, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liusi, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=liuwu, allowFrom=[""]
[qqbot] resolveAllowFrom: accountId=xiaodi, allowFrom=[""]

Security audit
Summary: 0 critical · 6 warn · 1 info
WARN No auth rate limiting configured
gateway.bind is not loopback but no gateway.auth.rateLimit is configured. Without rate limiting, brute-force auth attacks are not mitigated.
Fix: Set gateway.auth.rateLimit (e.g. { maxAttempts: 10, windowMs: 60000, lockoutMs: 300000 }).
WARN Some gateway.nodes.denyCommands entries are ineffective
gateway.nodes.denyCommands uses exact node command-name matching only (for example system.run), not shell-text filtering inside a command payload. - Unknown …
Fix: Use exact command names (for example: canvas.present, canvas.hide, canvas.navigate, canvas.eval, canvas.snapshot, canvas.a2ui.push, canvas.a2ui.pushJSONL, canvas.a2ui.reset). If you need broader restrictions, remove risky command IDs from allowCommands/default workflows and tighten tools.exec policy.
WARN Potential multi-user setup detected (personal-assistant model warning)
Heuristic signals indicate this gateway may be reachable by multiple users: - channels.qqbot.accounts.liuyi.allowFrom includes "*" - channels.qqbot.accounts.li…
Fix: If users may be mutually untrusted, split trust boundaries (separate gateways + credentials, ideally separate OS users/hosts). If you intentionally run shared-user access, set agents.defaults.sandbox.mode="all", keep tools.fs.workspaceOnly=true, deny runtime/fs/web tools unless required, and keep personal/private identities + credentials off that runtime.

WARN Extensions exist but plugins.allow is not set
Found 1 extension(s) under /home/yunshenjia/.openclaw/extensions. Without plugins.allow, any discovered plugin id may load (depending on config and plugin beha…
Fix: Set plugins.allow to an explicit list of plugin ids you trust.
WARN Extension plugin tools may be reachable under permissive tool policy
Enabled extension plugins: openclaw-qqbot. Permissive tool policy contexts: - default - agents.list.main - agents.list.liuyi - agents.list.liuer - agents.list.…
Fix: Use restrictive profiles (minimal/coding) or explicit tool allowlists that exclude plugin tools for agents handling untrusted input.
WARN Plugin installs include unpinned npm specs
Unpinned plugin install records: - openclaw-qqbot (@tencent-connect/openclaw-qqbot@latest)
Fix: Pin install specs to exact versions (for example, @scope/pkg@1.2.3) for higher supply-chain stability.
Full report: openclaw security audit
Deep probe: openclaw security audit --deep

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ QQ Bot │ ON │ OK │ configured · accounts 6/6 │
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

agent:liusi:qqbot:direct:fe9ab9… │ direct │ 1h ago │ grok-4.20-beta-0309-non-reasoning │ unknown/131k (?%) │
│ agent:liuer:qqbot:direct:989e60… │ direct │ 1h ago │ qwen3.5-plus │ unknown/128k (?%) │
│ agent:main:cron:de45047c-5799-4… │ direct │ 1h ago │ deepseek-chat │ unknown/131k (?%) │
└───────────────────────────────────────────────────────────┴────────┴─────────┴───────────────────────────────────┴──────────────────────────────────┘

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting

Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Fix reachability first: openclaw gateway probe
yunshenjia@yunshenjia3:~$ openclaw system event --text "Heartbeat test: say hi" --mode now

🦞 OpenClaw 2026.3.13 (61d171a) — Automation with claws: minimal fuss, maximal pinch.

│
13:32:53 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
gateway connect failed: Error: gateway closed (1000):
◇
Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/yunshenjia/.openclaw/openclaw.json
Bind: lan

[jaunty birch]

That error is just your shell command getting mangled by the line continuations.

The > prompts mean bash was still “inside” the first command, and you accidentally typed a second openclaw system event … as arguments to the first one. That’s why it says:

Expected 0 arguments but got 3

1) Run ONE clean command (copy/paste exactly)

Example (single line):

openclaw system event --mode now --text "heartbeat test: reply with a short message" --url ws://127.0.0.1:18789 --token "<PASTE_REAL_GATEWAY_TOKEN_HERE>"

2) Important: openclaw config get gateway.auth.token is REDACTED

So this part will not work:

--token "$(openclaw config get gateway.auth.token)"

It will substitute __OPENCLAW_REDACTED__, which guarantees a token mismatch → WS gets closed.

Where to get the real token

Open this file locally on the gateway host and copy the value (do not paste it into Discord):

• ~/.openclaw/openclaw.json
• look for: gateway.auth.token

3) Make CLI commands work without always passing --token (recommended)

Once you have the real token, set it in your shell:

export OPENCLAW_GATEWAY_TOKEN="(paste token)"

Then you can just do:

openclaw system event --mode now --text "heartbeat test: say hi"
openclaw logs --follow

If you want it persistent across logins, put the same line in ~/.openclaw/.env (same token value), then openclaw gateway restart.

After this, your heartbeat config (target: last, every: 30m) should finally be able to deliver proactively.

[bronze tulip]

13:37:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-qqbot (/home/yunshenjia/.openclaw/extensions/openclaw-qqbot/index.ts). Set plugins.allow to explicit trusted ids.
gateway connect failed: Error: gateway closed (1000):
◇
Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /home/yunshenjia/.openclaw/openclaw.json

[jaunty birch]

That security audit output makes sense for your current setup (LAN bind + allowFrom: "*"). But it’s separate from the reason your CLI heartbeats/system-event calls are failing.

The immediate blocker (why /system event + logs --follow keep failing)

Your gateway is in token auth mode. Commands like openclaw system event / openclaw logs --follow need the gateway token in the client (OPENCLAW_GATEWAY_TOKEN env var or --token …). Right now you’re not providing it, and because auth is required the gateway just closes the WS (1000).

Also: openclaw config get gateway.auth redacts the token on output, so you can’t use $(openclaw config get gateway.auth.token) as a real token source.

Do this on the gateway host (don’t paste the token into Discord):

1. Open ~/.openclaw/openclaw.json and copy the value of gateway.auth.token.
2. In your shell:

export OPENCLAW_GATEWAY_TOKEN="(paste token)"
openclaw system event --mode now --text "heartbeat test: reply with a short message"

If that works, your heartbeat delivery (target: "last", every: "30m") can finally function.

---

About the security audit warnings (quick fixes)

1) Add auth rate limiting (recommended on bind: lan)

The audit even suggests a good baseline:

openclaw config set gateway.auth.rateLimit '{ "maxAttempts": 10, "windowMs": 60000, "lockoutMs": 300000 }' --strict-json
openclaw gateway restart

2) allowFrom: "*" means “anyone can use your bot”

That’s why it warns about “potential multi-user setup”. If this is meant to be personal, restrict allowFrom to only your own QQ IDs (and consider sandboxing).

---

If you run the export OPENCLAW_GATEWAY_TOKEN=... + openclaw system event ... test and paste just the success/failure output (no secrets), we can confirm the proactive path is unblocked.

Those audit warnings are legit, and (good news) they’re all straightforward to address.

1) Fix: “Extensions exist but plugins.allow is not set”

If you intend to run openclaw-qqbot, allowlist it explicitly:

openclaw config set plugins.allow '["openclaw-qqbot"]' --strict-json
openclaw gateway restart

That will stop the “auto-load anything under ~/.openclaw/extensions” warning.

2) Fix: “Plugin installs include unpinned npm specs”

You installed it as @tencent-connect/openclaw-qqbot@latest. Safer is to pin the exact resolved version:

openclaw plugins install @tencent-connect/openclaw-qqbot --pin

(or pin a specific version you trust, e.g. @tencent-connect/openclaw-qqbot@1.2.3).

3) Fix: “Plugin tools reachable under permissive tool policy”

This warning is basically saying: with allowFrom: "*" your bot is public, so you should assume untrusted input.

Minimum safety steps for a public-facing gateway:

• Don’t leave allowFrom: "*" unless you really want public access.
• Enable gateway.auth.rateLimit (your earlier audit already suggested a good baseline).
• Consider sandboxing + restrictive tool allowlists for agents that handle public chats.

Docs that cover this philosophy: https://docs.openclaw.ai/gateway/security

---

Separate but important: did you already try setting OPENCLAW_GATEWAY_TOKEN in your shell and rerunning:

openclaw system event --mode now --text "heartbeat test: say hi"

That’s still the key step to get your proactive heartbeat test working.

Yep — QQ Bot channel being ON / OK just means “configured + accounts load”. It doesn’t prove the Gateway RPC calls (heartbeat/system-event/logs) are working yet.

Right now your blocker is still:

• openclaw system event … / openclaw logs --follow → gateway closed (1000)
  That’s what happens when token auth is enabled and the CLI isn’t sending the token.

Do these exact steps (don’t paste the token into Discord)

1) Copy your gateway token from the config file

Open (locally on the gateway host):

~/.openclaw/openclaw.json

Find: gateway.auth.token and copy the value.

2) Export it in your current shell

export OPENCLAW_GATEWAY_TOKEN="(paste token)"

3) Retry a gateway RPC command

openclaw status
openclaw system event --mode now --text "heartbeat test: reply with a short message"

If that succeeds, you should be unblocked.

4) For “target: last” delivery, make sure “last” is actually QQ

Send any message to the bot on QQ first, then run the system event again. Otherwise “last” may be unset and nothing will be delivered.

If you paste the output of step (3) (no secrets), I can tell you whether the heartbeat is now firing and whether we need to set channels.qqbot.defaultAccount or a per-agent heartbeat target for your multi-account setup.

That table output (with session keys like agent:liusi:qqbot:direct:…) means your CLI can now actually talk to the Gateway again — so the “gateway unreachable” part is solved. Good.

Now the only remaining question is: did the heartbeat actually run + did it deliver a message?
Sometimes it runs but you see nothing because the reply was HEARTBEAT_OK (which is suppressed by default) or because target:"last" couldn’t resolve a “last chat” for the heartbeat session.

Check what happened (best next command)

Run this and paste the output:

openclaw system heartbeat last

That will tell us whether the heartbeat:

• ran or was skipped
• delivered or not
• and the skip/delivery reason

If you want a guaranteed visible test message

Temporarily force the heartbeat prompt to always send a message (instead of HEARTBEAT_OK), restart, then trigger:

openclaw config set agents.defaults.heartbeat.prompt "Send a short message: 'heartbeat test ok' (do not output HEARTBEAT_OK)."
openclaw gateway restart
openclaw system event --mode now --text "test"

(After testing, you can set the prompt back, or move the real “background tasks” into HEARTBEAT.md.)

Reminder for “continuous”

Since you’re on Linux systemd user service: if you want it to stay up after logout/reboot, enable lingering:

sudo loginctl enable-linger $USER

Paste openclaw system heartbeat last and we’ll make the proactive delivery reliable from there.

That output is still “client connected without a token → gateway closed the socket”.

openclaw system event does not automatically send your gateway.auth.token from config. You must provide the token via either:

• --token … or
• OPENCLAW_GATEWAY_TOKEN=… in your shell/env.

Right now you’re running:

openclaw system event --text "Heartbeat test: say hi" --mode now

…with no token, so the gateway closes (1000).

Do this (don’t paste the token into Discord)

Option A: export once, then run commands normally

1. Open ~/.openclaw/openclaw.json and copy the value of gateway.auth.token
2. Then:

export OPENCLAW_GATEWAY_TOKEN="(paste token)"
openclaw system event --mode now --text "Heartbeat test: say hi"

Option B: pass the token inline

openclaw system event --mode now --text "Heartbeat test: say hi" --token "(paste token)"

After it succeeds, run:

openclaw system heartbeat last

and you should see the heartbeat run record + whether it delivered.

If you want this to work across SSH sessions/reboots, put the same token into ~/.openclaw/.env as OPENCLAW_GATEWAY_TOKEN=... (same value) and restart the gateway.

Once you run it with a token, paste the success output (no secrets) and we’ll confirm delivery is going to the right QQ chat (target: "last").

[bronze tulip]

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting

Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Fix reachability first: openclaw gateway probe
yunshenjia@yunshenjia3:~$ openclaw system event --mode now --text "heartbeat test: reply with a short message"

🦞 OpenClaw 2026.3.13 (61d171a) — I can't fix your code taste, but I can fix your build and your backlog.

│
◇
ok
yunshenjia@yunshenjia3:~$

yunshenjia@yunshenjia3:~$ openclaw system heartbeat last

🦞 OpenClaw 2026.3.13 (61d171a) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

│
◇
{
"ts": 1773726202524,
"status": "ok-token",
"reason": "wake",
"durationMs": 10985,
"silent": true,
"indicatorType": "ok"
}
yunshenjia@yunshenjia3:~$

help

[jaunty birch]

You’re stuck on one exact thing: your CLI commands (openclaw system event, openclaw logs --follow, etc.) are connecting to the gateway without a token, so the gateway closes the socket (1000). That’s why nothing “proactive” works.

If you don’t want to hunt for the existing token in openclaw.json, do this clean reset/align in one go (don’t paste the token into Discord):

Fix (rotate token + export it for the CLI in the same shell)

# 1) Generate a fresh token
TOKEN="$(openssl rand -hex 32)"   # if openssl missing: TOKEN="$(python3 -c 'import secrets; print(secrets.token_hex(32))')"

# 2) Write it to config (gateway uses this)
openclaw config set gateway.auth.mode "token"
openclaw config set gateway.auth.token "$TOKEN"

# 3) Export it for CLI commands (client uses this)
export OPENCLAW_GATEWAY_TOKEN="$TOKEN"