Telegram issues | Friends of the Crustacean 🦞🤝 | Page 1

umbral sable Apr 19, 2026, 1:01 AM

#

2026-04-18T20:01:34.671-05:00 [telegram] deleteMyCommands failed: Network request for 'deleteMyCommands' failed!
2026-04-18T20:01:34.744-05:00 [telegram] setMyCommands failed: Network request for 'setMyCommands' failed!
2026-04-18T20:01:34.745-05:00 [telegram] command sync failed: HttpError: Network request for 'setMyCommands' failed!
2026-04-18T20:01:34.789-05:00 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
2026-04-18T20:01:34.790-05:00 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 21.57s.

thorny otterBOT Apr 19, 2026, 1:01 AM

#

jagged juncoBOT Apr 19, 2026, 1:01 AM

#

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

thorny otterBOT Apr 19, 2026, 1:01 AM

#

glossy obsidianBOT Apr 19, 2026, 1:03 AM

#

That pattern is usually a network reachability problem to api.telegram.org, not a Telegram command bug.

Because deleteMyCommands + setMyCommands + deleteWebhook all fail with the same generic “Network request failed”, I’d check these first:

openclaw --version
openclaw channels status --probe
openclaw channels logs --channel telegram
dig +short api.telegram.org A
dig +short api.telegram.org AAAA

A few notes:

If this is on a VPS / proxy / Docker / WSL2 box, outbound DNS + HTTPS to api.telegram.org is the main suspect.
If IPv6 is flaky on that host, try:

#

channels:
  telegram:
    network:
      autoSelectFamily: false

If the host’s direct egress is unreliable, route Telegram through:

channels:
  telegram:
    proxy: socks5://<user>:<password>@proxy-host:1080

Also, disabling native Telegram commands can stop the setMyCommands noise:

#

channels:
  telegram:
    commands:
      native: false

…but that won’t fix the deleteWebhook failure, so I’d treat networking as the real issue first.

Docs:

If you paste the output of openclaw --version and openclaw channels status --probe, I can narrow it down fast.

umbral sable Apr 19, 2026, 1:04 AM

#

agent@shell-opentruthprotocol:opentruthprotocol$ openclaw --version
OpenClaw 2026.4.15 (041266a)
agent@shell-opentruthprotocol:opentruthprotocol$ openclaw channels status --probe

🦞 OpenClaw 2026.4.15 (041266a)
I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

│
penclaw channels logs --channel telegram
dig +short api.telegram.org A
dig +short api.telegram.org AAAA◇
Gateway not reachable: Error: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/agent/.openclaw/openclaw.json
Bind: lan
Gateway not reachable; showing config-only status.
Config: /home/agent/.openclaw/openclaw.json
Mode: local

Telegram default: enabled, not configured, mode:polling

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

glossy obsidianBOT Apr 19, 2026, 1:05 AM

#

Nice, version looks fine. The bigger issue is actually before Telegram API reachability now:

Gateway is not reachable
- gateway closed (1006 abnormal closure)
Telegram is enabled but not configured
- Telegram default: enabled, not configured, mode:polling

So I would not chase api.telegram.org yet. I’d fix these in order:

openclaw status
openclaw gateway status
openclaw gateway restart
openclaw logs --follow
openclaw doctor

#

If the gateway still drops, paste the startup logs from openclaw logs --follow.

Then check your config at:

/home/agent/.openclaw/openclaw.json

Telegram needs a usable credential, usually one of:

channels.telegram.botToken
channels.telegram.tokenFile

Docs reference:

#

Also, your pasted block does not show actual output from:

openclaw channels logs --channel telegram
dig +short api.telegram.org A
dig +short api.telegram.org AAAA

It looks like those may not have executed cleanly, so after the gateway is up, run those separately and paste the results.

If you want, paste the channels.telegram section from openclaw.json with the token redacted, and I’ll sanity check it.

umbral sable Apr 19, 2026, 1:07 AM

#

OpenClaw Status Report Summary
System Overview

Version: 2026.4.15 (Stable)

Environment: Linux 6.12.44 | Node 22.22.2

Dashboard: http://172.17.0.9:18789/

Active Model: openrouter/elephant-alpha (200k context)

Session: agent:main:main active (18k tokens used / 9%)

Gateway & Connectivity

State: Unreachable (Code 1006)

Listener: Local loopback ws://127.0.0.1:18789

Service: systemd not installed (Manual foreground execution required)

Channel Status

Telegram: ON (Setup Required)

Status: Missing token configuration.

Security Audit (1 Critical, 4 Warnings)

CRITICAL: Small models (<300B) like nemotron-3 detected without active sandboxing.

Fix: Enable agents.defaults.sandbox.mode="all".

WARN: Insecure UI authentication is enabled.

WARN: No authentication rate limiting is configured for non-loopback binds.

WARN: Ineffective denyCommands entries detected in gateway node configuration.

glossy obsidianBOT Apr 19, 2026, 1:08 AM

#

Yep, that summary is much clearer.

Your immediate Telegram blocker is not the network error anymore, it’s this:

Telegram: ON (Setup Required)
Status: Missing token configuration
Gateway: Unreachable (1006)

So the next steps are:

Add a Telegram bot token
In ~/.openclaw/openclaw.json, configure Telegram with either botToken or tokenFile.

Minimal example:

#

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}

You can also use env fallback for the default account:

TELEGRAM_BOT_TOKEN=...

#

Run the Gateway and keep it alive
Your status says there’s no systemd service, so this needs to run manually in a terminal.
Then re-check

openclaw channels status --probe
openclaw logs --follow

Approve the first DM

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

A couple of useful notes:

#

Telegram does not use openclaw channels login.
The sandbox/auth warnings are separate from getting Telegram online. Worth fixing, but not the blocker here.

Docs:

If you paste your redacted channels.telegram config block, I can sanity check it quickly.

umbral sable Apr 19, 2026, 1:09 AM

#

glossy obsidian 2. **Run the Gateway and keep it alive** Your status says there’s **no system...

agent@shell-opentruthprotocol:opentruthprotocol$ openclaw channels status --probe

🦞 OpenClaw 2026.4.15 (041266a) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

│
penclaw logs --follow◇
Gateway not reachable: Error: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/agent/.openclaw/openclaw.json
Bind: lan
Gateway not reachable; showing config-only status.
Config: /home/agent/.openclaw/openclaw.json
Mode: local

Telegram default: enabled, not configured, mode:polling

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

glossy obsidianBOT Apr 19, 2026, 1:09 AM

#

Yep, same two blockers, and I think your shell is eating the second command.

This line:

│
penclaw logs --follow◇

is not actual openclaw logs --follow output. It looks like the prompt/UI is mangling pasted multi-command input. So please run one command at a time.

What your output still confirms:

Gateway is not running / not reachable
- gateway closed (1006 ...)
Telegram is still not configured
- Telegram default: enabled, not configured, mode:polling

#

So the real next move is:

1) Fix Telegram config

Add a token in ~/.openclaw/openclaw.json:

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc"
    }
  }
}

(or use TELEGRAM_BOT_TOKEN for the default account)

#

2) Start the Gateway manually

Since your machine says manual foreground execution required, make sure the Gateway is actually running in another terminal.

If you’re not sure which command to use on that setup, run:

openclaw gateway --help

3) Then run these separately, one by one

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

If you paste the redacted channels.telegram block plus the output of openclaw gateway status, I can tell you exactly what’s still missing.

umbral sable Apr 19, 2026, 1:13 AM

#

OpenClaw Log & Status Summary
Gateway Status

Process: Active (PID 1122).

Listener: Binding successful on 0.0.0.0:18789 (all interfaces).

RPC Probe: OK. The CLI can successfully communicate with the gateway via loopback.

Reachability: Dashboard is live at http://172.17.0.9:18789/.

Critical Errors & Blockers

Pairing Loop: The logs show a massive flood of pairing required (Code 1008) errors. The CLI is repeatedly attempting a "scope upgrade" but is being rejected because the device isn't paired/authorized.

Telegram Failure: The provider is in a crash loop. It is failing to sync commands and delete webhooks (Network request failed), confirming the sandbox egress is still blocked.

Model Warmup: Failed for openrouter/openrouter/elephant-alpha. The gateway reports it as an Unknown model, meaning OpenRouter likely doesn't recognize that specific alias or the API key isn't authorized for it.

Current Config State

Model: Falling back to openrouter/openrouter/elephant-alpha.

Security: allowInsecureAuth is enabled (Warning).

Service: systemd is confirmed unavailable (Container mode).

I am using Docker sandbox

glossy obsidianBOT Apr 19, 2026, 1:14 AM

#

Much better, now we’ve got the real picture.

A few things are separate here:

1) The 1008 pairing loop

That means the CLI/browser device is trying to connect with scopes it hasn’t been approved for yet.

Run:

openclaw devices list
openclaw devices approve <requestId>

If it keeps saying “scope upgrade”, approve the new pending requestId, not the old one.

2) The Telegram network failure

#

The docs map setMyCommands / deleteWebhook network errors to DNS/HTTPS reachability to api.telegram.org.

Since you’re in Docker/container land, check outbound reachability from the gateway/container, not just from your host:

dig +short api.telegram.org A
dig +short api.telegram.org AAAA

If IPv6 is busted there, try:

{
  channels: {
    telegram: {
      network: {

#

        autoSelectFamily: false
      }
    }
  }
}

Also, if your previous status was still saying “Telegram not configured”, make sure you actually have channels.telegram.botToken or tokenFile set. No token means Telegram can’t come up cleanly anyway.

3) The model warmup error

That’s separate from Telegram.

openrouter/openrouter/elephant-alpha looks wrong on format alone. OpenClaw expects models as:

#

provider/model

not:

provider/provider/model

So I’d fix that duplicated prefix next.

4) Docker sandbox note

One important gotcha from the docs: Docker sandbox containers default to network: "none". That matters for sandboxed agent work. But Telegram startup happens in the gateway path, so for this specific Telegram issue I’d focus on gateway/container egress first.

Docs:

https://docs.openclaw.ai/channels/telegram

#

If you paste:

openclaw devices list
whether channels.telegram.botToken is set
dig +short api.telegram.org A and AAAA

…I can tell you which blocker is actually left.

umbral sable Apr 19, 2026, 1:16 AM

#

glossy obsidian - <https://docs.openclaw.ai/install/docker> - <https://docs.openclaw.ai/gateway/...

Everything is positive, no issues with those

glossy obsidianBOT Apr 19, 2026, 1:17 AM

#

If all of those are genuinely clean, then we’re past first-line triage and I need the literal raw logs, not a summary.

Right now the interesting branch is:

direct Bot API access works from the same container/process path, but
OpenClaw’s Telegram client still fails

That usually narrows it to one of these:

BOT_COMMANDS_TOO_MUCH
TypeError: fetch failed
proxy / custom fetch / Node 22 abort weirdness
bad Telegram-specific config like proxy, apiRoot, or webhook settings

Please paste the exact output of one of these, around the first Telegram failure:

#

openclaw channels logs --channel telegram

or

openclaw logs --follow

Also paste the redacted channels.telegram block, specifically these fields if present:

botToken (just say “set”, don’t paste it)
proxy
apiRoot
commands
network

#

webhookUrl
webhookSecret

One very high-signal check, run privately from the same container and just tell me whether it succeeds:

curl -sS "https://api.telegram.org/bot<TOKEN>/getMe"

If that fails, it’s still network/TLS/proxy.
If that works, then I’d focus on OpenClaw config/runtime, especially channels.telegram.proxy, custom proxy env, or a Node 22 fetch/proxy mismatch.

At this point the summaries are flattening the part that actually matters, so the raw log line is the thing I need.

umbral sable Apr 19, 2026, 1:19 AM

#

Log file: /tmp/openclaw/openclaw-2026-04-18.log
Channel: telegram
2026-04-18T19:08:16.853-05:00 info {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 54 commands visible.
2026-04-18T19:08:16.887-05:00 error {"subsystem":"gateway/channels/telegram"} telegram deleteMyCommands failed: Network request for 'deleteMyCommands' failed!
2026-04-18T19:08:16.956-05:00 error {"subsystem":"gateway/channels/telegram"} telegram setMyCommands failed: Network request for 'setMyCommands' failed!
2026-04-18T19:08:16.957-05:00 error {"subsystem":"gateway/channels/telegram"} Telegram command sync failed: HttpError: Network request for 'setMyCommands' failed!
2026-04-18T19:08:16.977-05:00 error {"subsystem":"gateway/channels/telegram"} telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
2026-04-18T19:08:16.978-05:00 error {"subsystem":"gateway/channels/telegram"} Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 30s.
2026-04-18T19:08:47.089-05:00 info {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep

agent@shell-opentruthprotocol:opentruthprotocol$ curl -sS "https://api.telegram.org/bot<TOKEN>/getMe"
Blocked by network policy: domain api.telegram.org:443
detail: no matching allow rule — blocked by default deny policy

glossy obsidianBOT Apr 19, 2026, 1:19 AM

#

Nice, we found it.

This is the root cause:

Blocked by network policy: domain api.telegram.org:443
detail: no matching allow rule — blocked by default deny policy

So the Telegram failures are exactly what the docs suggest: outbound HTTPS to api.telegram.org is blocked.

A few clarifications:

The Telegram menu text exceeded... line is just informational
This is not BOT_COMMANDS_TOO_MUCH
deleteMyCommands, setMyCommands, and deleteWebhook all fail because the gateway cannot reach Telegram at all

#

Fix

Allow outbound access from the gateway/container to:

api.telegram.org:443

If your policy only supports hostname patterns, allow api.telegram.org over HTTPS.
If it only supports suffix/domain rules, you may need *.telegram.org, but minimum is api.telegram.org:443.

If you can’t open direct egress, use a proxy instead:

{
  channels: {

#

    telegram: {
      proxy: "socks5://user:pass@proxy-host:1080"
    }
  }
}

After changing the policy

Restart the gateway, then re-test:

curl -sS "https://api.telegram.org/bot<TOKEN>/getMe"
openclaw channels status --probe
openclaw channels logs --channel telegram

#

If curl ... /getMe works, Telegram should stop crash-looping.

There’s still a separate 1008 pairing issue for the CLI/device auth path, but for the Telegram thread specifically, this is the blocker.

umbral sable Apr 19, 2026, 1:20 AM

#

agent@shell-opentruthprotocol:opentruthprotocol$ curl -sS "https://api.telegram.org/bot<TOKEN>/getMe"
{"ok":false,"error_code":404,"description":"Not Found"}agent@shell-opentruthprotocol:opentruthprotocol$

glossy obsidianBOT Apr 19, 2026, 1:21 AM

#

Good, that changes the diagnosis again.

If you used the real token and only redacted it in chat, then:

network reachability is fixed
the remaining problem is now the token itself

getMe should return bot info. A plain:

{"ok":false,"error_code":404,"description":"Not Found"}

usually means one of these:

wrong bot token
malformed token in config/file

#

accidental extra characters, quotes, or whitespace/newline

So I’d do this next:

Regenerate/copy the token from BotFather
Update channels.telegram.botToken (or the tokenFile)
If using tokenFile, make sure it contains only the token
Restart the gateway
Re-test:

curl -sS "https://api.telegram.org/bot<REAL_TOKEN>/getMe"

You want a response with bot metadata, not 404.

So the progression is:

#

first blocker: network policy
current blocker: bad/malformed Telegram token

If you want, paste the redacted channels.telegram block and whether you’re using botToken or tokenFile, and I’ll check for the usual formatting mistakes.

umbral sable Apr 19, 2026, 1:23 AM

#

agent@shell-opentruthprotocol:opentruthprotocol$ TELEGRAM_BOT_TOKEN=(REDACTED)agent@shell-opentruthprotocol:opentruthprotocol$ curl -sS "https://api.telegram.org/bot<REAL_TOKEN>/getMe"
{"ok":false,"error_code":404,"description":"Not Found"}agent@shell-opentruthprotocol:opentruthprotocol$

glossy obsidianBOT Apr 19, 2026, 1:24 AM

#

Two important gotchas here:

In the pasted command, you’re still showing the <REAL_TOKEN> placeholder, so I can’t tell whether the shell actually used the real token or whether that’s just redaction in chat.
In bash, this:

TELEGRAM_BOT_TOKEN=...

does not export the variable to child processes like OpenClaw. If you want env fallback, use:

export TELEGRAM_BOT_TOKEN='...'

I’d test it like this, so there’s no copy/paste ambiguity:

#

export TELEGRAM_BOT_TOKEN='...'
curl -sS "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getMe"

Results:

If that returns bot info JSON, the token is valid, and OpenClaw probably isn’t reading the same token. Then restart the gateway after exporting it, or put it in channels.telegram.botToken / tokenFile.
If that still returns 404 Not Found, the token itself is bad or malformed. In that case, get a fresh token from BotFather and replace it.

So at this point I’m pretty confident the remaining issue is one of:

token not actually exported to OpenClaw
wrong token
malformed token in config/tokenFile

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

umbral sable Apr 19, 2026, 1:25 AM

#

glossy obsidian ```bash export TELEGRAM_BOT_TOKEN='...' curl -sS "https://api.telegram.org/bot${...

agent@shell-opentruthprotocol:opentruthprotocol$ curl -sS "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getMe"
{"ok":true,"result":{"id":(REDACTED),"is_bot":true,"first_name":"Claw","username":"redacted","can_join_groups":true,"can_read_all_group_messages":false,"supports_inline_queries":false,"can_connect_to_business":false,"has_main_web_app":false,"has_topics_enabled":false,"allows_users_to_create_topics":false,"can_manage_bots":false}}agent@shell-opentruthprotocol:opentruthprotocol$

glossy obsidianBOT Apr 19, 2026, 1:25 AM

#

Perfect, that’s the breakthrough.

So now we know:

network is fine
the token is valid
Telegram itself is fine

That means the remaining issue is almost certainly:

the gateway process is not seeing that token, or
a different/stale token in config is overriding the env var

And the docs matter here: config wins over env fallback.

What I’d check next

#

If you want to use env fallback

Make sure the gateway is started after the export, in the same environment/container that actually runs OpenClaw.

export TELEGRAM_BOT_TOKEN='...'
# restart gateway/container after this

If the gateway is already running, it will not pick up the new env var until restarted.

If you have `channels.telegram.botToken` or `tokenFile` in config

That may be overriding the good env token. Fix or remove the stale value.

So the practical fix is:

either put the known-good token in channels.telegram.botToken
or remove the bad config token and restart the gateway with TELEGRAM_BOT_TOKEN exported in the runtime environment

#

Then re-test:

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

At this point I would specifically inspect:

channels.telegram.botToken
channels.telegram.tokenFile
whether the running gateway/container was restarted after setting TELEGRAM_BOT_TOKEN

You’re very close now. If you paste the redacted channels.telegram block, I can probably point at the exact override immediately.

And if this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow picks it up.

umbral sable Apr 19, 2026, 1:27 AM

#

opentruthprotocol$ openclaw channels status --probe

🦞 OpenClaw 2026.4.15 (041266a) — If you can describe it, I can probably automate it—or at least make it funnier.

│
◇
Gateway reachable.

Telegram default: enabled, not configured, stopped, mode:polling, error:not configured

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
agent@shell-opentruthprotocol:opentruthprotocol$ openclaw channels logs --channel telegram

🦞 OpenClaw 2026.4.15 (041266a) — No $999 stand required.

Log file: /tmp/openclaw/openclaw-2026-04-18.log
Channel: telegram
2026-04-18T19:08:16.853-05:00 info {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 54 commands visible.
2026-04-18T19:08:16.887-05:00 error {"subsystem":"gateway/channels/telegram"} telegram deleteMyCommands failed: Network request for 'deleteMyCommands' failed!
2026-04-18T19:08:16.956-05:00 error {"subsystem":"gateway/channels/telegram"} telegram setMyCommands failed: Network request for 'setMyCommands' failed!
2026-04-18T19:08:16.957-05:00 error {"subsystem":"gateway/channels/telegram"} Telegram command sync failed: HttpError: Network request for 'setMyCommands' failed!
2026-04-18T19:08:16.977-05:00 error {"subsystem":"gateway/channels/telegram"} telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
2026-04-18T19:08:16.978-05:00 error {"subsystem":"gateway/channels/telegram"} Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 30s.
2026-04-18T19:08:47.089-05:00 info {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep

glossy obsidianBOT Apr 19, 2026, 1:27 AM

#

Yep, this nails it.

The current truth is this line:

- Telegram default: enabled, not configured, stopped, mode:polling, error:not configured

So right now, the running gateway still does not see any Telegram token at all.

A couple of important implications:

your curl ... ${TELEGRAM_BOT_TOKEN} test only proved the token works in your interactive shell
it did not prove the gateway process/container has that env var
the channels logs output is just old history from /tmp/openclaw/openclaw-2026-04-18.log, from before you fixed egress

So the real remaining issue is:

#

token is not present in the gateway runtime

Since you’re in container/manual mode, the clean fixes are:

Option A, simplest

Put the token directly in config:

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "..."
    }
  }
}

#

Option B

Pass TELEGRAM_BOT_TOKEN into the actual gateway/container startup environment, then restart that gateway/container.

Just exporting it in the shell where you ran curl is not enough if the gateway is already running elsewhere.

What I’d do next

Check ~/.openclaw/openclaw.json
Make sure channels.telegram.botToken or tokenFile is set there, or
Ensure the container/process that launches OpenClaw gets TELEGRAM_BOT_TOKEN
Restart the gateway/container
Re-run:

openclaw channels status --probe

You want it to stop saying not configured.

#

At this point, I’m confident the Telegram problem is no longer network, it’s just runtime config injection. If you paste the redacted channels.telegram block or how you launch the gateway/container, I can tell you exactly where the token needs to go.

umbral sable Apr 19, 2026, 1:34 AM

#

🦞 OpenClaw 2026.4.15 (041266a) — Your config is valid, your assumptions are not.

│
◇
Gateway reachable.

Telegram default: enabled, configured, stopped, mode:polling, token:env, probe failed, error:Call to 'deleteWebhook' failed! (401: Unauthorized)

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
agent@shell-opentruthprotocol:opentruthprotocol$

glossy obsidianBOT Apr 19, 2026, 1:34 AM

#

That’s a very useful state.

Now we know:

OpenClaw sees a Telegram token from env (token:env)
Telegram rejects that token with 401: Unauthorized
your manual curl ... /getMe succeeds with a valid token

So the token OpenClaw is probing with is almost certainly not the same token you just tested successfully.

token:env tells us the source, not that it’s the right env value in the right process/container.

What I’d do now

The cleanest fix is to remove env ambiguity completely:

Best option

#

Put the known-good token directly in config:

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "KNOWN_GOOD_TOKEN"
    }
  }
}

Then restart the gateway/container and re-run:

#

openclaw channels status --probe

If you want to keep env-based config

Then check the actual runtime environment of the gateway container/process, not just your current shell.

Common causes:

stale container env
old .env
different shell/session than the gateway startup
multiple env injection points
account-specific override / old token somewhere else

Short version

You’re no longer debugging networking.

#

You’re debugging which token OpenClaw is actually using.

And 401 Unauthorized on deleteWebhook is the classic sign that the runtime token is wrong.

If you paste how you launch the gateway/container, I can tell you the exact place to put the token so OpenClaw stops picking up the wrong one.

If this solves it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

umbral sable Apr 19, 2026, 1:40 AM

#

🦞 OpenClaw 2026.4.15 (041266a) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

│
◇
Gateway reachable.

Telegram default: enabled, configured, running, mode:polling, bot:@redacted, token:env, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
agent@shell-opentruthprotocol:opentruthprotocol$

glossy obsidianBOT Apr 19, 2026, 1:40 AM

#

Nice, that’s fixed 🎉

This line is the one that matters:

- Telegram default: enabled, configured, running, mode:polling, bot:@redacted, token:env, works

So the final path was basically:

egress/network policy blocked api.telegram.org
then token/runtime env mismatch
now the gateway sees the right env token and Telegram is healthy

If you want to do a quick functional check next:

#

openclaw pairing list telegram

Then DM the bot and approve the first pairing if you’re using the default dmPolicy: "pairing".

And if this thread solved it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

umbral sable Apr 19, 2026, 1:41 AM

#

agent@shell-opentruthprotocol:opentruthprotocol$ openclaw pairing list telegram

🦞 OpenClaw 2026.4.15 (041266a) — More integrations than your therapist's intake form.

No pending telegram pairing requests.
agent@shell-opentruthprotocol:opentruthprotocol$

glossy obsidianBOT Apr 19, 2026, 1:42 AM

#

That’s expected.

For Telegram, a pairing request only shows up after an unknown sender actually messages the bot while dmPolicy: "pairing" is enabled.

One gotcha from the docs: /start by itself does not generate a pairing code.

So the next step is:

DM the bot a normal message, like hi
Then run:

openclaw pairing list telegram

If you want immediate owner access instead of pairing every new DM, the docs recommend using:

#

dmPolicy: "allowlist"
your numeric Telegram user ID in channels.telegram.allowFrom

Docs: https://docs.openclaw.ai/start/faq#i-ran-start-in-telegram-but-did-not-get-a-pairing-code

And if this thread solved the original Telegram issue, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

#Telegram issues

1) Fix Telegram config

2) Start the Gateway manually

3) Then run these separately, one by one

1) The 1008 pairing loop

2) The Telegram network failure

3) The model warmup error

4) Docker sandbox note

Fix

After changing the policy

What I’d check next

If you want to use env fallback

If you have channels.telegram.botToken or tokenFile in config

So the real remaining issue is:

Option A, simplest

Option B

What I’d do next

What I’d do now

Best option

If you want to keep env-based config

Short version

If you have `channels.telegram.botToken` or `tokenFile` in config