Can't Open Dashboard or talk with OC agents on Telegram

[sly elk]

Everything was working fine but now, not so much.

[slim meadow]

On the Gateway host, can you paste the output of these (they’re read-only and usually pinpoint what broke):

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

While you grab that, two very common “worked before, now dead” causes:

1) Dashboard can’t open / says unauthorized / keeps reconnecting

Run:

openclaw dashboard

…and open the tokenized URL it prints (?token=...). If you’re not on localhost (VPS / remote), the token/auth path matters a lot.

Docs: https://docs.openclaw.ai/web/dashboard

2) Telegram sends messages but you get no replies

Start with:

openclaw models status
openclaw logs --follow

and (if available in your build):

openclaw channels logs --channel telegram

Also tell me:

• Is your Gateway running locally or on a VPS?
• What exactly happens in the dashboard (blank page / “unauthorized” / “disconnected” / doesn’t load at all)?
• Do you see your Telegram messages showing up in openclaw logs --follow when you DM the bot?

Relevant checklist in the FAQ: https://docs.openclaw.ai/help/faq#the-gateway-is-up-but-replies-never-arrive-what-should-i-check

[sly elk]

Ver:
2026.2.3-1

So running the URL with openclaw dashboard just gets me the spinning circle with "starting openclaw"

Running on a VPS

when I -- follow I get:
2:46:46 info Copy to clipboard unavailable.
12:46:46 info No GUI detected. Open from your computer:
ssh -N -L 18789:127.0.0.1:18789 root@85.209.95.79
Then open:
http://localhost:18789/
http://localhost:18789/?token=6HIDDEN
Docs:
https://docs.openclaw.ai/gateway/remote
https://docs.openclaw.ai/web/control-ui
12:48:41 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
12:50:22 warn [openclaw] Non-fatal unhandled rejection (continuing): TypeError: fetch failed
at node:internal/deps/undici/undici:14902:13
at processTicksAndRejections (node:internal/process/task_queues:105:5)
12:50:30 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)

[slim meadow]

That’s a really useful signal: if Telegram messages don’t show up in openclaw logs --follow at all, the Gateway is almost certainly not receiving updates from Telegram (so it’s not an “agent didn’t answer” problem yet).

Two high-probability causes on a VPS:

1) You’re looking at the wrong instance / wrong user’s state

If the Gateway service is running under a different user than the one you’re using in SSH (common: service runs as openclaw/your user, but you’re SSH’d as root), then openclaw logs --follow won’t be the logs for the running service.

On the VPS, paste:

openclaw --version
openclaw gateway status

gateway status will show whether RPC probe is ok and whether Config (cli) vs Config (service) differ (that’s the smoking gun for “wrong user / wrong config”).

2) The Telegram channel isn’t actually running (token not resolved) or can’t reach Telegram

Next, on the VPS, paste:

openclaw channels status --probe

That will usually tell us if Telegram is disabled, missing a token, failing DNS/HTTPS, etc.

Also: the log line you shared:

Non-fatal unhandled rejection ... TypeError: fetch failed

…strongly hints at a network/DNS/IPv6 egress issue (or similar) on the server. If channels status --probe points at Telegram connectivity, I’ll give you the exact next step (often it’s IPv6 vs IPv4 to api.telegram.org).

Dashboard note (from your snippet)

The openclaw dashboard output you pasted is correct for a VPS: you must run the SSH tunnel from your computer and keep it running:

ssh -N -L 18789:127.0.0.1:18789 root@85.209.95.79

Then open the token URL (/?token=...) locally.

---

Send openclaw gateway status + openclaw channels status --probe and we can narrow it down to “wrong service/user”, “telegram token/config”, or “network can’t reach Telegram”.

That snippet is actually openclaw dashboard output, not the Gateway log stream. The “SSH -L 18789…” part is expected on a VPS with no GUI.

1) Dashboard: make sure you’re opening it the right way

From your laptop/desktop (not on the VPS), run exactly:

ssh -N -L 18789:127.0.0.1:18789 root@85.209.95.79

Then open the token URL locally (the http://localhost:18789/?token=... one).

Important: don’t try to open http://<vps-ip>:18789/ directly in your browser — the Control UI can fail over plain HTTP/non-localhost due to secure-context/WebCrypto requirements. (Docs: https://docs.openclaw.ai/gateway/troubleshooting#control-ui-fails-on-http-device-identity-required--connect-failed)

2) Telegram: if DMs don’t show up in logs, the Gateway isn’t receiving updates

On the VPS, paste outputs of:

openclaw --version
openclaw gateway status
openclaw channels status --probe
openclaw logs --follow

Then (while openclaw logs --follow is running) DM the Telegram bot again and see if anything shows up.

What I’m looking for

• In openclaw gateway status: do Config (cli) and Config (service) differ? If yes, you’re likely editing/inspecting one config while the daemon runs another (often happens when running CLI as root but the service runs under a different user).
• In channels status --probe: whether Telegram is enabled, has a token resolved, and whether it can reach api.telegram.org.

3) About TypeError: fetch failed

That usually points to egress DNS/IPv6/network trouble on the VPS (or a proxy misconfig). channels status --probe will usually name the exact failing endpoint.

Drop those four command outputs and we can narrow it down quickly.

[sly elk]

1. openclaw --version
   openclaw gateway status
   2026.2.3-1

🦞 OpenClaw 2026.2.3-1 (d84eb46) — Works on Android. Crazy concept, we know.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-10.log
Command: /usr/bin/node /usr/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 49696, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status

2. openclaw channels status --probe

🦞 OpenClaw 2026.2.3-1 (d84eb46) — I read logs so you can keep pretending you don't have to.

│
◇
Gateway reachable.

• Telegram default: enabled, configured, running, mode:polling, bot:@DamonTekBot, token:config, works

[slim meadow]

Nice — that output means the Gateway is healthy and you’re not dealing with a “wrong config / wrong service” situation:

• RPC probe: ok
• Config (cli) == Config (service)
• Telegram: enabled, configured, running … works

So now we need to figure out why you don’t see inbound Telegram messages.

A) Quick sanity check: DM vs group

Are you trying to talk to the bot in a DM or in a group?

• If it’s a group: Telegram “privacy mode” + mention-gating can mean the bot never receives most messages (so nothing shows in logs). Try explicitly @mention the bot in the group, or just DM it for the next test.
• If it’s a DM: the bot should definitely receive updates, and we should see them in Telegram channel logs.

(Ref: https://docs.openclaw.ai/channels/telegram#token--privacy--permissions-telegram-side)

B) Tail Telegram-only logs (best signal)

On the VPS, run:

openclaw channels logs --channel telegram --lines 300

Then DM @DamonTekBot something simple like ping.

• If you see the inbound update logged, Telegram is reaching the Gateway and we move on to why it’s not replying (models/auth/pairing/etc).
• If you still see nothing Telegram-related when you DM, double-check you’re DMing the exact bot handle shown: @DamonTekBot (people often end up messaging an old bot / wrong token).

C) If inbound shows up but no reply: pairing/allowlist is the next suspect

Run:

openclaw pairing list telegram

If your DM is blocked by dmPolicy: "pairing" you’ll see a pending request/code there.

D) Dashboard (separate issue, but now it should work)

Since you’re bind=loopback, the dashboard is local-only. From your own computer:

ssh -N -L 18789:127.0.0.1:18789 root@85.209.95.79

Then open the token URL printed by openclaw dashboard (the /?token=... one).

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

If you paste the output of openclaw channels logs --channel telegram --lines 300 right after sending a DM, we can finish this quickly.

[sly elk]

A) individual bot

B) Here's the log, but the bot name is wrong:
Log file: /tmp/openclaw/openclaw-2026-02-10.log
Channel: telegram
2026-02-10T03:32:05.351Z info {"subsystem":"gateway/channels/telegram"} [default] starting provider
2026-02-10T03:32:05.618Z error {"subsystem":"gateway/channels/telegram"} telegram setMyCommands failed: Call to 'setMyCommands' failed! (401: Unauthorized)
2026-02-10T03:32:05.625Z error {"subsystem":"gateway/channels/telegram"} [default] channel exited: Call to 'getMe' failed! (401: Unauthorized)
2026-02-10T03:56:08.813Z info {"subsystem":"gateway/channels/telegram"} [default] starting provider (@DamonTekBot)
2026-02-10T12:33:04.654Z info {"subsystem":"gateway/channels/telegram"} [default] starting provider (@DamonTekBot)

The bot I'm trying to message is:@DamonBerusBot

C) openclaw pairing list telegram

🦞 OpenClaw 2026.2.3-1 (d84eb46) — The only crab in your contacts you actually want to hear from. 🦞

No pending telegram pairing requests.

[slim meadow]

Yep — that explains everything: your Gateway is currently configured for @DamonTekBot, but you’re DM’ing @DamonBerusBot.

openclaw channels status --probe reporting bot:@DamonTekBot means the token your Gateway has resolves to that bot. OpenClaw can only receive messages for the bot token it’s running.

Fix options (pick one)

Option 1 (fastest): message the bot the Gateway is actually running

DM @DamonTekBot and send ping (or /start).
Then run:

openclaw channels logs --channel telegram --lines 200

You should see inbound activity.

Option 2: switch OpenClaw to use @DamonBerusBot

Get the BotFather token for @DamonBerusBot, then on the VPS:

openclaw config set channels.telegram.botToken "123456:ABC..." # Berus token
openclaw gateway restart
openclaw channels status --probe

After restart, channels status --probe should show bot:@DamonBerusBot.

About the 401 in your logs

These lines:

• setMyCommands failed (401: Unauthorized)
• getMe failed (401: Unauthorized)

…mean the token was invalid at that time (wrong token, revoked, or typo). So if you recently regenerated tokens in BotFather, make sure the Gateway config matches the current token.

If you do Option 2 and it still doesn’t receive DMs, paste the fresh output of:

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

(right after you DM the bot once).

[sly elk]

So I'm just going to throw in the towel. I think the server is a little hosed from all the stuff my previous bot asked me to do. I'm going to reisntall the OS and start fresh. No info of consequence will be lost. Thanks for the help,.

[autumn elm]

claude fixxed my setup from console - what he did What I did:

1. openclaw gateway stop — stopped the crash loop
2. openclaw gateway uninstall — removed the stale service file
3. openclaw gateway install — created a fresh service file pointing to v2026.2.9
4. openclaw gateway start — started the gateway

[slim meadow]

You don’t need to reinstall the whole OS for this one — based on your logs it was basically:

• OpenClaw is running @DamonTekBot
• you were DM’ing @DamonBerusBot
• plus an earlier 401 Unauthorized suggests the Telegram token was wrong/revoked at some point

That’s all fixable with a clean OpenClaw/channel reset.

If you still want a “fresh start” without nuking the VPS, this is the usual safe ladder (run on the VPS, as the same user that owns ~/.openclaw + the systemd user service):

1) Refresh the Gateway service (often fixes “weird/stale” installs)

openclaw gateway stop
openclaw gateway uninstall
openclaw gateway install
openclaw gateway start

(What iShowSpED posted is exactly this pattern — it fixes stale/crash-looping service files.)

2) Point Telegram at the correct bot

Make sure channels.telegram.botToken is the BotFather token for @DamonBerusBot, then:

openclaw gateway restart
openclaw channels status --probe

You want channels status --probe to show bot:@DamonBerusBot.

3) “Actually wipe OpenClaw” (still not an OS reinstall)

If you truly don’t care about losing OpenClaw state/sessions:

openclaw gateway stop
# then delete/trash ~/.openclaw (and reinstall/onboard)

(If you do this, you’ll need to re-onboard and re-add channels.)

If you change your mind and want to try the quick fix, paste openclaw channels status --probe after you set the Berus token and restart — that’ll confirm in one line whether the Gateway is even attached to the right bot.

[somber fractal]

Hi, I'm the developer of u/ruah. I've read the rules and noticed Rule 6/7. I'm currently facing a ban issue due to a challenge failure (#2). Which would be more effective for an appeal: following the git install method mentioned in Rule 7, or should I wait for a response on my GitHub issue?

[slim meadow]

A git (from-source) install is useful for debugging OpenClaw, but it generally won’t help with an actual ban/appeal by itself.

What to do depends on what you mean by “ban”:

1. If you’re banned from a platform/community (e.g. Discord / a service) due to “challenge failure (#2)”
   Only that platform’s mods/system can reverse it, so the most effective path is to follow the official appeal process for that platform. A git install won’t change the outcome there.

2. If “ban” means your OpenClaw setup is being blocked / failing a “challenge” in the OpenClaw stack (auth / webhook / Cloudflare / etc.)
   Then your GitHub issue is the right place, and doing a git install can help in parallel by answering: “is this already fixed on main?” If you try it, post back to the GitHub issue with:

• exact error text
• openclaw --version
• openclaw status --all (redacts secrets)
• a short log excerpt around the failure

If you paste the exact “challenge failure (#2)” message (where you saw it + which system is issuing it), I can tell you which of the two cases it is and what the fastest next step is.

[somber fractal]

Hi Krill, thanks for the info. It seems Case 1. My account (u/ruah) had a verification issue due to a technical error in my v5.0.0 build.

A bug in my connection script caused the failed response. I’ve already updated the code to fix this. I will now follow the official steps to request a review. Thanks again!

[slim meadow]

Got it — yep, that’s squarely Case 1.

Best appeal is usually a short, concrete writeup:

• it was a technical regression in your v5.0.0 connection script
• it caused the challenge response to fail
• you’ve patched it (optionally link commit / release tag)
• you’re requesting a review / re-verification

If they allow attachments, include whatever minimal proof they accept (new build version, commit hash, a log snippet showing the corrected challenge response).

If you don’t get a response after their stated SLA, then it’s worth nudging via whatever official channel they specify — but otherwise you’re on the right track.

[somber fractal]

Krill, thanks for the help. I fixed the issue in my build. I tried to provide more details, but my messages are not sending properly here for some reason. I'll just follow the official steps you mentioned. Appreciate your time!

[slim meadow]

No worries — Discord can get flaky (and sometimes rate limits / permissions / thread settings make messages “feel” like they vanish).

If you need to capture the details somewhere reliable for the appeal, the easiest is:

• put the technical writeup + fix link in a paste (gist / pastebin) and include that URL in the appeal, or
• link the commit / release tag directly.

Good luck with the review — sounds like you’ve done the right fix already.

[somber fractal]

Actually, my background is in acting, so I'm still quite a novice when it comes to development. Please bear with me if I seem a bit slow! ^^;;

[slim meadow]

That’s totally fine — you’re already doing the important dev skill: you found the failure mode, fixed the bug, and you’re following the right process to get it reviewed.

If it helps, here’s a simple “appeal template” you can copy/paste and fill in:

Subject: Request for review — challenge failure (#2) fixed
Body:

• Account: u/ruah
• What happened: My v5.0.0 build had a bug in the connection script which caused the challenge response to fail (technical error, not abuse).
• Fix: I’ve updated the build to correct the response handling.
• Evidence: (link to commit / release tag / short log snippet if allowed)
• Request: Please re-review / re-verify my account now that the issue is resolved.

If you want, paste your draft appeal text here and I’ll tighten it up so it’s short and clear (without sounding overly technical).

[somber fractal]

"I just posted the appeal on the Hub issues, including my X handle and Agent ID as you suggested. I was honestly feeling quite lost and stuck, so your guidance really means a lot to me. Thank you so much for your help!

[slim meadow]

One quick note: I don’t actually need (and generally wouldn’t recommend) posting extra personal identifiers like your X handle or an agent ID unless the platform’s appeal form explicitly asks for them.

If you already included them and they’re not required, I’d edit the issue and remove/redact them. A clean appeal usually only needs:

• account name (u/ruah)
• what failed (“challenge failure #2 due to a bug/regression”)
• confirmation it’s fixed
• a link to the fix (commit / release tag)

Now it’s mostly a waiting game—follow whatever review/appeal SLA they publish. If you paste the text you posted (redacting anything private), I can help make sure it reads clearly and doesn’t overshare.

[somber fractal]

I see, I think I was just a bit too anxious to get this sorted out. I’ve updated the issue according to the standard format you suggested. Thank you once again for your patience and help!

[slim meadow]

Perfect — that’s the right move.

Now the best thing you can do is just stay consistent and responsive: if they ask for a specific detail (timestamp, build version, exact error text), answer that directly, but otherwise avoid adding extra side info.

If you hit a deadline and don’t hear back, reply once on the same issue with a short “checking in” and the date/time you submitted the appeal.

[somber fractal]

Thanks again for all your help, Krill! I really appreciate the guidance. Have a wonderful day! 🙂