HTTP 401: Invalid Authentication | Friends of the Crustacean 🦞🤝 | Page 1

vital latchBOT Feb 17, 2026, 3:31 PM

#

That Call to 'getMe' failed! (401: Unauthorized) is Telegram telling you: the bot token you’re using is invalid (typo, wrong token, or it was regenerated/revoked).

Checklist to fix:

Re-copy the token from BotFather
- In Telegram, open @BotFather → your bot → token (or /token)
- Make sure you paste only the token (it looks like 123456789:AA...) — no quotes, no extra spaces/newlines.
Confirm OpenClaw is using the right config key
- It must be channels.telegram.botToken (not token, etc.)
  Docs: https://docs.openclaw.ai/channels/telegram and https://docs.openclaw.ai/gateway/configuration-reference#telegram
Quick external sanity test (proves whether the token is valid)
```
curl "https://api.telegram.org/bot<PASTE_TOKEN_HERE>/getMe"
```
- If that returns 401 too → the token is definitely wrong/revoked.

#

If it returns "ok": true → token is fine; then it’s likely OpenClaw is reading a different token than you think (wrong config file/service env).

After updating the token, restart the gateway, then rerun:
```
openclaw channels status --probe
```

If you paste your channels.telegram { ... } config block here (redact the token as "...REDACTED..."), I can spot the usual gotchas quickly. Also: what does openclaw --version print?

past grove Feb 17, 2026, 3:46 PM

#

i run the onboard again and changed the telegram token with the correct one but I still get the same error

vital latchBOT Feb 17, 2026, 3:47 PM

#

If you’re still seeing getMe (401: Unauthorized) after you “fixed” the token, it almost always means the running gateway is still using a different token/config than the one you edited (wrong profile, service vs CLI config path, multi-account default token still old, tokenFile still pointing at old token, etc.).

Try this in order:

Prove the token itself is valid

curl "https://api.telegram.org/bot<YOUR_TOKEN>/getMe"

If this is 401 too → the token is not actually valid (wrong bot / revoked / copied wrong).
If this is ok:true → OpenClaw is reading a different token than you think.

Check what token OpenClaw is actually configured to use (watch for multi-account)

openclaw config get channels.telegram

Look specifically for any of these being set (and accidentally stale):

channels.telegram.botToken

#

channels.telegram.tokenFile
channels.telegram.accounts.default.botToken (multi-account mode)

(Please redact the token before pasting output—leave maybe first 6 + last 4 chars.)

Confirm you’re editing the same profile/state as the running gateway
Run:

openclaw status --deep
openclaw gateway status --deep

Those will usually reveal a mismatch like:

you configured with --dev but the gateway service is running without it (or vice-versa), or
“Config (cli)” vs “Config (service)” are different paths.

If you spot a profile mismatch, rerun your config + restart using the same --dev / --profile <name> you use to run the gateway.

#

If you paste the redacted outputs of:

openclaw --version
openclaw gateway status --deep
openclaw config get channels.telegram
…I can tell you exactly which of the above is happening.

past grove Feb 17, 2026, 3:51 PM

#

if I refresh health is ok but if i type in chat it gives me the error

#

{"id":xxx,"is_bot":true,"first_name":"xxxx","username":"xxxxx","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}}

vital latchBOT Feb 17, 2026, 3:53 PM

#

That output means the token you tested is valid (Telegram returned your bot info successfully). So the 401 in OpenClaw is almost certainly because the running gateway is still using a different token/config than the one you tested/edited (profile mismatch, service using a different config file, multi-account default token, tokenFile, etc.).

Do these and paste the outputs (redact the token strings):

Show what config the gateway is using (service vs CLI / profile)

openclaw gateway status --deep
openclaw status --deep

Show the effective Telegram config OpenClaw sees

openclaw config get channels.telegram

Pay attention to whether you have any of these:

botToken
tokenFile

#

accounts: { default: { botToken: ... } } (multi-account)

Restart after changing config

openclaw gateway restart
openclaw channels status --probe

Also: can_read_all_group_messages: false is normal (privacy mode) and only affects group message visibility — it’s not related to a 401.

Once you paste gateway status --deep + config get channels.telegram, I can tell you exactly where the “other” token is coming from.

past grove Feb 17, 2026, 3:56 PM

#

the token is correct

#

Channel │ Enabled │ State │ Detail
│ Telegram │ ON │ OK │ token config (AAHp…zmsY · len 35) · accounts 1/1

Item │ Status │ Detail
│ Gateway │ reachable │ 170ms
│ Telegram │ WARN │ failed (404) - Not Found

vital latchBOT Feb 17, 2026, 3:57 PM

#

If curl .../getMe works, then the token is valid. A 401 inside OpenClaw at that point basically means: the gateway is not using the token you just tested (wrong profile/config path, service using different config, multi-account default still old, or tokenFile pointing at an old token).

Most common gotcha: you ran onboard/configure under a different profile than the running gateway (e.g. --dev vs default, or --profile <name>).

Can you run/paste (redact token values)?

openclaw --version
openclaw gateway status --deep
openclaw config get channels.telegram

Quick self-check while you wait:

If you normally start the gateway with --dev, then also run:
```
openclaw --dev config get channels.telegram
```

#

  openclaw --dev channels status --probe

(If those differ from the non---dev outputs, that’s the whole issue.)

Also check in that config output whether you have either:

channels.telegram.botToken vs channels.telegram.accounts.default.botToken
channels.telegram.tokenFile (if set, it may still be reading an old file)

Once I see the gateway status --deep + channels.telegram block, I can tell you exactly where the stale token is coming from.

past grove Feb 17, 2026, 4:00 PM

#

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Command: /Users/xxxx.nvm/versions/node/v24.13.1/bin/node /Users/xxxx/.nvm/versions/node/v24.13.1/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/Users/xxxx/.nvm/versions/node/v24.13.1/bin/node)
Service config issue: System Node 22+ not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
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 27502)
RPC probe: ok

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

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your .env is showing; don't worry, I'll pretend I didn't see it.

{
"enabled": true,
"dmPolicy": "pairing",
"botToken": "xxxx",
"groupPolicy": "allowlist",
"streamMode": "partial"
}

vital latchBOT Feb 17, 2026, 4:02 PM

#

If curl https://api.telegram.org/bot<TOKEN>/getMe works, then Telegram is fine and the token you tested is valid.

So the 401 in OpenClaw can only really be one of these:

The token in ~/.openclaw/openclaw.json is not the same token you tested with curl (most common)
You updated config but the running gateway didn’t restart / didn’t reload
You’re probing a different gateway instance/profile than you think

Best next test (this removes “maybe I tested a different token”):

TOKEN="$(openclaw config get channels.telegram.botToken | tr -d '\"')"
curl "https://api.telegram.org/bot$TOKEN/getMe"

If this curl returns 401 → the token stored in OpenClaw config is wrong (even if you have a correct token elsewhere).
If this curl returns ok:true → restart + probe:

#

openclaw gateway restart
openclaw channels status --probe --json

If it still shows 401 after that, paste:

openclaw channels logs --channel telegram --lines 200

(keep the token redacted). That log usually reveals which token source/account it’s actually using and why it still thinks auth failed.

past grove Feb 17, 2026, 4:05 PM

#

it returned 404
2026-02-17T16:04:06.287Z info {"subsystem":"gateway/channels/telegram"} [default] starting provider
2026-02-17T16:04:06.560Z error {"subsystem":"gateway/channels/telegram"} telegram deleteMyCommands failed: Call to 'deleteMyCommands' failed! (404: Not Found)
2026-02-17T16:04:06.616Z error {"subsystem":"gateway/channels/telegram"} telegram setMyCommands failed: Call to 'setMyCommands' failed! (404: Not Found)
2026-02-17T16:04:06.722Z error {"subsystem":"gateway/channels/telegram"} [default] channel exited: Call to 'getMe' failed! (404: Not Found)

vital latchBOT Feb 17, 2026, 4:07 PM

#

A 404 Not Found from getMe / setMyCommands / deleteMyCommands is Telegram’s “your bot token is not valid (for this request)” response. With a valid token, getMe should return 200 + JSON, not 404.

Given you previously pasted a successful getMe JSON: you’re almost certainly testing a different token than the one OpenClaw is using now, or the token string in config has extra junk.

Things to check (no need to paste the token):

Token format sanity
The token should look like: digits + colon + letters
Example: 123456789:AAH...
If your config value starts with bot (like bot12345:...) → that’s wrong (people sometimes copy the URL form).
Verify the exact token OpenClaw has matches the one that worked
Run:

openclaw config get channels.telegram.botToken

Compare it character-for-character with BotFather (again: don’t paste it here).

#

Force-set it via CLI (avoids hidden characters) + restart

openclaw config set channels.telegram.botToken "123456789:AA...."
openclaw gateway restart
openclaw channels status --probe

Re-test using the token from config

TOKEN=$(openclaw config get channels.telegram.botToken | tr -d '"')
curl "https://api.telegram.org/bot$TOKEN/getMe"

If that curl is still 404, then the token stored in config is still not the valid one.

If you want, paste the output of (with token redacted) openclaw config get channels.telegram again, but this time also tell me: does your BotFather token begin with a number and contain a :?

vital latchBOT Feb 17, 2026, 4:24 PM

#

That log means Telegram auth is working now.

telegram pairing request happens because your config has:

dmPolicy: "pairing"

So the bot will not answer DMs until you approve your user.

Run:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

#

(Then DM the bot again.)

If you’re “still getting 401” somewhere, can you paste the exact command/output that shows 401 now? Because the Telegram channel log you pasted no longer shows a 401 (it’s past auth and waiting on pairing).

past grove Feb 17, 2026, 4:28 PM

#

Approved telegram sender XXXX.
xpld77@192 ~ % openclaw channels logs --channel telegram --lines 200

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your AI assistant, now without the $3,499 headset.

Log file: /tmp/openclaw/openclaw-2026-02-17.log
Channel: telegram
2026-02-17T16:20:18.471Z info {"subsystem":"gateway/channels/telegram"} [default] starting provider (@XXX)
2026-02-17T16:20:18.797Z info {"module":"telegram-auto-reply"} {"chatId":"XXX","senderUserId":"5827995826","username":"XXX","firstName":"XXX","matchKey":"none","matchSource":"none"} telegram pairing request
2026-02-17T16:20:35.860Z info {"subsystem":"gateway/channels/telegram"} [default] starting provider (@XXX)

#

now tg bot responds but still 401

#

I get 401 when I type in the tg chat or on http://127.0.0.1:18789/chat?

vital latchBOT Feb 17, 2026, 4:31 PM

#

If the Telegram bot is responding in chat now, Telegram auth is fixed.

So the “401” you still see is coming from something else (most commonly Discord token or the Dashboard/Control UI gateway auth), not Telegram.

Can you paste the output of:

openclaw channels status --probe

and (if it’s not obvious from that) the last ~50 lines around the 401:

openclaw channels logs --channel all --lines 200

What to look for:

#

If you see HTTP 401: Invalid Authentication under gateway/channels/discord → your Discord bot token is wrong/old (make sure it’s the bot token from the Discord Developer Portal, not client secret), then restart gateway.
If the 401 happens when opening the Dashboard/Control UI → that’s gateway auth mismatch; easiest fix is to open it via:
```
openclaw dashboard
```
(that URL includes the right token).

Send the channels status --probe output and I’ll tell you exactly which one it is.

#

Two different “401”s can happen here, and they have different fixes:

1) `http://127.0.0.1:18789/chat?` → 401 in the browser

That’s the Control UI/WebChat not authenticated to the Gateway WebSocket.

Do this:

openclaw dashboard
openclaw config get gateway.auth.token

Then in the Control UI, open the settings / “Gateway Access” and paste the Gateway Token (not your Telegram token). After that, reload and /chat will work.

Docs: https://docs.openclaw.ai/web/dashboard and https://docs.openclaw.ai/web/control-ui

2) Telegram chat message → bot “responds but still 401”

#

If Telegram is receiving/sending messages, Telegram auth is fine. A 401 at message time is usually the model provider/API key failing (wrong/missing key in the LaunchAgent environment).

Run and paste the output (redact secrets):

openclaw models status
openclaw logs --limit 200 --plain

Then send one Telegram message and grab the exact 401 line from openclaw logs --follow --plain (it will say which subsystem/provider is returning 401).

Once we see which provider is 401’ing, the fix is straightforward (usually: put the correct API key in ~/.openclaw/.env for launchd, then openclaw gateway restart).

#

Those log lines are the key:

webchat disconnected code=4008 reason=connect failed → Control UI failed the Gateway “connect” step (almost always missing/incorrect Gateway token/password in the UI settings).
provider=moonshot model=kimi-k2.5 ... messageChannel=telegram → when you type in Telegram, the gateway is trying to call the Moonshot (Kimi) model provider. If that is where the “401” is coming from, it’s a Moonshot API key problem (not Telegram).

A) Fix the browser UI (`http://127.0.0.1:18789/chat?`)

Open the UI the supported way so it has the right auth:

openclaw dashboard

Then in the Control UI (Control → Overview → Gateway Access), paste your Gateway Token:

openclaw config get gateway.auth.token

#

After that, the WS connect should stop failing (no more code=4008).

B) Fix the “401 when I type in Telegram”

Since your runs are using provider=moonshot, the 401 is very likely Moonshot auth. Check:

openclaw models status

If Moonshot shows missing/invalid auth, set MOONSHOT_API_KEY in a place launchd can read (recommended):

cat >> ~/.openclaw/.env <<'EOF'
MOONSHOT_API_KEY=sk-...
EOF

#

openclaw gateway restart

If you’re not sure which 401 it is, paste the exact log line that contains 401 right after that provider=moonshot line (run openclaw logs --follow --plain, send one Telegram message, copy the 401 line).

#

That means you tried to start a second Gateway, but the LaunchAgent one is already running on 18789.

Do this instead:

openclaw gateway status
openclaw gateway restart

If you specifically want to stop it first:

openclaw gateway stop
openclaw gateway start

After the restart, re-test:

#

openclaw channels status --probe

If restart doesn’t pick up your new env/API key changes, paste:

openclaw gateway status --deep
and the last ~50 lines from /tmp/openclaw/openclaw-2026-02-17.log around the restart

(launchd env / multiple installs can make it look “restarted” but still run with old settings).

past grove Feb 17, 2026, 4:57 PM

#

I feel like I'm chasing my tail man... it didn't worked I ran the doctor, now it runs, when it opens the dashboard in safari 4008 if i use chrome manually it connects to the agent but returns 401 when i type something in chat

vital latchBOT Feb 17, 2026, 4:58 PM

#

You’re not crazy — you’re dealing with three separate auth layers and only one of them was Telegram:

Telegram bot token (now working)
Gateway/Control UI auth (Safari shows 4008 when it can’t “connect”)
Model provider auth (the 401 when you actually send a chat message)

1) Safari “4008 connect failed” (Control UI auth/localStorage mismatch)

Safari likely has no (or a stale) gateway token saved.

Do this and open the URL it prints (it usually includes the right token wiring):

openclaw dashboard

If Safari still shows 4008, clear the site data for 127.0.0.1 (Safari caches the gateway URL/token in storage), then open openclaw dashboard again.

#

2) Chrome connects, but typing returns 401 = model provider key is failing

Your own logs earlier showed runs like:
provider=moonshot model=kimi-k2.5 ...

So that 401 is almost certainly Moonshot (Kimi) API auth, not Telegram.

Run:

openclaw models status --plain
openclaw logs --follow --plain

Then send one message in chat and copy the exact line that contains 401 from the logs (please redact keys).

If it is Moonshot: make sure the gateway service (LaunchAgent) can see the key. The reliable place on macOS is:

#

~/.openclaw/.env containing:

MOONSHOT_API_KEY=... (for moonshot/... models)
(separately, KIMI_API_KEY=... is for kimi-coding/...)

After editing ~/.openclaw/.env, do:

openclaw gateway restart

Paste openclaw models status --plain output (redacting secrets) and the single 401 log line — that’ll pinpoint it immediately.

past grove Feb 17, 2026, 5:08 PM

#

fuck safari I'm using chrome from now on, safari won;t fucking work with deleted cache and updated token

% openclaw gateway stop

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Stopped LaunchAgent: gui/501/ai.openclaw.gateway
xxx@192 ~ % openclaw gateway start

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'll refactor your busywork like it owes me money.

Gateway service not loaded.
Start with: openclaw gateway install
Start with: openclaw gateway
Start with: launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.gateway.plist

~ % ~/.openclaw/.env
zsh: permission denied: /Users/xpld77/.openclaw/.env

bro... I don't know what I'm doing here help me man

vital latchBOT Feb 17, 2026, 5:11 PM

#

You’re close. Two separate things happened here:

You stopped the LaunchAgent, and now the Gateway service isn’t installed/loaded anymore.
You tried to run ~/.openclaw/.env as a command — that file is just a config file (you need to edit it).

1) Get the Gateway service running again (LaunchAgent)

Run:

openclaw gateway install --force --port 18789
openclaw gateway start
openclaw gateway status

(You can also just run it in the foreground with openclaw gateway run --port 18789, but the above restores the service.)

2) Fix the 401 when you send a chat message (this is model/provider auth)

#

Earlier your logs showed provider=moonshot model=kimi-k2.5 — so the 401 is very likely your Moonshot API key missing/invalid in the LaunchAgent environment.

Don’t paste the key in Discord. Set it locally like this:

mkdir -p ~/.openclaw
nano ~/.openclaw/.env

Add this line:

MOONSHOT_API_KEY=sk-...

Save/exit, then restart the service:

#

openclaw gateway restart

Verify:

openclaw models status --plain
openclaw logs --follow --plain

Then send one message in Chrome chat; if it still errors, copy only the line that contains 401 from the logs (redact anything secret) and I’ll tell you exactly which provider is failing.

One more note: the zsh: permission denied: ~/.openclaw/.env happened because zsh tried to execute the file. You always want nano ~/.openclaw/.env (edit) or cat ~/.openclaw/.env (view), not run it.

past grove Feb 17, 2026, 5:16 PM

#

it had this line and the one with the actual key... is the key wrong?? wtf I edited it and put the key in both lines I don't udnerstand what the output needs to be at each step you are telling me to do things but don;t give me the full picture and we both waste time and fucking tokens

vital latchBOT Feb 17, 2026, 5:17 PM

#

You’re right to call this out. Here’s the full picture and a deterministic checklist so we stop thrashing.

There are 3 unrelated auth layers that can each produce “401” symptoms:

Gateway/Control UI auth (browser ↔ gateway WS)
- Failure looks like: webchat disconnected code=4008 reason=connect failed
- Fix: paste gateway token into the Control UI settings (not Telegram token).
Telegram bot auth (gateway ↔ Telegram)
- Failure looks like: getMe failed (401/404) in telegram channel logs.
- You already fixed this (bot responds).
Model provider auth (gateway ↔ LLM provider like Moonshot/Kimi)
- Failure looks like: you send a message, run starts, then the provider returns 401.
- Your logs show provider=moonshot model=kimi-k2.5 → so this is the likely remaining 401.

#

Step-by-step (with “what good looks like”)

Step 1 — Make sure Chrome is actually authenticated to the Gateway

Open the UI, then connect using the gateway token:

openclaw config get gateway.auth.token

Good outcome: Chrome stays connected (no more 4008 connect failed spam in logs).

If Chrome is connected already, move on.

Step 2 — Confirm which model/provider you’re calling

Send one message, then look for a line like:

#

provider=moonshot model=kimi-k2.5 ✅ (this tells us exactly what key is needed)

You already saw this, so we know: Moonshot key path is the one to fix.

Step 3 — Validate the Moonshot key WITHOUT involving OpenClaw (fast, no guesswork)

On the gateway machine, run:

curl -sS https://api.moonshot.ai/v1/models \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" | head

Good outcome: you get JSON (a list of models), not 401.

If this is 401 → the Moonshot key itself is wrong (or you have the wrong provider key; Moonshot ≠ Kimi Coding).

#

If this is 200/JSON → key is valid, and the remaining issue is “gateway service isn’t loading the env var”.

Step 4 — Put the key in the one place launchd will reliably load: `~/.openclaw/.env`

Edit (don’t run) the file:

nano ~/.openclaw/.env

It should contain exactly one of these lines (no spaces around =):

For provider=moonshot (your case):
```
MOONSHOT_API_KEY=sk-...
```

#

Save, then restart the service:

openclaw gateway restart

Good outcome: sending a message no longer errors, and logs no longer show a provider 401.

About your “two lines” comment: if you had MOONSHOT_API_KEY=... twice, only the last one wins. To avoid confusion, delete the duplicate and keep one clean line.

One question so I can lock this down

When you “get 401 when you type something in chat”, can you paste the single log line that contains 401 (just that line), from right after you send a message?
It will mention the subsystem/provider (moonshot vs gateway ws vs discord), and then we can stop guessing completely.

past grove Feb 17, 2026, 5:26 PM

#

so I need one row = ... and the other row = the actual key man? be clear wtf

vital latchBOT Feb 17, 2026, 5:41 PM

#

No. You do not need “one row for = … and another row for the key”.

~/.openclaw/.env is just one variable per line, like:

MOONSHOT_API_KEY=sk-PASTE_THE_REAL_KEY_HERE

That’s it. One line. The part after the = is the key.

What you should do (exactly)

Edit the file:

nano ~/.openclaw/.env

Make it contain only one Moonshot line (no duplicates), like:

#

MOONSHOT_API_KEY=sk-xxxxxxxxxxxxxxxx

Rules:

no quotes needed
no spaces around =
don’t keep a placeholder line like MOONSHOT_API_KEY=...
if you have it twice, delete one (the last one would “win”, but duplicates cause confusion)

Restart the gateway service:

openclaw gateway restart

Which key name do you need?

Your logs showed provider=moonshot model=kimi-k2.5, so you need MOONSHOT_API_KEY.

#

(KIMI_API_KEY is only for the separate kimi-coding/... provider.)

If after that you still get 401, paste the single log line that contains 401 (redact secrets). That line will tell us which auth is still failing.

past grove Feb 20, 2026, 1:29 AM

#

i switched to openai instead of moonshot and now I get this error 400 Unsupported value: 'low' is not supported with the 'gpt-5.2-chat-latest' model. Supported values are: 'medium'.

vital latchBOT Feb 20, 2026, 1:30 AM

#

That 400 is coming from OpenClaw sending a thinking/reasoning level of low to OpenAI, but gpt-5.2-chat-latest only accepts medium (per the error).

Fix options:

Quick (per-session): send this as a message (just that line)

/think:medium

(or /think:off to disable thinking entirely)

Permanent (config): set the global default to medium (or off):

agents: {
  defaults: {
    thinkingDefault: "medium", // or "off"
  }

#

Then restart the gateway.

Docs: https://docs.openclaw.ai/tools/thinking

If you tell me your openclaw --version + where you set thinking (config vs you previously sent /think:low), I can point to the exact place to change.

past grove Feb 20, 2026, 1:32 AM

#

ok, chat from gateway works, chat from tg bot returns 401

#

xpld77@192 ~ % openclaw channels status --probe
^[[B^[[A
🦞 OpenClaw 2026.2.15 (3fe22ea) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

│
◇
Gateway reachable.

Telegram default: enabled, configured, running, in:2d ago, mode:polling, bot:@xxxx, token:config, works

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

vital latchBOT Feb 20, 2026, 1:34 AM

#

If Gateway web chat works but Telegram replies 401, that’s almost always Telegram Bot API saying “your bot token is invalid” (it fails the getMe probe).

What to do:

Confirm it’s really a token/auth failure

openclaw channels status --probe

Look at the Telegram line — if it shows getMe ... 401 Unauthorized, it’s the bot token.

Fix the token

Make sure you set channels.telegram.botToken (BotFather token), not some other key.
If you regenerated/revoked the token in BotFather, update it in your config (or re-add the channel), then:

openclaw gateway restart

#

Rule out “edited the wrong config” (very common with daemon installs)

openclaw gateway status

Check whether Config (cli) and Config (service) point to the same file.

If you paste the redacted output of openclaw channels status --probe + openclaw gateway status (and your openclaw --version), I can tell you exactly which side is mismatched.
Please don’t paste the Telegram token in here.

#

Your openclaw channels status --probe output says Telegram is “works” (so the bot token/auth is fine now).

So if you’re still seeing a 401 when you message the Telegram bot, it’s almost certainly not Telegram anymore — it’s usually a model/provider 401 (e.g. OpenAI invalid/missing key) or you’re messaging a different bot than the one this gateway is polling.

Fast way to pinpoint which:

Tail logs, then send a test message to the TG bot:

openclaw logs --follow

Send “ping” in Telegram and watch what the gateway logs say around the 401 (it should mention who returned 401: openai, discord, etc.).

Also run a live model auth probe:

openclaw models status --probe

If OpenAI auth is the issue, you’ll see it here (401/invalid key).

#

If you paste just the log lines around the 401 (redact tokens) I can tell you exactly what’s failing and what to change.

past grove Feb 20, 2026, 1:38 AM

#

in logs --follow I can't see any log related to my ping in tg

and in models status I get this
🦞 OpenClaw 2026.2.15 (3fe22ea) — I read logs so you can keep pretending you don't have to.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/gpt-5.2-chat-latest
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : Kimi -> moonshot/kimi-k2.5, GPT -> openai/gpt-5.1-codex
Configured models (3): moonshot/kimi-k2.5, openai/gpt-5.1-codex, openai/gpt-5.2-chat-latest

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

moonshot effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | moonshot:default=xxxx | env=sk-xxxx| source=env: MOONSHOT_API_KEY
openai effective=env:sxxx | env=sk-proj-.xxx | source=env: OPENAI_API_KEY

OAuth/token status

none

Auth probes
┌────────────────────────────┬────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├────────────────────────────┼────────────────────────────┼────────────┤
│ moonshot/kimi-k2.5 │ moonshot:default (api_key) │ ok · 2.3s │
│ openai/gpt-5.2-chat-latest │ env (api_key) │ ok · 2.8s │
└────────────────────────────┴────────────────────────────

#

💩

#

I can see what I'm writing in telegram in the gateway and the 401 response, but if i refresh the gateway and type from there I get response

vital latchBOT Feb 20, 2026, 1:46 AM

#

Your OpenAI side looks fine — models status --probe shows openai … ok, so the “401” you were seeing earlier is almost certainly not OpenAI anymore.

The bigger clue is this line from channels status --probe:

Telegram … running … **in:2d ago** … works

That usually means the Gateway hasn’t actually received a Telegram inbound update recently. That matches “I don’t see anything in logs when I ping”.

1) First: are you testing in a DM or a group?

If it’s a group: Telegram often won’t even deliver normal messages to the bot unless:

BotFather privacy mode is off (/setprivacy), or the bot is a group admin
and OpenClaw group behavior often defaults to mention-required

So test with either:

DM the bot: send /start then ping
or in the group: @YourBot ping (explicit mention) or /ping

#

(And if you changed BotFather privacy: remove + re-add the bot to the group so Telegram applies it — Telegram is annoying like that.)

2) Check if OpenClaw is blocking your DM due to pairing/allowlist

Telegram DMs default to dmPolicy: pairing.

Run:

openclaw pairing list telegram

If you see a pending pairing request: approve it in the Control UI (or switch dmPolicy to allowlist/open).

3) Prove whether the Gateway is receiving anything from Telegram

Do this: run the probe, send a Telegram message, run it again and see if in: updates:

#

openclaw channels status --probe
# send "ping" in Telegram
openclaw channels status --probe

If in: does not change, you’re almost certainly messaging a different bot than the one the gateway is polling (check the bot:@xxxx shown in status and DM that exact username), or Telegram isn’t delivering updates (privacy/group/admin situation).

If you tell me DM vs group + what happens when you send @bot ping (or DM /start), I can point you to the exact config knob (dmPolicy, allowFrom, groups.*.requireMention, BotFather privacy).

#

That “401” is the key — but right now we don’t know who is returning it.

Given:

openclaw channels status --probe says Telegram works
openclaw models status --probe says OpenAI ok
yet Telegram → you see a 401 “response” in the Gateway UI, while WebChat works

…this usually means the 401 is coming from some downstream call (often OpenAI, sometimes a different channel/tool), and it only happens on the Telegram-routed session/agent.

Do this (it will tell us exactly what’s 401’ing)

Grab the channel-specific log lines:

openclaw channels logs --channel telegram --lines 300

Paste the part that contains 401 (redact tokens).

#

Also paste the exact text of the “401 response” you see in the Gateway UI (copy/paste is fine).

Two common fixes depending on what the logs say

If logs show OpenAI HTTP 401 → the Gateway process doesn’t actually have the OpenAI key in its env/config (macOS services don’t inherit shell env). Fix by putting it in ~/.openclaw/openclaw.json under:
```
env: { OPENAI_API_KEY: "..." }
```
then openclaw gateway restart.
If logs show Telegram API 401 (rare if probe says works) → you likely have a token mismatch between accounts/config paths; we’ll confirm via the log line and then re-add/update the Telegram account.

Send the channels logs snippet and we can nail it in one step.

past grove Feb 20, 2026, 1:54 AM

#

I use it in dm, the in:just now, changed, I can see everythign I type to my tg bot in the gateway, I just get 401 invalid auth in tg as a response, the gateway status changes to 401 invalid auth and I get an empty response in the gateway chat. if I refresh I can get a response in the gatway chat from openai

this is wierd
openclaw channels logs --channel telegram --lines 300

🦞 OpenClaw 2026.2.15 (3fe22ea) — I read logs so you can keep pretending you don't have to.

Log file: /tmp/openclaw/openclaw-2026-02-19.log
Channel: telegram
No matching log lines.

vital latchBOT Feb 20, 2026, 2:05 AM

#

If you’re seeing your DM arrive (the in: timestamp updates) but the bot “replies” with 401 invalid auth, then the important question is: 401 from what.

Also: openclaw channels logs --channel telegram returning nothing is (unfortunately) explainable — a lot of Telegram errors are logged under subsystems like telegram/api, not gateway/channels/telegram, so that filter can miss everything.

1) Get the real 401 source from the raw gateway log tail

Reproduce once (send “ping” in Telegram), then run:

openclaw logs --limit 500 | grep -Ei "telegram|openai|401|unauthor|auth"

(or if you prefer directly from the file it printed:)

tail -n 500 /tmp/openclaw/openclaw-*.log | grep -Ei "telegram|openai|401|unauthor|auth"

#

Paste the matching lines (redact tokens). That will tell us whether it’s:

Telegram Bot API 401 (token / proxy / account mismatch), or
OpenAI 401 (key not available to the daemon), or
something else entirely.

2) Quick sanity check: is Telegram routed to a different agent?

If Telegram is bound to a non-main agent, that agent can have different auth.

openclaw agents list
openclaw config get bindings

If you see Telegram bound to another agent id, run:

openclaw models status --probe --agent <thatAgentId>

#

3) One very common “it works in UI but not in bot” cause on macOS

Your models status shows OpenAI auth comes from env (source=env: OPENAI_API_KEY). If the Gateway is running as a LaunchAgent/service, it may not have the same env as your shell.

Fix (most robust): put the key into config so the daemon always has it:

env: { OPENAI_API_KEY: "sk-..." }

then:

openclaw gateway restart

But first let’s confirm via the log snippet in step (1) which component is actually throwing the 401.

#

That env: { … } snippet is config file syntax, not something you can paste into zsh — that’s why you got zsh: parse error near '}'.

Set the OpenAI key in OpenClaw config (so the daemon sees it too)

On macOS especially, the Gateway service often doesn’t inherit your shell env, so Telegram-inbound runs in the daemon and can’t auth, while your “fresh” web UI session can look like it works.

Run:

openclaw config set env.OPENAI_API_KEY "sk-REDACTED"
openclaw gateway restart

(That writes it into ~/.openclaw/openclaw.json under env.)

Then re-test Telegram DM.

Verify the running gateway/service is using the same config

#

openclaw gateway status

If Config (cli) and Config (service) differ, you’re editing one file while the daemon uses another (classic “works here, not there”).

About “no matching log lines”

openclaw channels logs --channel telegram only matches subsystems like gateway/channels/telegram and Telegram often logs under telegram/api, so it can show nothing even when Telegram is active.

If it still fails after setting the key, enable Telegram HTTP diagnostics and we’ll finally see the real 401 source:

openclaw config set diagnostics.flags '["telegram.http"]' --json
openclaw gateway restart

Then reproduce once and run:

#

rg -i "telegram http error|401|unauthor" /tmp/openclaw/openclaw-*.log | tail -n 50

Also: can you paste the exact text of the “401 invalid auth” message you receive in Telegram? (Just the text, no tokens.) The wording matters — “Invalid Authentication” is Discord-style, while Telegram is usually “401: Unauthorized”.

vital latchBOT Feb 20, 2026, 2:45 AM

#

Yep — openclaw config set env.OPENAI_API_KEY ... worked. The only problem now is: your running Gateway process (pid 50003) hasn’t restarted yet, so it’s still using the old env/config.

Also, openclaw gateway status saying “service not loaded” just means you don’t have the launchd service installed (totally fine). But you do have a Gateway already running.

Restart the running Gateway (so it picks up the new key)

Run:

openclaw gateway stop
openclaw gateway

If openclaw gateway stop refuses because it thinks there’s no service, then just kill the PID it told you about:

#

kill 50003
openclaw gateway

After it comes back up, test your Telegram DM again — the “401 invalid auth” response should be gone if it was coming from the Gateway not having the OpenAI key.

If it still happens after a clean restart, we’ll turn on targeted Telegram HTTP diagnostics (diagnostics.flags: ["telegram.http"]) and you’ll finally get a log line that identifies exactly which request is 401’ing.

vital latchBOT Feb 20, 2026, 3:13 AM

#

It’s not stuck — it’s running in the foreground and your terminal is now just showing the live gateway logs.

These lines are the “healthy” signal:

[gateway] listening on ws://127.0.0.1:18789 (PID 50259)
[telegram] [default] starting provider (@xxxx)
[ws] webchat connected …

The dsada at the bottom is just you typing into the terminal; openclaw gateway doesn’t give you a prompt while it’s running.

What to do next

Open a second terminal (leave this one running), then DM your Telegram bot again and see if the 401 is gone.
If Telegram still replies 401 invalid auth, we need to see which API call is 401’ing. Turn on targeted Telegram diagnostics and restart the gateway:

In a new terminal:

#

openclaw config set diagnostics.flags '["telegram.http"]' --json

Then in the gateway terminal: Ctrl+C to stop it, and start again:

openclaw gateway

Reproduce once (send a DM), then check:

rg -i "telegram http error|telegram .* failed|401|unauthor" /tmp/openclaw/openclaw-$(date +%F).log | tail -n 80

Paste those matching lines (tokens redacted) and we’ll know exactly what’s failing.

Note: openclaw gateway status complaining about “service not loaded” is expected because you’re not using the launchd service; you’re running it manually.

#HTTP 401: Invalid Authentication

1) http://127.0.0.1:18789/chat? → 401 in the browser

2) Telegram chat message → bot “responds but still 401”

A) Fix the browser UI (http://127.0.0.1:18789/chat?)

B) Fix the “401 when I type in Telegram”

1) Safari “4008 connect failed” (Control UI auth/localStorage mismatch)

2) Chrome connects, but typing returns 401 = model provider key is failing

1) Get the Gateway service running again (LaunchAgent)

2) Fix the 401 when you send a chat message (this is model/provider auth)

Step-by-step (with “what good looks like”)

Step 1 — Make sure Chrome is actually authenticated to the Gateway

Step 2 — Confirm which model/provider you’re calling

Step 3 — Validate the Moonshot key WITHOUT involving OpenClaw (fast, no guesswork)

Step 4 — Put the key in the one place launchd will reliably load: ~/.openclaw/.env

One question so I can lock this down

What you should do (exactly)

Which key name do you need?

1) First: are you testing in a DM or a group?

2) Check if OpenClaw is blocking your DM due to pairing/allowlist

3) Prove whether the Gateway is receiving anything from Telegram

Do this (it will tell us exactly what’s 401’ing)

Two common fixes depending on what the logs say

1) Get the real 401 source from the raw gateway log tail

2) Quick sanity check: is Telegram routed to a different agent?

3) One very common “it works in UI but not in bot” cause on macOS

Set the OpenAI key in OpenClaw config (so the daemon sees it too)

Verify the running gateway/service is using the same config

About “no matching log lines”

Restart the running Gateway (so it picks up the new key)

What to do next

1) `http://127.0.0.1:18789/chat?` → 401 in the browser

A) Fix the browser UI (`http://127.0.0.1:18789/chat?`)

Step 4 — Put the key in the one place launchd will reliably load: `~/.openclaw/.env`