Can’t seem to get a response after the setup of openclaw

[cunning hollow]

I’m not very familiar with any sort of programming or coding and it seems like this should be straightforward. I’ve used multiple API keys and different UIs discord and telegram as well as hatching in the control panel. And I cannot get the bot to respond back. And in the control panel it looks like it’s responding but not showing any words. Any ideas?

[lone knoll]

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

[dull tusk]

If the Control UI shows a “response” happening but you never see any text (and Discord/Telegram also don’t get replies), it’s usually one of these:

1. The Gateway can’t actually talk to a model (API key/token not loaded, wrong agent, rate limit, “model not allowed”, etc.)
2. Your chat messages are being blocked before reply (allowlist / pairing / mention-required / guild not enabled)
3. Your Gateway service is running with a different config/env than the one you edited (very common when running as a background service)

The fastest way to diagnose (copy/paste)

Run these on the machine where the Gateway is running and paste the output here (it redacts secrets):

openclaw --version
openclaw status --all

If you can add one more, this is super helpful for Discord/Telegram specifically:

openclaw channels status --probe

Two quick Discord gotchas to check immediately

• In the Discord Developer Portal for your bot: enable “Message Content Intent” (without it, the bot can connect but won’t properly read/respond in many servers).
  Docs: https://docs.openclaw.ai/channels/discord
• In guild channels, OpenClaw often requires a mention and/or the guild may be blocked by default depending on groupPolicy. So try: @YourBot hello in the channel.

If you set API keys in your terminal but run the Gateway as a service

On macOS/Linux services often don’t inherit your shell env, so keys “look set” but the running Gateway never sees them. Fix is usually to put keys in:

• ~/.openclaw/.env (recommended), then restart the gateway

FAQ section: https://docs.openclaw.ai/help/faq#i-started-the-gateway-via-the-service-and-my-env-vars-disappeared-what-now

Post openclaw status --all and I can tell you which of the above is happening from the report/log tail.

[cunning hollow]

im also getting this first "Health check failed: gateway closed (1006 abnormal closure (no close frame)): no close reason"

[dull tusk]

That error is a WebSocket disconnect between the CLI/UI and the Gateway:

Health check failed: gateway closed (1006 abnormal closure …)

In practice 1006 usually means the Gateway process crashed/restarted, or something in-between (VPN/proxy/firewall/reverse-proxy) is dropping WebSockets, or your CLI/UI is pointed at the wrong gateway URL/config.

1) Run these 3 commands on the machine where OpenClaw Gateway runs

…and paste the output here (they’re safe to share; secrets get redacted in --all):

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

Those will immediately tell us:

• is the service actually running?

• is the RPC probe working?
• is there a Config (cli) vs Config (service) mismatch?
• what URL it’s probing (wrong host/port is common)

2) Then grab the log tail (this usually contains the real reason)

openclaw logs --limit 200

3) Quick “easy fixes” while we wait for the output

• Try a restart (often fixes a crashed gateway):

  openclaw gateway restart
  

• If you’re accessing the dashboard from another device/network (not 127.0.0.1), avoid putting it behind a random HTTP proxy that doesn’t support WebSockets. If you are using a proxy/Cloudflare/etc, tell me what you’re using (that’s a common 1006 cause).

Once you paste openclaw gateway status + the log tail, I can tell you exactly which bucket this is (crash vs wrong target vs auth/proxy).

[cunning hollow]

this is what i get after the logtail 23:03:00 error Health check failed: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/maddenctelles/.openclaw/openclaw.json
Bind: loopback
23:03:00 error Missing Control UI assets. Build them with pnpm ui:build (auto-installs UI deps).

[dull tusk]

That log actually contains two separate clues:

1) “Missing Control UI assets” = your dashboard/web control panel can’t render

So the UI can look like it’s “doing something” but you won’t see the actual text because the frontend files (dist/control-ui) aren’t there.

Fix (if you installed from a git/source checkout):

cd <your-openclaw-repo-folder>   # the folder that has package.json + pnpm-lock.yaml
pnpm install
pnpm ui:build
pnpm build
openclaw gateway restart

Docs: https://docs.openclaw.ai/web/control-ui#building-the-ui

2) The real blocker: “gateway closed (1006)” = the Gateway isn’t staying up

On loopback (ws://127.0.0.1:18789), 1006 almost always means the gateway process crashed or restarted, so nothing (Discord/Telegram/UI) can reply reliably.

Next, please paste this output (it’s the quickest way to see why it’s dying and whether you have a config mismatch):

openclaw gateway status
openclaw logs --limit 200

After you run the pnpm ui:build steps + restart, re-try:

openclaw health --verbose

and tell me if it still shows the 1006.

[cunning hollow]

cant run pnpm command not found

[dull tusk]

pnpm not found is totally normal — but also: you only need pnpm ui:build if you’re running OpenClaw from a git/source checkout. If you installed via npm/installer, the Control UI is usually already bundled, and “Missing Control UI assets” points to an incomplete/older install.

First: tell me how you installed OpenClaw

Was it:

1. the installer script (curl ... install.sh | bash), or
2. npm install -g openclaw, or
3. git clone ... (running from source)

If you’re not sure, paste:

openclaw --version
which openclaw

---

If you DO have a source checkout (git clone)

Install pnpm via corepack (recommended on Node 22+):

node -v
corepack enable
corepack prepare pnpm@latest --activate
pnpm -v

Then go into your repo folder and build the UI:

cd <your-openclaw-repo-folder>
pnpm install
pnpm ui:build
pnpm build

openclaw gateway restart

Docs: https://docs.openclaw.ai/web/control-ui#building-the-ui

---

If you do NOT have a source checkout (most beginners)

Don’t worry about pnpm yet. Instead, reinstall/upgrade OpenClaw so the UI assets are present:

npm install -g openclaw@latest
openclaw doctor
openclaw gateway restart

---

Also: the 1006 “gateway closed” still needs the crash reason

After you do the above, paste this:

openclaw gateway status
openclaw logs --limit 200

openclaw gateway status usually shows a “Last gateway error:” line that immediately explains the 1006.

[cunning hollow]

I Installed openclaw through #1 option

[dull tusk]

Yep — if you installed via the installer script, you don’t need pnpm. So pnpm: command not found is fine.

What’s not fine is this combo:

• gateway closed (1006 …) = the Gateway isn’t staying connected / is crashing / is being restarted
• Missing Control UI assets = your install the Gateway/CLI is using doesn’t have the dashboard files where it expects them (often a service/CLI mismatch)

Do this on the machine where the Gateway runs

Paste the output back here:

openclaw --version
which openclaw
openclaw gateway status
openclaw doctor

Then restart:

openclaw gateway restart
openclaw health --verbose

If it still says “Missing Control UI assets”

Run a clean reinstall of the bundled build (installer-style / npm global) and then Doctor again (this often fixes “service points at an old install path”):

npm install -g openclaw@latest
openclaw doctor
openclaw gateway restart

Docs reference for the UI build note (just so you see where that message comes from): https://docs.openclaw.ai/web/control-ui#building-the-ui

Once you paste openclaw gateway status (it usually includes a “Last gateway error” line), I can tell you exactly what’s causing the 1006.

[cunning hollow]

2026.2.6-3, /home/maddenctelles/.npm-global/bin/openclaw,
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-08.log
Command: /usr/bin/node /home/maddenctelles/.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 2490, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

[dull tusk]

Nice — that openclaw gateway status looks healthy now (Runtime running + RPC probe ok). So the 1006 you saw earlier is likely from the Control UI connection, not “the gateway is dead”.

Two important takeaways from what you pasted:

1) Your Gateway is loopback-only

It says:

Bind: loopback
Probe note: Loopback-only gateway; only local clients can connect.

That means the dashboard at http://127.0.0.1:18789/ only works on the same machine that’s running OpenClaw.

• If OpenClaw is on a VPS / another computer: you need an SSH tunnel (quickest) and then open the dashboard locally:

  ssh -N -L 18789:127.0.0.1:18789 <user>@<your-server>
  

  Then on your laptop: http://127.0.0.1:18789/

(Or use Tailscale Serve later, but tunnel is easiest to get unstuck.)

2) That “Missing Control UI assets” error shouldn’t require pnpm for you

Since you installed via the installer (#1), you should already have UI assets bundled. Let’s verify if they’re actually present:

ls -la /home/maddenctelles/.npm-global/lib/node_modules/openclaw/dist/control-ui/index.html

• If that file is missing, fix is:

  npm install -g openclaw@latest
  openclaw doctor
  openclaw gateway restart
  

3) To fix “bot doesn’t respond in Discord/Telegram”, we need channel + model status

Please paste these two outputs:

openclaw models status
openclaw channels status --probe

Those will usually immediately show the real cause (no model auth, Discord intent missing, Telegram allowFrom/pairing, guild mention-required, allowlists blocking, etc.).

[cunning hollow]

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : moonshot/kimi-k2.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : Kimi -> moonshot/kimi-k2.5
Configured models (1): moonshot/kimi-k2.5

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=nvapi-gm...7yMfMrFy

OAuth/token status

• none, Gateway reachable.
• Telegram default: enabled, configured, running, mode:polling, bot:@GoogleMadden_Bot, token:config, works

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

[dull tusk]

Good news: your openclaw models status says two key things:

• The Gateway is reachable and you do have a model configured (moonshot/kimi-k2.5) with a stored API key.
• Telegram is connected and the token “works” (so the bot is actually running).

So if you still get no replies, it’s usually access control / mention-gating / pairing, not “the bot is offline”.

1) Telegram: check DM pairing (most common)

Telegram DMs default to dmPolicy: "pairing" — your first message won’t be processed until you approve the code.

Run:

openclaw pairing list telegram

• If it shows a code, approve it:

  openclaw pairing approve telegram <CODE>

Then DM the bot again.

Docs: https://docs.openclaw.ai/start/pairing

2) Discord: we need to see if Discord is actually enabled + allowed

Your paste didn’t include anything about Discord. Please run and paste:

openclaw channels status --probe

That output usually flags the exact reason Discord won’t reply (missing Message Content Intent, guild/channel blocked by allowlist, require-mention behavior, missing token, etc.).

3) Sanity check: does the model actually answer?

If the model key is invalid / provider errors, you’ll also see “no reply” behavior. This will probe providers:

openclaw status --deep

If you paste the channels status --probe + status --deep results, I can tell you exactly what’s blocking replies.

[cunning hollow]

It did work and we approved the code. Now im getting a "HTTP 401: Invalid Authentication code

[dull tusk]

That 401 “Invalid Authentication code” is not the Telegram pairing code — pairing is done once and then you’re allowed to talk. A 401 like that is almost always your LLM provider key being rejected (or less commonly the Telegram bot token being rejected).

From what you pasted earlier, your default model is:

• moonshot/kimi-k2.5

…and the stored key preview looked like nvapi-gm... which doesn’t look like a Moonshot API key (Moonshot keys are typically sk-...). So my #1 suspicion is: wrong key for the provider → Moonshot API returns 401.

Confirm where the 401 is coming from

Please run and paste:

openclaw logs --limit 200
openclaw models status --probe

• If the log mentions api.moonshot.ai (or moonshot) near the 401 → it’s the Moonshot/Kimi API key.

• If it mentions Telegram getMe / Unauthorized → it’s the Telegram bot token.

If it’s Moonshot (most likely)

Fix = enter a real Moonshot Open Platform API key for provider moonshot:

• quickest interactive way:

  openclaw models auth add
  

  (then pick moonshot and paste the correct API key)

OR rerun onboarding just for that auth choice:

openclaw onboard --auth-choice moonshot-api-key

Then restart:

openclaw gateway restart

Provider docs (important note: Moonshot vs Kimi Coding keys are not interchangeable):
https://docs.openclaw.ai/providers/moonshot

If it’s Telegram instead

Re-check the bot token in your config (channels.telegram.botToken) and restart the gateway. Telegram should show “Unauthorized” if the token is wrong.

Paste the models status --probe + the log tail and I’ll tell you exactly which one it is.

[cunning hollow]

runId=5a958c8a-fb5d-42d3-a8e2-9ff5a9046ce7 sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 provider=moonshot model=kimi-k2.5 thinking=off messageChannel=telegram
23:51:11 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
23:51:11 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 totalActive=1
23:51:11 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=5a958c8a-fb5d-42d3-a8e2-9ff5a9046ce7 sessionId=9f20956e-6968-47cd-8c09-899e621f7e63
23:51:11 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=5a958c8a-fb5d-42d3-a8e2-9ff5a9046ce7
23:51:12 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=5a958c8a-fb5d-42d3-a8e2-9ff5a9046ce7
23:51:12 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=5a958c8a-fb5d-42d3-a8e2-9ff5a9046ce7 sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 durationMs=1266
23:51:12 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
23:51:12 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 totalActive=0
23:51:12 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=5a958c8a-fb5d-42d3-a8e2-9ff5a9046ce7 sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 durationMs=1685 aborted=false
23:51:12 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=1699 active=0 queued=0
23:51:12 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=1708 active=0 queued=0
23:54:23 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered

[dull tusk]

That log snippet confirms the 401 is coming from the model provider, not Telegram:

• provider=moonshot model=kimi-k2.5 … messageChannel=telegram

When Moonshot returns HTTP 401 “Invalid Authentication code”, it means the Moonshot API key is wrong/expired/revoked (or you pasted a key for a different service). Since you have no fallbacks configured, the bot will just fail and you’ll see “no reply”.

1) Prove it in one command (and show the exact error)

Run:

openclaw models status --probe --probe-provider moonshot

You should see the 401 right there.

2) Fix: re-enter the Moonshot API key (most common: wrong key format)

Get a Moonshot Open Platform API key (usually looks like sk-...). Then on the gateway machine run:

openclaw models auth add

Pick moonshot, paste the key carefully (no extra spaces/newlines), then:

openclaw gateway restart
openclaw models status --probe --probe-provider moonshot

Moonshot provider doc (important note: Moonshot vs “Kimi Coding” keys are not interchangeable):
https://docs.openclaw.ai/providers/moonshot

3) Optional but recommended: add a fallback model

So you still get replies even if Moonshot auth breaks again:

openclaw models fallbacks add <some-other-model>

(If you tell me what other provider you have a working key for—OpenAI/Anthropic/etc—I can suggest the exact command.)

If you paste the output of openclaw models status --probe --probe-provider moonshot, I can confirm it’s 100% the Moonshot key and not anything else.

[cunning hollow]

This is what I got after the first command ◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : moonshot/kimi-k2.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : Kimi -> moonshot/kimi-k2.5
Configured models (1): moonshot/kimi-k2.5

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=nvapi-gm...7yMfMrFy

OAuth/token status

• none

Auth probes
┌────────────────────┬────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├────────────────────┼────────────────────────────┼────────────┤
│ moonshot/kimi-k2.5 │ moonshot:default (api_key) │ ok · 2s │
└────────────────────┴────────────────────────────┴────────────┘

[dull tusk]

The Moonshot/Kimi side looks fine now — your models status --probe shows:

• moonshot/kimi-k2.5 … Status: ok

So if you’re still seeing HTTP 401: Invalid Authentication code, it’s almost certainly not the Moonshot API key anymore. We need to identify which component is throwing the 401 (Telegram vs Control UI vs something else).

1) Please paste the actual 401 line from logs

Run this on the gateway machine right after reproducing the error:

openclaw logs --limit 400 | grep -nE "401|Invalid Authentication|Unauthorized"

That will show the subsystem (telegram/moonshot/control-ui/etc) and the exact request that failed.

2) Also paste channel probe (this catches Telegram/Discord auth issues)

openclaw channels status --probe

3) Quick question (important)

Where do you see the “HTTP 401” message?

• in Telegram chat as a bot reply?
• in the Control UI / dashboard in your browser?
• in the terminal after running a command?

Answer that + paste the grep output and we’ll know exactly what to fix.

[cunning hollow]

Yes in Telegram chat as a bot reply

[dull tusk]

If you’re seeing HTTP 401: Invalid Authentication code as an actual Telegram bot reply, that means OpenClaw is hitting a 401 somewhere upstream (usually the model API) and then echoing the error back into chat.

Even though openclaw models status --probe shows Moonshot = ok, the Gateway process can still be using an old in-memory credential until it’s restarted.

Do this first (reload creds)

On the machine running the Gateway:

openclaw gateway restart

Then send a fresh “hi” to the bot in Telegram.

If you still get the 401: capture the exact source

Run this, leave it running, then send one Telegram message and copy/paste the lines that mention 401:

openclaw logs --follow

(You can stop it with Ctrl+C after you see the error.)

Also paste this output:

openclaw channels status --probe

What I’m looking for in the log is whether the 401 is coming from:

• api.moonshot.ai / Moonshot (model auth), or
• api.telegram.org (Telegram bot token), or
• something else entirely.

Once you paste the 401 log lines, I can tell you exactly which key/setting is wrong and what command fixes it.

[cunning hollow]

This is showing up after I send a telegram message Im going to send this in two chats since I reached the limit in one 00:08:21 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
00:08:21 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=2 queueSize=0
00:08:21 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
00:08:21 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=2 queueSize=0
00:08:21 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=02ca6114-2bf4-455b-9bc8-858eb329ca6a sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 provider=moonshot model=kimi-k2.5 thinking=off messageChannel=telegram
00:08:21 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
00:08:21 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=9f20956e-6968-47cd-

8c09-899e621f7e63 totalActive=1
00:08:21 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=02ca6114-2bf4-455b-9bc8-858eb329ca6a sessionId=9f20956e-6968-47cd-8c09-899e621f7e63
00:08:21 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=02ca6114-2bf4-455b-9bc8-858eb329ca6a
00:08:22 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=02ca6114-2bf4-455b-9bc8-858eb329ca6a
00:08:22 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=02ca6114-2bf4-455b-9bc8-858eb329ca6a sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 durationMs=524
00:08:22 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
00:08:22 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 totalActive=0
00:08:22 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=02ca6114-2bf4-455b-9bc8-858eb329ca6a sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 durationMs=675 aborted=false
00:08:22 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=683 active=0 queued=0
00:08:22 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=689 active=0 queued=0

[dull tusk]

Those lines you pasted are just the “run started / run finished” debug — the actual HTTP 401 line isn’t in that snippet, so we still don’t know if the 401 is coming from Telegram or from Moonshot.

Let’s pull the exact 401 from the file log (this is the fastest way):

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "$LOG"
grep -nE "HTTP 401|Invalid Authentication|Unauthorized|moonshot|telegram" "$LOG" | tail -80

Then paste the output (especially the lines that include the 401).

Also paste this (it will confirm whether Telegram auth is still OK):

openclaw channels status --probe

How we’ll interpret it:

• If the 401 line mentions api.telegram.org / grammY / telegram → your Telegram bot token is wrong/changed.
• If it mentions api.moonshot.ai / moonshot → it’s the Moonshot key during actual runs (even if models status --probe says ok).

Once you paste the grep output, I’ll tell you the exact fix command.

[cunning hollow]

Its hard to find. I believe this is an output from my telgram message. Not certain 273:{"0":"{"subsystem":"agent/embedded"}","1":"embedded run start: runId=164689af-dbd2-49cf-8a60-adcde2ca9f8e sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 provider=moonshot model=kimi-k2.5 thinking=off messageChannel=telegram","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-02-09T00:07:30.679Z","logLevelId":2,"logLevelName":"DEBUG","path":{"fullFilePath":"file:///home/maddenctelles/.npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:777:14","fileName":"subsystem-CAq3uyo7.js","fileNameWithLine":"subsystem-CAq3uyo7.js:777","fileColumn":"14","fileLine":"777","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:777","method":"logToFile"}},"time":"2026-02-09T00:07:30.680Z"}

[dull tusk]

That line you found is just a DEBUG “run start” line — it doesn’t contain the failure. The 401 will be an ERROR log line somewhere near the same timestamp.

To make this easy, do a “clean capture”:

1) Get the exact log file + current time

Run on the gateway machine:

date -Is
LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "$LOG"

2) Immediately after you reproduce the 401 in Telegram, run these searches

grep -nE "HTTP 401|Invalid Authentication|Unauthorized" "$LOG" | tail -50

grep -n '"logLevelName":"ERROR"' "$LOG" | tail -50

3) Also paste channel probe (rules out Telegram token issues fast)

openclaw channels status --probe

Once you paste the matched 401/ERROR lines, we’ll know if the 401 is coming from:

• Telegram (api.telegram.org / “Unauthorized”) → bot token issue, or
• Moonshot (api.moonshot.ai) → model auth issue (even if the probe sometimes says ok), or
• something else.

If you want, also copy/paste the exact Telegram message text you see (verbatim) — sometimes it includes which service returned the 401.

[cunning hollow]

102:{"0":"Invalid config at /home/maddenctelles/.openclaw/openclaw.json:\n- plugins.entries.telegram: plugin not found: telegram\n- plugins.slots.memory: plugin not found: memory-core","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-02-08T23:41:02.680Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/maddenctelles/.npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:638:68","fileName":"subsystem-CAq3uyo7.js","fileNameWithLine":"subsystem-CAq3uyo7.js:638","fileColumn":"68","fileLine":"638","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:638","method":"console.error"}},"time":"2026-02-08T23:41:02.690Z"}

[dull tusk]

That ERROR line is a big clue:

• plugins.entries.telegram: plugin not found: telegram
• plugins.slots.memory: plugin not found: memory-core

Meaning: your ~/.openclaw/openclaw.json contains plugin config that references plugins OpenClaw can’t discover. OpenClaw runs in “strict config” mode now, so this can cause all kinds of weird behavior (including replies failing / config not applying).

Fix (safe, recommended)

Run this on the gateway machine:

openclaw doctor --repair
openclaw gateway restart

Notes:

• Doctor will create a backup: ~/.openclaw/openclaw.json.bak

• --repair (aka --fix) drops unknown/invalid config keys and lists what it removed.

Then test in Telegram

1. Send /status to the bot (should reply even if the model is broken).
2. Send a normal “hi”.

If you still see the 401 in Telegram after the restart

Paste the 401 line from the log:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
grep -nE "HTTP 401|Invalid Authentication|Unauthorized" "$LOG" | tail -50

But do the doctor --repair + restart first — that plugin misconfig needs to be cleaned up regardless.

[cunning hollow]

Still getting the HTTP 401: Invalid Authentication in the telegram app

That line of code you gave me isnt returning anything

[dull tusk]

If you’re still seeing HTTP 401: Invalid Authentication code as the Telegram bot reply, we need the exact ERROR line from the gateway log that contains the 401 — your earlier snippets only show “run start/end”, not the failure.

Run this on the machine running OpenClaw (it just searches the log file):

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "LOG=$LOG"
grep -nE "HTTP 401|Invalid Authentication|Unauthorized|moonshot|telegram" "$LOG" | tail -120

Paste that output.

Also paste:

openclaw channels status --probe

Why: there are two different common 401 sources and the fix is different:

• If the 401 line mentions api.telegram.org / Telegram / grammY → your Telegram bot token is invalid/revoked/mismatched. Fix: update channels.telegram.botToken (or TELEGRAM_BOT_TOKEN) and openclaw gateway restart.

• If the 401 line mentions api.moonshot.ai / moonshot → your Moonshot API key is being rejected during real runs (even if a probe looked “ok” once). Fix: re-enter the Moonshot key via:

  openclaw models auth add
  openclaw gateway restart
  

Once you paste the grep output, I’ll tell you exactly which one it is and the minimal fix steps.

Yeah — that grep pattern was too specific, and OpenClaw’s logs are JSON, so the 401 line often doesn’t contain the exact text you expect.

Do this instead (it will always return something):

1) Find the active log file

ls -t /tmp/openclaw/openclaw-*.log | head -1

2) After you reproduce the 401 in Telegram, run these two commands

(First shows the latest errors; second searches for any 401 anywhere.)

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
tail -n 300 "$LOG" | grep -nE "ERROR|401|Unauthorized|moonshot|telegram" | tail -120

If that still prints nothing, run this (no grep, just raw tail) and paste the last ~80 lines:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
tail -n 200 "$LOG"

3) Also paste this (it rules out Telegram token issues fast)

openclaw channels status --probe

Once I can see the actual ERROR/401 line, I can tell whether it’s:

• Telegram bot token invalid (401 from api.telegram.org), or
• Moonshot request failing (401 from api.moonshot.ai), or
• something else being surfaced into Telegram.

[cunning hollow]

{"0":"{"subsystem":"agent/embedded"}","1":"embedded run start: runId=4f8082ed-e7b9-471d-9410-1eb4cc254d92 sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 provider=moonshot model=kimi-k2.5 thinking=off messageChannel=telegram","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-02-09T00:29:17.291Z","logLevelId":2,"logLevelName":"DEBUG","path":{"fullFilePath":"file:///home/maddenctelles/.npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:777:14","fileName":"subsystem-CAq3uyo7.js","fileNameWithLine":"subsystem-CAq3uyo7.js:777","fileColumn":"14","fileLine":"777","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:777","method":"logToFile"}},"time":"2026-02-09T00:29:17.293Z"} Gateway reachable.

• Telegram default: enabled, configured, running, in:7m ago, mode:polling, bot:@GoogleMadden_Bot, token:config, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
maddenctelles@penguin:~$

[dull tusk]

Got it. The line you pasted is not the error — it’s just:

• embedded run start … provider=moonshot … messageChannel=telegram

The 401 has to be in an ERROR line either in the file log or in the systemd journal.

Also important: your models status --probe says Moonshot auth is OK, so either:

• the Gateway service hasn’t actually picked up the new auth yet (needs restart), or
• the 401 is coming from somewhere else and being surfaced to Telegram.

Let’s force-catch the real 401:

A) Restart gateway, then watch live logs while sending 1 Telegram message

On the server:

openclaw gateway restart
openclaw logs --follow

Then send one “hi” in Telegram and copy/paste the first lines that contain ERROR or 401 from that live log output.

B) If openclaw logs --follow still doesn’t show it, check systemd journal

Sometimes errors go to journald instead of the file log:

journalctl --user -u openclaw-gateway.service -n 300 --no-pager | grep -iE "401|unauthor|moonshot|telegram|error" | tail -80

Paste that output.

C) One more thing: your config has plugin errors

You previously had:

• plugins.entries.telegram: plugin not found: telegram
• plugins.slots.memory: plugin not found: memory-core

If you haven’t already, run:

openclaw doctor --repair
openclaw gateway restart

Then re-test Telegram.

Once you paste the actual 401 ERROR line (from A or B), I can tell you exactly whether it’s Moonshot auth, Telegram token, or a config/plugin issue being echoed into chat.

[cunning hollow]

Feb 08 19:28:54 penguin node[4226]: 2026-02-09T00:28:54.514Z [gateway] agent model: moonshot/kimi-k2.5
Feb 08 19:28:55 penguin node[4226]: 2026-02-09T00:28:55.613Z [telegram] [default] starting provider (@GoogleMadden_Bot)
Feb 08 19:28:55 penguin node[4226]: 2026-02-09T00:28:55.657Z [telegram] autoSelectFamily=false (default-node22)
Feb 08 19:39:33 penguin node[4226]: 2026-02-09T00:39:33.582Z [openclaw] Suppressed AbortError: AbortError: This operation was aborted
Feb 08 19:39:48 penguin node[4425]: 2026-02-09T00:39:48.968Z [gateway] agent model: moonshot/kimi-k2.5
Feb 08 19:39:49 penguin node[4425]: 2026-02-09T00:39:49.666Z [telegram] [default] starting provider (@GoogleMadden_Bot)
Feb 08 19:39:49 penguin node[4425]: 2026-02-09T00:39:49.724Z [telegram] autoSelectFamily=false (default-node22)

Not seeing a 401 Error line but there is an Abort error

[dull tusk]

Ok — the journal output you pasted still doesn’t include the 401 line (it only shows the gateway + telegram starting). So we need to catch the 401 live in the console.

Best way to catch the real cause (2 minutes)

On the server (SSH), temporarily run the gateway in the foreground:

openclaw gateway stop
openclaw gateway --verbose

Now send one message to the bot in Telegram (like “hi”).

In that same terminal, you should see an error line that includes where the 401 comes from (it’ll usually mention either Moonshot’s API URL or Telegram’s API). Copy/paste the first few lines around that 401 here.

When you’re done, restore the background service:

• press Ctrl+C

• then run:

  openclaw gateway start
  

What we’re looking for

• If it mentions api.moonshot.ai (or Moonshot) → your Moonshot key being used at runtime is still wrong/mismatched. Fix is re-entering it via:

  openclaw models auth add
  openclaw gateway restart
  

• If it mentions api.telegram.org → your Telegram bot token is wrong/revoked. Fix is updating channels.telegram.botToken and restarting.

Paste the 401 line from the --verbose run and I’ll tell you the exact fix.

[dull tusk]

AbortError by itself is usually not the problem — it commonly shows up when something gets cancelled (gateway restart, long‑poll loop restarting, request timing out). It’s also consistent with the “Suppressed AbortError” line you saw earlier in journald.

But we still need to answer the real question: why Telegram is showing HTTP 401: Invalid Authentication code.

Right now we don’t have the actual 401 in logs, so let’s make it deterministic and capture it.

Step 1: Confirm the 401 is happening “right now”

In Telegram, send /status.

• If /status replies normally, Telegram is connected and the 401 is coming from the model call (Moonshot or something else).
• If /status also errors, it’s more systemic.

Tell me what /status returns.

Step 2: Turn on trace logging temporarily (so the 401 can’t hide)

On the gateway machine:

openclaw config set logging.level trace
openclaw gateway restart

Step 3: Reproduce once + paste the last log chunk

1. Send a normal message in Telegram (e.g. “hi”) until you get the 401 reply.
2. Immediately run:

openclaw logs --limit 300

…and paste the output here. With trace enabled, the error line will be in there.

Step 4 (optional fallback): journalctl if file logs still don’t show it

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

Paste the last ~80 lines around the time you sent the message.

Once we have the real 401 line, we’ll know if it’s:

• api.moonshot.ai → Moonshot auth at runtime (even if a probe said “ok” once), or
• api.telegram.org → Telegram token issue, or
• something else being surfaced into chat.

Also: paste the exact Telegram bot reply text (copy/paste) — sometimes it includes which endpoint returned the 401.

[cunning hollow]

00:47:19 [telegram] update: {"update_id":872008168,"message":{"message_id":27,"from":{"id":6445657256,"is_bot":false,"first_name":"Madden","last_name":"Telles","language_code":"en"},"chat":{"id":6445657256,"first_name":"Madden","last_name":"Telles","type":"private"},"date":1770598038,"text":"hi"}}
00:47:19 telegram inbound: chatId=6445657256 from=telegram:6445657256 len=67 preview="[Telegram Madden Telles id:6445657256 +57s 2026-02-08 19:47 EST] hi"
00:47:19 [diagnostic] lane enqueue: lane=session:agent:main:main queueSize=1
00:47:19 [diagnostic] lane dequeue: lane=session:agent:main:main waitMs=5 queueSize=0
00:47:19 [diagnostic] lane enqueue: lane=main queueSize=1
00:47:19 [diagnostic] lane dequeue: lane=main waitMs=7 queueSize=0
00:47:19 [agent/embedded] embedded run start: runId=4dd0644f-513c-4151-b366-db9a2ee1748d sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 provider=moonshot model=kimi-k2.5 thinking=off messageChannel=telegram
00:47:19 [diagnostic] session state: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
00:47:19 [diagnostic] run registered: sessionId=9f20956e-6968-47cd-8c09-899e621f7e63 totalActive=1
00:47:19 [agent/embedded] embedded run prompt start: runId=4dd0644f-513c-4151-b366-db9a2ee1748d sessionId=9f20956e-6968-47cd-8c09-899e621f7e63
00:47:19 [agent/embedded] embedded run agent start: runId=4dd0644f-513c-4151-b366-db9a2ee1748d
00:47:19 [ws] → event agent seq=9 clients=1 run=4dd0644f…748d agent=main session=main stream=lifecycle aseq=1 phase=start

[dull tusk]

The snippet you pasted is still only the start of the run — there’s no “run done” and no error yet:

embedded run agent start …

So we still haven’t captured whatever is producing the “HTTP 401: Invalid Authentication code” message you’re seeing in Telegram.

Let’s make this foolproof with 2 commands that always work:

1) Paste the last 200 lines of the file log (this will include the real error)

Run:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "LOG=$LOG"

tail -n 200 "$LOG"

Send “hi” in Telegram again right before you run that, so the error is in the tail.

2) Sanity check: can the gateway send a normal Telegram message?

This confirms the Telegram bot token is truly OK:

openclaw message send --channel telegram --target 6445657256 --message "test from the server"

• If this fails with a 401 → Telegram bot token issue.
• If it sends successfully → Telegram token is fine, and the 401 is coming from the model/provider side (or config).

3) Also run Doctor once (you had plugin-not-found errors earlier)

openclaw doctor

Paste any errors it reports.

Once you paste the tail -n 200 output, I can point to the exact line that’s generating the 401 and the exact fix.

[cunning hollow]

It succesfully sent the test message

[dull tusk]

Good — if openclaw message send --channel telegram … works, then your Telegram bot token is fine.

So the HTTP 401: Invalid Authentication code you see as a Telegram reply is almost certainly coming from the model call (Moonshot) and OpenClaw is just relaying the error text back to you.

The log chunk you pasted stops at run start:

embedded run agent start …

…but the 401 (or whatever error triggers that Telegram reply) will show up after that, when the model request happens.

Capture the missing part (the simplest way)

1. On the gateway machine, run:

openclaw logs --follow

2. Send one “hi” in Telegram.
3. Wait until you see either:

• embedded run done (success), or
• an ERROR line

Then copy/paste the lines from:

• embedded run start: runId=...
  through
• the first ERROR line (or through embedded run done)

Right now you’re only copying the beginning, before the failure happens.

If you still can’t see the error in openclaw logs --follow

Pull the raw file tail right after you get the 401 reply in Telegram:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
tail -n 250 "$LOG"

Paste that output.

Once I can see the post-agent start lines, I can tell you exactly why it’s replying with 401 (wrong Moonshot endpoint, wrong key being used at runtime, config override, etc.) and the exact command to fix it.

[cunning hollow]

i csnt paste long messages

[dull tusk]

No problem — Discord truncation is real. Let’s make it small and targeted.

Option A (best): paste only the error lines

Right after you trigger the 401 in Telegram, run:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
grep -n '"logLevelName":"ERROR"' "$LOG" | tail -20

That should be short enough to paste.

If that still doesn’t show it, broaden slightly:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

grep -nE "ERROR|401|Unauthorized|moonshot" "$LOG" | tail -40

Option B: paste just the “window” around your message time

Run this and paste the output:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
tail -n 120 "$LOG"

120 lines should fit.

Option C: upload the log snippet as a file

If your Discord allows it, you can attach a small text file:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
tail -n 300 "$LOG" > /tmp/openclaw-snippet.txt
ls -lh /tmp/openclaw-snippet.txt

Then upload /tmp/openclaw-snippet.txt.

Once I see the actual ERROR line, we’ll be done — right now we’ve proven Telegram works, so it’s just the model call failing and getting echoed back.

[cunning hollow]

7:{"0":"\u001b[38;5;167m\u001b[1mHealth check failed\u001b[22m\u001b[39m: gateway closed (1006 abnormal closure (no close frame)): no close reason\n \u001b[38;5;138mGateway target:\u001b[39m \u001b[38;5;209mws://127.0.0.1:18789\u001b[39m\n \u001b[38;5;138mSource:\u001b[39m \u001b[38;5;138mlocal loopback\u001b[39m\n \u001b[38;5;138mConfig:\u001b[39m \u001b[38;5;209m/home/maddenctelles/.openclaw/openclaw.json\u001b[39m\n \u001b[38;5;138mBind:\u001b[39m \u001b[38;5;216mloopback\u001b[39m","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-02-08T23:03:00.660Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/maddenctelles/.npm-global/lib/node_modules/openclaw/dist/entry.js:917:68","fileName":"entry.js","fileNameWithLine":"entry.js:917","fileColumn":"68","fileLine":"917","filePath":".npm-global/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/entry.js:917","method":"console.error"}},"time":"2026-02-08T23:03:00.661Z"}
8:{"0":"Missing Control UI assets. Build them with pnpm ui:build (auto-installs UI deps).","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-02-08T23:03:00.693Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///home/maddenctelles/.npm-global/lib/node_modules/openclaw/dist/entry.js:917:68","fileName":"entry.js","fileNameWithLine":"entry.js:917","fileColumn":"68","fileLine":"917","filePath":".npm-global/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/entry.js:917","method":"console.error"}},"time":"2026-02-08T23:03:00.697Z"}
102:{"0":"Invalid config at /home/maddenctelles/.openclaw/openclaw.json:\n- plugins.entries.telegram: plugin not found: telegram\n- plugins.slots.memory: plugin not found: memory-core","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"open

[dull tusk]

Cool — the fact that openclaw message send --channel telegram … worked proves your Telegram bot token is valid.

Also: the “ERROR” lines you pasted (Missing Control UI assets, plugin not found, 1006 health check) are from yesterday (23:03 / 23:41), so they’re not the reason you’re seeing the 401 right now.

Make the logs “short” so you can paste them

Let’s write to a fresh debug log file so it only contains this reproduction:

openclaw config set logging.file "/tmp/openclaw/telegram-401.log"
openclaw config set logging.level debug
openclaw gateway restart

Now:

1. Send “hi” in Telegram (until you get the HTTP 401… reply)
2. Immediately run:

tail -n 120 /tmp/openclaw/telegram-401.log

Paste those ~120 lines here — that will include the actual 401 source line (it’ll mention what URL/provider is returning the 401).

(Optional cleanup after we’re done)

openclaw config unset logging.file
openclaw gateway restart

Once you paste that tail, I can tell you exactly whether the 401 is coming from Moonshot (model auth) or something else inside the run, and what to change.

[cunning hollow]

I cannot paste this all

[dull tusk]

Got it — don’t paste the whole tail.

Let’s extract only the lines that mention the 401 (should be <20 lines), and if needed we’ll grab ~15 lines around it.

Assuming you already switched logging to /tmp/openclaw/telegram-401.log:

1) Show only 401/unauthorized lines (short)

grep -nE "401|Invalid Authentication|Unauthorized" /tmp/openclaw/telegram-401.log | tail -20

Paste just that output.

2) If that prints something: grab a tiny context window around the last match

n=$(grep -nE "401|Invalid Authentication|Unauthorized" /tmp/openclaw/telegram-401.log | tail -1 | cut -d: -f1)

sed -n "$((n-5)),$((n+15))p" /tmp/openclaw/telegram-401.log

Paste that (it’s ~20 lines).

3) If grep prints nothing

Then the “HTTP 401…” message is being generated without logging the underlying error (or it’s in journald). Run:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager | grep -iE "401|unauthor|moonshot|error" | tail -40

Paste that.

Once we have the actual 401 source line, we’ll know whether it’s Moonshot (api.moonshot.ai) or something else and I can give you the exact fix.

[cunning hollow]

32:{"0":"{"subsystem":"gateway"}","1":"log file: /tmp/openclaw/telegram-401.log","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-02-09T01:10:38.272Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/maddenctelles/.npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:777:14","fileName":"subsystem-CAq3uyo7.js","fileNameWithLine":"subsystem-CAq3uyo7.js:777","fileColumn":"14","fileLine":"777","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CAq3uyo7.js:777","method":"logToFile"}},"time":"2026-02-09T01:10:38.273Z"}

[dull tusk]

All good — you don’t need to paste long stuff. Right now you’ve only pasted the “log file path” line, not the actual error.

Let’s force the log to contain only this one failure, then extract just the 1–5 matching lines.

1) Clear the new log (so it stays tiny)

On the gateway machine:

: > /tmp/openclaw/telegram-401.log

2) Reproduce once

Send “hi” in Telegram until you see the HTTP 401: Invalid Authentication code reply.

3) Paste ONLY these short outputs (each should be a few lines)

grep -n "401" /tmp/openclaw/telegram-401.log | tail -10

grep -n '"logLevelName":"ERROR"' /tmp/openclaw/telegram-401.log | tail -10

grep -nE "telegram outbound|sendMessage|outbound" /tmp/openclaw/telegram-401.log | tail -10

One of those will catch either:

• the real upstream 401 (usually includes which host returned it), or
• the Telegram outbound line that includes the actual text it sent (“HTTP 401…”), which helps us backtrack.

If any of those commands returns nothing, just tell me “401 grep empty / ERROR grep empty / outbound grep empty” and we’ll switch to journald filtering next.

[cunning hollow]

none of the commands returned anything

is there anyway we can fix this weve been going in circles

[dull tusk]

Ok — if those greps return nothing, that means one of two things:

1. the text “HTTP 401: Invalid Authentication code” is not being logged (even though it’s being sent), or
2. we’re still not looking at the exact moment/log where it happens.

Since you already proved Telegram outbound works (openclaw message send … succeeded), the 401 is not Telegram auth. It’s almost certainly an error being generated inside the agent run and then sent back as a normal message.

Quickest next step: paste the exact Telegram bot reply text

In Telegram, long‑press the bot’s message → Copy → paste it here.
(It’s short, so Discord will allow it.) Sometimes it includes which service returned the 401.

If you can’t copy it: upload a tiny file instead of pasting

Run these 2 commands (they create a small text file with just the relevant lines), then upload the file in Discord:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

tail -n 400 "$LOG" > /tmp/last-400.log

Now upload: /tmp/last-400.log

(Discord file upload is way easier than fighting message limits.)

Also: please run Doctor repair once (you had plugin-not-found config errors)

Those old config errors can cause weird behavior later:

openclaw doctor --repair
openclaw gateway restart

After that, try Telegram again.

If you paste the exact Telegram bot reply (or upload /tmp/last-400.log), I can point to the specific line that triggers the 401 and give you the exact fix.

Yeah, we are looping because we still don’t have the one line that proves where the HTTP 401: Invalid Authentication code is coming from.

But we did make progress:

• Telegram bot token is fine (your openclaw message send --channel telegram … test succeeded).
• So the 401 you see in Telegram is almost certainly coming from the model call (or some internal request), and OpenClaw is just echoing it back.

The “stop going in circles” move: generate 1 debug file and upload it

This avoids Discord paste limits and gives enough context to pinpoint it.

Run these on the gateway machine:

openclaw status --all > /tmp/openclaw-debug.txt
openclaw models status --probe >> /tmp/openclaw-debug.txt
openclaw channels status --probe >> /tmp/openclaw-debug.txt

openclaw logs --limit 300 >> /tmp/openclaw-debug.txt
ls -lh /tmp/openclaw-debug.txt

Then upload /tmp/openclaw-debug.txt here in Discord.

(That report is designed to be shareable; it redacts secrets in status --all.)

If you want a quick “try this” while you prep the file

Re-run the model auth setup (this fixes 90% of “401 from model provider” cases):

openclaw models auth add
openclaw gateway restart

Then test Telegram again.

Upload that debug file and I’ll tell you the exact fix in one shot (no more guesswork).

[cunning hollow]

HTTP 401: Invalid Authentication

[dull tusk]

That Telegram reply (HTTP 401: Invalid Authentication) means: the bot is running and receiving your message, but when it tries to call the model provider, the provider rejects the credential and OpenClaw is echoing that error back to you.

Two concrete things to do (no more log spelunking):

1) Re-enter the Moonshot key the right way, then restart

In the output you posted earlier, your Moonshot key preview started with nvapi-… — that’s an NVIDIA-style key prefix, not a Moonshot key (Moonshot keys are typically sk-...). If you pasted the wrong provider’s key, you’ll get exactly this kind of 401.

On the gateway machine run:

openclaw models auth add
openclaw gateway restart

When it asks, pick moonshot and paste a Moonshot Open Platform API key.

(Alternative wizard path if you prefer guided setup:)

openclaw onboard --auth-choice moonshot-api-key
openclaw gateway restart

2) In Telegram, reset the chat session and retry

Send these to the bot:

• /reset
• then: hi

If it still replies HTTP 401… after you’ve re-added the Moonshot key + restarted, then you’re almost certainly using the wrong provider for the key (Moonshot vs Kimi Coding are separate), and we should switch the model/provider to match the key you actually have.

If you tell me what site you got the API key from (Moonshot Open Platform vs “Kimi Coding” vs NVIDIA), I’ll give you the exact correct provider/model setting for that key.

[cunning hollow]

This is where I got the key

https://build.nvidia.com/moonshotai/kimi-k2.5

[dull tusk]

I don’t see the link/screenshot in what came through on my side — can you paste the URL (or upload a screenshot) of the page where you generated the key?

That said, based on what you posted earlier, your key preview looked like it starts with nvapi-…. If that’s true, that key is not a Moonshot (Kimi) key — it’s an NVIDIA key — and that will produce exactly the HTTP 401: Invalid Authentication you’re seeing when OpenClaw calls the moonshot provider.

If your key starts with nvapi-… (NVIDIA)

You have 2 options:

Option A (recommended): get a real Moonshot key

Create the API key on Moonshot’s platform: https://platform.moonshot.ai/
Then on the server:

openclaw models auth add
openclaw gateway restart

Pick moonshot and paste the new key. Then test in Telegram again.

Option B: keep the NVIDIA key

Then we need to switch your model/provider config away from moonshot/kimi-k2.5 to whatever provider matches NVIDIA’s endpoint (different setup).

Quick check (don’t paste the full key)

Tell me just the prefix (first 5–6 chars) of the key you’re using, e.g.:

• nvapi- (NVIDIA) vs
• sk- (Moonshot/OpenAI-style)

Once you paste the URL (or key prefix), I’ll give you the exact “do this, then this” fix with the right provider.

[dull tusk]

That URL is NVIDIA NIM / Integrate API, not Moonshot’s own API.

So an nvapi-... NVIDIA key will not work with OpenClaw’s built-in Moonshot provider (moonshot/kimi-k2.5), because that provider expects a Moonshot Open Platform key (typically sk-...) and calls https://api.moonshot.ai/v1.

You have two valid paths:

Option A (simplest): use a real Moonshot key

1. Create a key at https://platform.moonshot.ai/
2. Put it in ~/.openclaw/.env as:

   MOONSHOT_API_KEY=sk-...
   

3. Restart:

   openclaw gateway restart
   

Option B (use your NVIDIA key): add a custom “nvidia” provider + switch the model

NVIDIA’s OpenAI-compatible endpoint is:
https://integrate.api.nvidia.com/v1/chat/completions (base URL: https://integrate.api.nvidia.com/v1)

1. Put your NVIDIA key in ~/.openclaw/.env (don’t paste it in Discord):

   NVIDIA_API_KEY=nvapi-...
   

2. Edit ~/.openclaw/openclaw.json and add this (you can paste under the top-level object; JSON5 is OK):

{
  agents: {
    defaults: {
      model: { primary: "nvidia/moonshotai/kimi-k2.5" },

      models: { "nvidia/moonshotai/kimi-k2.5": { alias: "Kimi K2.5 (NVIDIA)" } },
    },
  },
  models: {
    mode: "merge",
    providers: {
      nvidia: {
        baseUrl: "https://integrate.api.nvidia.com/v1",
        apiKey: "${NVIDIA_API_KEY}",
        api: "openai-completions",
        models: [
          {
            id: "moonshotai/kimi-k2.5",
            name: "Moonshot Kimi K2.5 (NVIDIA)",
            reasoning: false,

            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 256000,
            maxTokens: 8192,
          },
        ],
      },
    },
  },
}

3. Restart:

openclaw gateway restart

4. Verify the new provider works:

openclaw models status --probe --probe-provider nvidia

If you want, paste your current agents.defaults.model.primary and whether your key starts with nvapi- or sk- (prefix only), and I’ll tell you which option is the right one for your setup.

[cunning hollow]

how do I put the key in ~/.openclaw/.env

[dull tusk]

On Linux, ~/.openclaw/.env is just a plain text file that the Gateway reads on startup (great for systemd because it won’t inherit your terminal env).

Safest way (doesn’t put your key in shell history)

1. Make sure the folder exists:

mkdir -p ~/.openclaw

2. Open the env file in an editor:

nano ~/.openclaw/.env

3. Add one line (pick the one that matches your key/provider):

• If you’re using the NVIDIA key from build.nvidia.com (starts with nvapi-):

NVIDIA_API_KEY=nvapi-PASTE_YOUR_KEY_HERE

• If you instead created a Moonshot key from platform.moonshot.ai (often sk-...):

MOONSHOT_API_KEY=sk-PASTE_YOUR_KEY_HERE

Save and exit nano (Ctrl+O, Enter, then Ctrl+X).

4. Lock down permissions (recommended):

chmod 600 ~/.openclaw/.env

5. Restart the Gateway so it picks it up:

openclaw gateway restart

Verify it’s being read

Run:

openclaw models status --probe

Important: don’t paste the key into Discord (even partially beyond the prefix).

[cunning hollow]

i cannot find that file I can find openclaw but not openclaw/.env

[dull tusk]

There usually isn’t an openclaw/.env file.

OpenClaw loads env vars from either:

1. a .env in the current working directory (only if you’re running it from a folder), and/or
2. the global fallback: ~/.openclaw/.env (this is the common one, especially when running as a service)

So if you “can find openclaw but not openclaw/.env”, that’s expected.

macOS / Linux (most common)

In Terminal:

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

Add your key(s), e.g.:

ANTHROPIC_API_KEY=...
OPENAI_API_KEY=...
OPENROUTER_API_KEY=...

Then restart:

openclaw gateway restart

Docs: https://docs.openclaw.ai/help/faq#env-vars-and-env-loading

Windows

The equivalent is usually:
C:\Users\<you>\.openclaw\.env

If you still get “bot doesn’t reply”

Reply with the output of these (redact any secrets):

openclaw --version
openclaw status
openclaw channels status

[cunning hollow]

would it be openclaw.json?

[dull tusk]

openclaw.json is the main config file, yes — but it’s not the same thing as the .env.

• Config (JSON5): ~/.openclaw/openclaw.json
• Global env file (API keys, etc): ~/.openclaw/.env

So you should not be looking for openclaw/.env inside some “openclaw program folder”. The .env lives in your home folder under ~/.openclaw/.

Also: .env is a hidden dotfile, so your file browser may not show it.

• macOS Finder: press Cmd + Shift + . to show hidden files
• Windows Explorer: View → “Hidden items”

If ~/.openclaw/.env doesn’t exist, that’s fine — just create it and put your key in there, then restart the gateway.

Docs:

• Config location: https://docs.openclaw.ai/help/faq#what-format-is-the-config-where-is-it
• .env loading: https://docs.openclaw.ai/help/faq#env-vars-and-env-loading

[cunning hollow]

dont think it exist. how do we create it

[dull tusk]

Create it manually — it’s just a plain text file named .env inside the ~/.openclaw folder.

macOS / Linux

Open Terminal and run:

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

Paste your key line(s), for example:

ANTHROPIC_API_KEY=your_key_here
# or OPENAI_API_KEY=...
# or OPENROUTER_API_KEY=...

Save + exit:

• Ctrl + O (write), Enter
• Ctrl + X (exit)

Then restart OpenClaw:

openclaw gateway restart

Windows (PowerShell)

mkdir $env:USERPROFILE\.openclaw -ea 0
notepad $env:USERPROFILE\.openclaw\.env

Add e.g.

ANTHROPIC_API_KEY=your_key_here

Save, then restart the gateway/service.

If you tell me what OS you’re on (Windows/macOS/Linux) and how you started OpenClaw (Control Panel app vs terminal vs service), I can give the exact “restart” step for your setup.

[cunning hollow]

those commands dont work on linux specifically nano

im in the terminal

[dull tusk]

On Linux, that usually just means nano isn’t installed (not that the steps are wrong).

Here are a few easy options — pick one:

Option A: use vi (almost always installed)

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

Press i to insert, add e.g.

ANTHROPIC_API_KEY=your_key_here

Then Esc, type :wq, Enter.

Option B: create the file without an editor (copy/paste safe)

mkdir -p ~/.openclaw
cat > ~/.openclaw/.env <<'EOF'
ANTHROPIC_API_KEY=your_key_here
EOF

chmod 600 ~/.openclaw/.env

Option C: install nano (if you want it)

• Debian/Ubuntu:

  sudo apt update && sudo apt install -y nano
  

• Fedora:

  sudo dnf install -y nano

• Alpine:

  sudo apk add nano
  

Then restart the gateway

openclaw gateway restart

Also: don’t paste your API key into Discord—just confirm the file exists with:

ls -la ~/.openclaw

If you tell me what Linux distro you’re on (Ubuntu/Debian/Fedora/etc.) and whether you installed via docker or npm, I can tailor the exact commands.

Cool — if you’re in a Linux terminal, we can do this without nano.

1) Create the folder + .env file

Run:

mkdir -p ~/.openclaw
cat > ~/.openclaw/.env <<'EOF'
ANTHROPIC_API_KEY=PASTE_YOUR_KEY_HERE
EOF

chmod 600 ~/.openclaw/.env

(Replace PASTE_YOUR_KEY_HERE with your real key. Don’t paste the key into Discord.)

2) Restart OpenClaw

If you installed it as a service, this usually works:

openclaw gateway restart

If that errors, tell me what it says and we’ll use the right restart method for your install.

3) Quick sanity checks (paste outputs, keys redacted)

openclaw --version
openclaw gateway status
openclaw status
openclaw channels status
openclaw models status

Also: how did you install/run OpenClaw on Linux — Docker or npm (npm i -g openclaw)? The restart + env loading differs a bit between those.

[cunning hollow]

What do I put for my key specifally if got it through nvidia, also installed through npm

[dull tusk]

If the key is “from NVIDIA”, the important bit is: OpenClaw only knows how to use keys for the provider you configured. There isn’t a built-in “nvidia” provider in OpenClaw (in the docs), so you can’t just paste an NVIDIA key into ANTHROPIC_API_KEY and expect it to work.

First: check what OpenClaw is actually trying to use

Run this and paste the output (redact any secrets — it shouldn’t print full keys anyway):

openclaw models status

That will usually make it obvious, e.g. it’ll say it needs ANTHROPIC_API_KEY, or OPENAI_API_KEY, or OPENROUTER_API_KEY, etc.

If you want to use NVIDIA specifically

You typically need an OpenAI-compatible base URL from NVIDIA (their docs will show an endpoint with /v1/... and model ids), and then you configure a custom provider in ~/.openclaw/openclaw.json.

You can store the key in your env file as (example):