401 auth fail

[limber heron]

401 “Authentication Failed” can mean two different things in OpenClaw, so first we need to pin down where it’s happening:

1) Quick questions (so we don’t guess)

1. What OS are you on (Windows/macOS/Linux/VPS)?

2. Where do you see the 401?

   • Dashboard / Control UI connect (browser says unauthorized / 401), or
   • when you send a message and the model call fails (logs show a provider 401)

3. Paste these (redact any secrets):

openclaw --version
openclaw gateway status
openclaw models status

…and the exact 401 line from:

openclaw logs --follow

2) If you’re trying to use Kimi, you probably want Moonshot (Kimi)

Moonshot provides Kimi via OpenAI-compatible endpoints. The doc path is here:
https://docs.openclaw.ai/providers/moonshot

The intended setup flow is:

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

Then set your default model to a Moonshot ref (example from docs: moonshot/kimi-k2.5).

Important gotcha from the docs: Moonshot and “Kimi Coding” are separate providers (different keys/endpoints/model refs). Keys are not interchangeable.

3) If the 401 is in the Dashboard connect

That’s usually a gateway auth token/password mismatch (common after reinstall because the service can be reading different config/env than your CLI). The runbook section is here:
https://docs.openclaw.ai/gateway/troubleshooting (see “Dashboard control ui connectivity”)

Send the openclaw gateway status output + the exact unauthorized message and we can point to the specific fix.

Once you paste the outputs above, I’ll tell you exactly which branch you’re in (gateway auth vs Moonshot/ZAI provider auth) and the minimal steps to fix it.

Your gateway is healthy (RPC probe: ok). The important bit in your openclaw status output is this:

• Default model: zai/glm-5
• Configured models: only zai/glm-5
• Auth: only zai has a key

So right now OpenClaw is still configured for GLM (Z.AI), not Kimi. A 401 here is almost always “provider rejected the API key” (or you’re calling a provider you haven’t actually configured).

Switch to Kimi (no reinstall needed)

Kimi = Moonshot provider in OpenClaw docs: https://docs.openclaw.ai/providers/moonshot

Run:

openclaw onboard --auth-choice moonshot-api-key
# paste your MOONSHOT key when prompted

Then set the default model:

openclaw config set agents.defaults.model.primary "moonshot/kimi-k2.5"
openclaw gateway restart

Re-check:

openclaw status

You should see Default: moonshot/kimi-k2.5 and it should show Moonshot auth present.

macOS gotcha (very common)

Your output says “Shell env: off” and you’re running as a LaunchAgent. On macOS, the service often does not see your terminal/.env env vars. So if you were relying on .env for keys, the gateway may not be using them. Using openclaw onboard ... is the clean fix because it stores creds where the service can actually read them.

If you still get 401 after switching

Run this, reproduce one request, and paste the single 401 block (redact secrets):

openclaw logs --follow

The log line will usually mention which provider is returning 401 (zai vs moonshot), and that tells us exactly which key/config is wrong.

[languid peak]

i added kimi api now in control center its giving me HTTP 401: Invalid Authentication

[limber heron]

That specific error (HTTP 401: Invalid Authentication) is coming from the model provider (not the gateway), meaning: the request reached Moonshot/Kimi, but the key/provider pairing they’re using is not accepted.

Two super common gotchas with Kimi in OpenClaw:

1. Moonshot (Kimi) vs Kimi Coding are different providers

   • Moonshot (Kimi) docs: https://docs.openclaw.ai/providers/moonshot
   • Keys are not interchangeable.
   • If you have a Moonshot key, you must configure moonshot and use models like moonshot/....
   • If you have a Kimi Coding key, you must configure kimi-coding and use kimi-coding/....

2. macOS LaunchAgent doesn’t reliably see your terminal .env
   Your earlier output showed Shell env: off and you’re running as a LaunchAgent, so pasting/setting env vars in a shell often won’t affect the running service. The reliable path is openclaw onboard ... (it stores creds where the service can use them).

Do this (and paste the output)

1. Make sure you used the right onboarding command:

openclaw onboard --auth-choice moonshot-api-key
# OR, if you specifically have a Kimi Coding key:
openclaw onboard --auth-choice kimi-code-api-key

2. Restart gateway:

openclaw gateway restart

3. Paste these outputs (redact keys):

openclaw status
openclaw models status

If you can also paste the single 401 block from:

openclaw logs --follow

…I can tell you immediately whether you’re still accidentally calling zai/glm-*, or you’re calling moonshot/kimi-coding with the wrong key/endpoint.

Your openclaw status looks correctly switched to Kimi:

• Default: moonshot/kimi-k2.5
• Moonshot auth profile exists (api_key=1)

So if Control Center still shows HTTP 401: Invalid Authentication, that’s almost always one of these:

1) Wrong kind of Kimi key (Moonshot vs Kimi Coding)

OpenClaw has two different “Kimi” providers and the keys are not interchangeable:

• Moonshot (Kimi): models look like moonshot/... (what you’re using now)
  Docs: https://docs.openclaw.ai/providers/moonshot
• Kimi Coding: models look like kimi-coding/...

If your key is actually for Kimi Coding, you need to onboard that instead and switch the model:

openclaw onboard --auth-choice kimi-code-api-key
openclaw config set agents.defaults.model.primary "kimi-coding/k2p5"
openclaw gateway restart

2) Right provider, wrong endpoint region (.ai vs .cn)

Moonshot has two endpoints:

• International: https://api.moonshot.ai/v1
• China: https://api.moonshot.cn/v1 (docs mention this explicitly)

If your Moonshot account/key is for the CN endpoint, using .ai will often 401.

Quick debug (high signal)

In Discord run:

• /model status (or in terminal: openclaw models status)
  and paste the part that shows moonshot baseUrl (if it shows it).

Also paste the single 401 block from:

openclaw logs --follow

That log line will tell us if it’s failing against moonshot or kimi-coding and which URL it’s hitting. Then we can tell you exactly which switch to make.

That log snippet is only gateway startup — it never actually shows the failing Kimi request yet, so we can’t see why Moonshot is returning 401.

Fastest way to pinpoint it (no guessing)

Run a live auth probe for Moonshot and paste the output (redact secrets):

openclaw models status --probe-provider moonshot

This will do a small real request and will usually print the exact 401 + which endpoint/profile it used. (Docs for --probe: https://docs.openclaw.ai/cli/models)

Two very common causes of “Invalid Authentication” with “Kimi”

1. Wrong provider for the key you have
   OpenClaw has two “Kimi” paths and the keys are not interchangeable:
   • Moonshot (Kimi) → models like moonshot/kimi-k2.5 (what you’re set to)
     https://docs.openclaw.ai/providers/moonshot
   • Kimi Coding → models like kimi-coding/k2p5

If your key is actually a Kimi Coding key, switch like this:

openclaw onboard --auth-choice kimi-code-api-key
openclaw models set kimi-coding/k2p5
openclaw gateway restart

2. Right provider, wrong region endpoint (.ai vs .cn)
   Moonshot can be api.moonshot.ai (international) vs api.moonshot.cn (China). If your account/key is CN-scoped, hitting .ai can 401. The probe output will help confirm this.

One more thing

In your earlier output the bot joked that your .env showed — if you ever pasted a full API key in the thread, rotate it. Even partial leaks are worth treating seriously.

Post the output of openclaw models status --probe-provider moonshot and we’ll know immediately whether to (a) swap to kimi-coding, (b) regenerate the Moonshot key, or (c) switch the base URL to .cn.

[languid peak]

i did change ! not getting any response from bot ! connected | idle
agent main | session main (openclaw-tui) | moonshot/kimi-k2.5 | tokens ?/256k

[limber heron]

“connected | idle … tokens ?/256k” in openclaw-tui just means the TUI is connected to the gateway, but you haven’t gotten a successful model response yet.

To see why you’re getting no reply, we need the first error that happens when you send a message:

1. In one terminal:

openclaw logs --follow

2. In the TUI, send something simple like: ping

3. In the logs, you should see either:

• a Moonshot request + a clear error (often still a 401), or
• nothing at all (then the TUI isn’t actually sending to that gateway / wrong target)

Also run this (it’s the quickest “is my Moonshot auth valid” check):