OpenClaw Telegram bot not responding despite gateway working since release | Friends of the Crustacean 🦞🤝 | Page 1

patent night Apr 27, 2026, 9:42 AM

#

Hi, I’m having an issue where my OpenClaw setup was working fine yesterday, but now my Telegram bot no longer responds.

Current state:

Gateway is running and reachable (/health OK, gateway probe OK)
Telegram bot is valid (getMe OK)
Messages are received by Telegram (getUpdates shows pending messages)
OpenClaw status shows Telegram: ON | OK
However, no response is sent back to Telegram

Observations:

pending_update_count keeps increasing → OpenClaw is not consuming updates
Bootstrap file: ABSENT for agent main
Agent has existing sessions, so it was working previously
No Telegram-related logs appear when sending messages
No obvious errors besides some plugin/runtime warnings

acoustic citrusBOT Apr 27, 2026, 9:44 AM

#

This points before the agent/session layer: if pending_update_count is rising and there are no Telegram logs, OpenClaw probably isn’t actually running the Telegram polling monitor, even though config/status says Telegram is enabled.

First thing: please paste:

openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw gateway status

Then tail logs while sending one fresh Telegram DM:

openclaw logs --follow

#

Look specifically for telegram, getUpdates, polling, webhook, or plugin load errors.

A few likely causes:

Version/regression after upgrade — version matters a lot here, especially around recent plugin/runtime changes.
Telegram plugin/runtime failed before polling starts — plugin warnings may be the real issue.
Duplicate poller — don’t leave getUpdates running in another terminal/script; Telegram allows only one long-poll consumer for a bot token.
Webhook/polling mismatch — check whether Telegram still has a webhook set:
```
curl -s "https://api.telegram.org/bot<TOKEN>/getWebhookInfo"
```

If status --all shows plugin/runtime warnings, paste that section too. Docs refs: https://docs.openclaw.ai/channels/telegram#troubleshooting and https://docs.openclaw.ai/channels/troubleshooting

#

That Agents table mostly rules out bootstrap/session-store as the cause. Active 2h ago also matches your theory: Telegram updates are not reaching the agent at all.

The missing piece is the Telegram channel runtime, not the agent table. Please paste:

openclaw --version
openclaw channels status --probe --json
openclaw channels logs --channel telegram --lines 200

Also useful:

openclaw logs --lines 300 | grep -iE "telegram|plugin|channel exited|getUpdates|webhook|runtime"

What I’m looking for:

#

running: false or lastError under Telegram → channel monitor crashed / never started.
plugin/runtime import errors → likely the “warnings” are actually blocking Telegram startup.
getUpdates conflict → another process/script is polling the same bot token.
webhook URL set unexpectedly → Telegram is delivering to webhook instead of polling.

Since pending_update_count is increasing, this is almost certainly polling not running, not an agent bootstrap issue. Docs: https://docs.openclaw.ai/channels/telegram#troubleshooting

patent night Apr 27, 2026, 9:59 AM

#

OpenClaw Status Summary
Version: 2024.4.24 (Node 22.22.2)

OS: Linux (WSL2 x64)

Channel Status: Both Discord and Telegram are marked as Enabled / OK.

Gateway Issue: The status shows a connection error: unreachable (connect ECONNREFUSED 127.0.0.1:18709).

Gateway Service: Currently in state activating and marked as stopped.

Agents: 1 main agent detected, but Bootstrap file is reported as ABSENT. Last activity was 2 hours ago.

acoustic citrusBOT Apr 27, 2026, 10:00 AM

#

Aha — this changes it: the Gateway is not actually reachable.

ECONNREFUSED 127.0.0.1:18709 + service activating/stopped means Telegram can’t be consumed because the gateway process isn’t staying up. The “Telegram: Enabled / OK” line is likely config/static status, not live polling.

Run:

openclaw gateway status --deep
openclaw logs --lines 300
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
openclaw doctor

Then try:

#

openclaw gateway restart
openclaw gateway status

If Config (cli) and Config (service) differ, reinstall the service from the same shell/profile:

openclaw gateway install --force
openclaw gateway restart

Also please double-check the version: did you mean 2026.4.24, not 2024.4.24? If it’s really 2024.4.24, update first. If it’s 2026.4.24, paste the service/log error — there have been recent plugin/runtime-deps weirdness around that area, and the exact startup error matters.

Docs: https://docs.openclaw.ai/gateway/troubleshooting#gateway-service-not-running

patent night Apr 27, 2026, 10:01 AM

#

Combined Diagnosis: Gateway & Channel Probe
Gateway Status: The service is technically "Active" (PID 9517), but it is not listening on port 18789. All connectivity probes are failing with ECONNREFUSED.

Channel Probe (JSON): Confirms gatewayReachable: false with an abnormal closure (1006) error. The Gateway is terminating connections immediately or failing to open the websocket.

Telegram Logs: Returns No matching log lines. This confirms that the Telegram channel cannot even begin polling because it’s stuck trying to reach the unresponsive Gateway.

Summary: The root cause is a Gateway hang/bind failure. The Telegram monitor hasn't crashed; it simply hasn't been able to start because the internal communication bridge (Port 18789) is down.

acoustic citrusBOT Apr 27, 2026, 10:02 AM

#

Yep, that’s no longer a Telegram problem. The gateway service is alive as a process, but not bind/listening, so no channel runtime can start.

One important clue: current changelog mentions a fix for .24 update hangs and 1006 disconnect cascades. If you’re on 2026.4.24, I’d try update/repair first:

openclaw update
openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

If it still says active but not listening, stop the service and run foreground to expose the real startup blocker:

openclaw gateway stop

#

openclaw --log-level debug gateway run

Also check the port mismatch possibility — you mentioned 18709 earlier but now 18789:

openclaw config get gateway.port
openclaw gateway status --deep
ss -ltnp | grep -E '18709|18789|openclaw|node'

If foreground logs show plugin/runtime-deps/npm staging errors, paste that section. That’s likely the actual root cause. Docs: https://docs.openclaw.ai/gateway/troubleshooting#gateway-service-not-running

patent night Apr 27, 2026, 10:06 AM

#

[gateway] ready (8 plugins: discord, telegram, bonjour, tailscale...)
[gateway] starting channels and sidecars...
[plugins] bonjour: watchdog detected non-announced service
[plugins] bonjour: restarting advertiser (stuck in probing for 60s)
[openclaw] Unhandled promise rejection: CIAO PROBING CANCELLED
systemd: openclaw-gateway.service: Main process exited, status=1/FAILURE

[tailscale] serve failed: Command failed: /usr/bin/tailscale serve --bg --yes 18789
[tailscale] Access denied: serve config denied
[tailscale] Hint: Use 'sudo tailscale set --operator=$USER'

acoustic citrusBOT Apr 27, 2026, 10:06 AM

#

Found it — this is the actual crash:

Unhandled promise rejection: CIAO PROBING CANCELLED
Main process exited, status=1/FAILURE

That’s Bonjour/mDNS killing the gateway after it initially says “ready”. Telegram never starts because the gateway dies during sidecar/channel startup.

Fast recovery:

openclaw gateway stop
openclaw plugins disable bonjour
openclaw gateway restart
openclaw gateway status

#

Then fix Tailscale separately. If you don’t need Tailscale Serve:

openclaw config set gateway.tailscale.mode off
openclaw gateway restart

If you do need Tailscale Serve, grant your user operator rights:

sudo tailscale set --operator=$USER
openclaw gateway restart

Also update off .24 if that’s what you’re on — this exact Bonjour CIAO PROBING CANCELLED crash path is mentioned in recent fixes:

#

openclaw update
openclaw doctor --fix

After the gateway stays listening, Telegram should start consuming updates again. Docs: https://docs.openclaw.ai/gateway/bonjour and https://docs.openclaw.ai/gateway/tailscale

patent night Apr 27, 2026, 10:17 AM

#

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

#

Health check failed: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/irisiris/.openclaw/openclaw.json
Bind: loopback

acoustic citrusBOT Apr 27, 2026, 10:17 AM

#

This is progress: the gateway now binds to 127.0.0.1:18789, but the probe times out. The “port already in use” line is not the problem — it’s the same gateway PID. The problem is that the gateway event loop is wedged after binding, likely during sidecars/channel startup.

Given your earlier logs, I’d temporarily disable the two suspects:

openclaw gateway stop
openclaw plugins disable bonjour
openclaw config set gateway.tailscale.mode off
openclaw gateway restart
openclaw gateway status
openclaw channels status --probe

If you actually need Tailscale Serve, don’t leave it off; fix permissions instead:

#

sudo tailscale set --operator=$USER
openclaw config set gateway.tailscale.mode serve
openclaw gateway restart

If the probe still times out, run this once to prove the core gateway is healthy without channel startup:

openclaw gateway stop
OPENCLAW_SKIP_CHANNELS=1 openclaw --log-level debug gateway run

If that probes OK, we know it’s definitely a channel/sidecar startup hang. Also, if you’re still on 2026.4.24, update — recent fixes mention .24 startup hangs / 1006 cascades.

Docs: https://docs.openclaw.ai/gateway/bonjour and https://docs.openclaw.ai/gateway/tailscale

#

That timeout confirms the gateway is listening but not servicing WS requests — likely stuck during startup after bind.

Please run the isolation test:

openclaw gateway stop
OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_DISABLE_BONJOUR=1 openclaw --log-level debug gateway run

Then in another terminal:

openclaw gateway status
openclaw health

Results:

#

If health works: core gateway is fine; a channel/sidecar is hanging. Keep Bonjour disabled and turn Tailscale off/fix permissions:
```
openclaw plugins disable bonjour
openclaw config set gateway.tailscale.mode off
openclaw gateway restart
```
If health still times out: paste the foreground debug log around where it stops.

Also: if this is 2026.4.24, update ASAP — this matches recent .24 startup hang/1006 issues.

patent night Apr 27, 2026, 10:23 AM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log command line: where dreams compile and confidence segfaults.
Command: /usr/bin/node /home/irisiris/.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: stopped (state failed, sub failed, last exit 9, reason 2)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
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/irisiris/.openclaw/logs/gateway-restart.log

Port 18789 is already in use.

pid 12503 irisiris: 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
irisiris@DESKTOP-L7HBNRL:/mnt/c/Users/Iris$ openclaw health
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/irisiris/.openclaw/agents/main/sessions/sessions.json (13 entries)
agent:main:cron:de6f379e-e5ec-4a21-b153-5b70a6bd326f (6m ago)
agent:main:cron:de6f379e-e5ec-4a21-b153-5b70a6bd326f:run:cdc13920-31e8-42ca-8d4e-25551a070bd8 (8m ago)
agent:main:cron:de6f379e-e5ec-4a21-b153-5b70a6bd326f:run:0b6e5b6b-d9da-4f58-948e-85ba3af4431d (12m ago)
agent:main:cron:15a9f04c-ffbc-4917-91f2-0ec436a99098 (178m ago)
agent:main:cron:15a9f04c-ffbc-4917-91f2-0ec436a99098:run:868f3572-e0b3-49c6-b810-9c308b93d51b (178m ago)

acoustic citrusBOT Apr 27, 2026, 10:23 AM

#

Now it looks like split-brain/stale process:

systemd service says failed/stopped
but port 18789 is held by another openclaw-gateway PID
that PID is listening but not answering WS → stuck/orphan gateway

Clean it up, then restart fresh:

openclaw gateway stop
ss -ltnp | grep 18789

If it still shows an openclaw-gateway PID, terminate that exact PID:

#

kill -TERM 12503
sleep 2
ss -ltnp | grep 18789

Only if it refuses to exit:

kill -KILL 12503

Then restart with the sidecar suspects disabled:

openclaw plugins disable bonjour

#

openclaw config set gateway.tailscale.mode off
openclaw gateway restart
openclaw gateway status
openclaw channels status --probe

If that works, Telegram should start draining pending updates. If it fails again, paste:

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

patent night Apr 27, 2026, 10:28 AM

#

irisiris@DESKTOP-L7HBNRL:/mnt/c/Users/Iris$ openclaw gateway status

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Somewhere between 'hello world' and 'oh god what have I built.'

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/irisiris/.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 12999, 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 12999 irisiris: 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
irisiris@DESKTOP-L7HBNRL:/mnt/c/Users/Iris$ openclaw channels status --probe

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

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

Discord default: enabled, configured, token:config
Telegram default: enabled, configured, token:config

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

acoustic citrusBOT Apr 27, 2026, 10:28 AM

#

You’re definitely on the bad shape now: 2026.4.24 gateway is bound but wedged. The channel status is explicitly config-only, so Telegram is not running.

Do this first — update off .24:

openclaw gateway stop
npm install -g openclaw@latest
openclaw --version
openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

Then verify live channel runtime:

#

openclaw channels status --probe

If it still times out after updating, start once in foreground with sidecars disabled so we can see the blocker:

openclaw gateway stop
OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_DISABLE_BONJOUR=1 openclaw --log-level debug gateway run

But I’d update first — 2026.4.24 matches the recent startup hang / 1006 cascade area almost perfectly.

patent night Apr 27, 2026, 10:38 AM

#

irisiris@DESKTOP-L7HBNRL:/mnt/c/Users/Iris$ openclaw gateway status

🦞 OpenClaw 2026.4.24 (cbcfdf6) — The lobster in your shell. 🦞

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/irisiris/.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 13818, 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 13818 irisiris: 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
irisiris@DESKTOP-L7HBNRL:/mnt/c/Users/Iris$ openclaw channels status --probe

🦞 OpenClaw 2026.4.24 (cbcfdf6) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

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

Discord default: enabled, configured, token:config
Telegram default: enabled, configured, token:config

#

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

12:35:12 [gateway] loading configuration…
12:35:12 [gateway] resolving authentication…
12:35:12 [gateway] starting...
12:35:21 [gateway] starting HTTP server...
12:35:21 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/irisiris/.openclaw/canvas)
12:35:21 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
12:35:22 [gateway] agent model: openai-codex/gpt-5.4
12:35:22 [gateway] ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 9.3s)
12:35:22 [gateway] log file: /tmp/openclaw/openclaw-2026-04-27.log
12:35:22 [gateway] starting channels and sidecars...
12:35:22 [gateway] removed stale session lock: /home/irisiris/.openclaw/agents/main/sessions/baf2ac56-e3ff-402b-ba7b-72b60dbdb8a7.jsonl.lock (dead-pid)
12:35:22 [gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)
12:35:22 [plugins] embedded acpx runtime backend registered (cwd: /home/irisiris/.openclaw/workspace)
12:35:22 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
12:36:25 [plugins] embedded acpx runtime backend ready
12:36:25 [tailscale] serve enabled: [TAILSCALE_URL] (WS via wss://desktop-l7hbnrl-1.tail76008b.ts.net)
12:36:25 [heartbeat] started

acoustic citrusBOT Apr 27, 2026, 10:39 AM

#

This output is the same failure state: 2026.4.24 is listening but wedged, and channels status is only showing config. Telegram will not work until the gateway probe succeeds.

Please stop repeating status and do the recovery path:

openclaw gateway stop
openclaw update --yes --no-restart
openclaw --version
openclaw doctor --fix
openclaw plugins disable bonjour
openclaw config set gateway.tailscale.mode off
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status
openclaw channels status --probe

#

If openclaw gateway stop leaves a stuck listener, kill the PID shown by status/ss first:

kill -TERM 13818
sleep 2
ss -ltnp | grep 18789

Only if it remains:

kill -KILL 13818

Then run the update/restart block above.

If it still times out after updating off 2026.4.24, paste:

#

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

Docs: https://docs.openclaw.ai/cli/update and https://docs.openclaw.ai/gateway/troubleshooting#gateway-service-not-running

#

Good, this proves the core gateway can start. But this line is the key:

[gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)

So Telegram is still not expected to work in this run — channels are explicitly disabled.

Next step: restart normally, without OPENCLAW_SKIP_CHANNELS:

# stop the foreground gateway if it is still running
# Ctrl+C in that terminal, then:

unset OPENCLAW_SKIP_CHANNELS
unset OPENCLAW_SKIP_PROVIDERS

#


openclaw gateway stop
openclaw plugins disable bonjour
openclaw gateway restart
openclaw gateway status
openclaw channels status --probe

If it still says “skipping channel start”, check whether the env var got baked into systemd:

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

If OPENCLAW_SKIP_CHANNELS=1 appears there, reinstall the service:

#

openclaw gateway install --force
openclaw gateway restart

Once channels status --probe reaches the gateway live, Telegram should begin polling again.

patent night Apr 27, 2026, 10:48 AM

#

i will wait the next release i think

acoustic citrusBOT Apr 27, 2026, 10:48 AM

#

Fair. Given you’re on 2026.4.24, waiting for the next release is reasonable.

For a temporary “make Telegram work now” workaround, the lowest-risk path is:

openclaw plugins disable bonjour
openclaw config set gateway.tailscale.mode off
openclaw gateway restart

Just make sure OPENCLAW_SKIP_CHANNELS is not set, otherwise Telegram will never start.

If the next release fixes it, please run:

openclaw update

#OpenClaw Telegram bot not responding despite gateway working since release