I just installed openclaw, instantly got a 401: User not found error. | Friends of the Crustacean 🦞🤝 | Page 1

static onyx Feb 25, 2026, 4:55 AM

#

Havnet been able to talk to the bot at all. I did the "hatch by TUI" option and in the gray box it sent the message then it instantly said 401 error. whats the best course of action? did i brick the install because the bot never hatched? I got a different error at first, then I ended up opening the dashboard with the token url. then everything i have tried since has only given me 401 error. all status say the bot is running fine but i cant talk to it

jade sableBOT Feb 25, 2026, 4:57 AM

#

That doesn’t “brick” anything — a 401 during hatch just means something it tried to call rejected auth, so the agent never actually got to run and reply.

In practice there are two common 401s:

Model/provider auth failed (most common; e.g. OpenRouter/OpenAI/etc returns “401 User not found/unauthorized”)
Dashboard / Gateway auth mismatch (Control UI can’t auth to the Gateway)

Do this on the machine running the Gateway (copy/paste output)

These are safe to share (they redact secrets):

openclaw --version
openclaw status --all
openclaw models status

If openclaw models status shows a 401 for a provider, that’s your root cause: fix the provider creds (or re-run onboarding to re-enter them), then:

#

openclaw gateway restart

If models status is fine but the Control UI says unauthorized / 401, then you’re likely just using the wrong Gateway token. This FAQ section covers exactly how to authenticate the dashboard and where the token comes from:
https://docs.openclaw.ai/start/faq#how-do-i-authenticate-the-dashboard-token-on-localhost-vs-remote

Also useful: watch the exact error while you try one message

openclaw logs --follow

Paste the first few lines around the 401 and we can tell immediately which of the two cases you’re in.

(And no — the bot “not hatching” is expected if it hit a 401; once auth is fixed, re-hatch/retry works.)

static onyx Feb 25, 2026, 5:04 AM

#

the models status says token status -None, but says i have an api key

jade sableBOT Feb 25, 2026, 5:06 AM

#

If openclaw models status shows “Token status: None” but also says an API key is present, that’s usually not a problem by itself — it often just means “no OAuth token, using API key auth”.

The thing that is a problem is: the running Gateway process still can’t actually use the key, so the first model call during hatch returns 401.

Two super-common causes:

1) Your API key is only in your shell, but the Gateway is running as a service (systemd/launchd)

Services often don’t inherit your terminal env vars, so the CLI can “see” the key but the daemon can’t.

Fix: put the key somewhere the Gateway always loads it from, then restart:

Put it in ~/.openclaw/.env (recommended), or
Put it in the config env block

Docs for how env loading works (and precedence): https://docs.openclaw.ai/help/environment.md

Then:

#

openclaw gateway restart

2) You’re probing one provider, but your default model is using a different provider with no creds

models status will show the default model + fallbacks. If the one you’re actually using points at a provider without valid auth, you’ll get 401 instantly.

Quick next step (paste output here; it redacts secrets)

Run these on the machine where the Gateway is running:

openclaw --version
openclaw gateway status
openclaw models status --probe --plain

#

Those three will tell us exactly:

whether your service is using a different config than your CLI (gateway status shows that),
which provider is returning the 401 (--probe),
and what model OpenClaw is actually trying to call.

static onyx Feb 25, 2026, 5:07 AM

#

this is what im getting for the error codes

04:52:01 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=slug-gen-1771995120982 isError=true error=HTTP 401: User not found.
04:52:01 warn [agent/embedded] embedded run agent end: runId=slug-gen-1771995120982 isError=true error=HTTP 401: User not found.

jade sableBOT Feb 25, 2026, 5:07 AM

#

That log line is the smoking gun: it’s not a dashboard/gateway-auth problem — it’s your model provider call failing immediately during the hatch “embedded run” (slug-gen…), so the bot never gets far enough to reply.

Also: you pasted your full name + email in the thread. I’d delete/redact that if you can (no need to share it here).

What “HTTP 401: User not found” usually means

Almost always: wrong API key for the provider you’re actually using, or the Gateway service can’t see the key (env var not available to systemd/launchd).

Do this on the machine running the Gateway (and paste output)

These outputs redact secrets:

openclaw --version
openclaw models status --probe --plain

Key thing I want to see in that output:

what your Default model provider is (openrouter/openai/anthropic/etc)

#

which provider fails during --probe

Most common fix (service can’t see your key)

If you set the API key only in your terminal, but you installed the daemon, the daemon often won’t inherit it.

Put the key in ~/.openclaw/.env on the gateway host (recommended), e.g.:

for OpenRouter: OPENROUTER_API_KEY=...
for OpenAI: OPENAI_API_KEY=...
etc.

Then restart:

openclaw gateway restart

#

(Env loading details: https://docs.openclaw.ai/help/environment.md)

Once you paste openclaw models status --probe --plain, I can tell you exactly which provider/key name you need to fix.

#

That agent/embedded … slug-gen … HTTP 401: User not found means the Gateway tried to call your LLM provider during hatch and the provider rejected auth. Nothing is bricked — it just can’t make any model call yet, so the bot can’t reply.

Two things to do:

1) Confirm which provider/model is failing (paste output, it redacts secrets)

Run on the Gateway machine:

openclaw models status --probe --plain

That will tell us exactly which provider profile is returning the 401.

2) The most common fix: the daemon can’t see your API key

If you installed the daemon/service, env vars you set in your terminal often don’t reach the running Gateway.

Put your provider key into ~/.openclaw/.env on the gateway host (recommended), then restart:

#

openclaw gateway restart

Env var loading rules: https://docs.openclaw.ai/help/environment

Important: don’t paste your API key here. Also you accidentally posted your email/name earlier — worth editing/redacting that in the thread if you can.

Once you paste the models status --probe --plain output, I’ll tell you the exact key name/provider to fix (OpenRouter/OpenAI/Anthropic/etc).

static onyx Feb 25, 2026, 5:09 AM

#

i dont have a .env in there, shouldi create one ?

#

and its openrouter

jade sableBOT Feb 25, 2026, 5:09 AM

#

Yes — you can (and in your case, you probably should) create it.

Create `~/.openclaw/.env` on the Gateway host

Create/edit the file:

nano ~/.openclaw/.env

Put only your provider key in there (one line), e.g. depending on what provider you’re using:

OPENROUTER_API_KEY=sk-or-...
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

Save/exit, then restart:

openclaw gateway restart

#

Important gotcha (very common)

If your Gateway is running as a daemon/service, it might be using a different home/state dir (via OPENCLAW_HOME / OPENCLAW_STATE_DIR). So before/after you do this, run and paste:

openclaw gateway status
openclaw models status --probe --plain

That’ll confirm which provider is failing and that the service is reading the same state dir where you created the .env.

Also: don’t paste the key into Discord—just the command outputs.

#

Yep — for OpenRouter, create ~/.openclaw/.env and put your key there.

On the machine running the Gateway:

nano ~/.openclaw/.env

Add exactly this (no quotes):

OPENROUTER_API_KEY=sk-or-xxxxxxxx

Save, then restart the gateway:

#

openclaw gateway restart

Then verify it’s actually fixed:

openclaw models status --probe --plain

If you still get 401 after that

It’s usually one of these:

The key is just wrong/expired → generate a fresh key in OpenRouter and replace the line.
The Gateway service is using a different state dir (so it’s not reading ~/.openclaw/.env). Check:

#

  openclaw gateway status

and paste that output here.

(Also: don’t paste the key into Discord.)

static onyx Feb 25, 2026, 5:15 AM

#

didnt work give up

#

can i just start over ?

jade sableBOT Feb 25, 2026, 5:16 AM

#

Yeah, I get why you’re done — but this one’s almost always a 5‑minute fix, because that exact string “HTTP 401: User not found” is coming from OpenRouter, not from OpenClaw.

That means OpenClaw is sending a key, but OpenRouter says it doesn’t map to any user → usually the key is wrong (copied the wrong thing) or the Gateway is still running with an old/empty key.

Fastest way to prove which it is (no OpenClaw involved)

On the gateway machine, run (this won’t print your key):

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

If that returns 401 User not found → your OPENROUTER_API_KEY is not a valid OpenRouter key. Generate a new API key in OpenRouter (it should look like sk-or-...), update it, restart gateway, done.
If that works (you see JSON) → the key is fine, but the Gateway service isn’t seeing it (wrong state dir/user, or key set somewhere else and .env won’t override).

If the curl test works, do these two and paste the output

#

openclaw gateway status
openclaw models status --probe --plain

Those will show whether the daemon is reading the same config/state you’re editing, and exactly which provider profile is failing.

Also: you pasted personal email/name earlier—worth editing that out of the thread.

static onyx Feb 25, 2026, 5:17 AM

#

it says my status is OK when i do openclaw models --probe

#

so its not that

jade sableBOT Feb 25, 2026, 5:17 AM

#

Yes — you can absolutely start over. The clean “wipe my config/state but keep OpenClaw installed” way is openclaw reset.

On the machine running the Gateway:

openclaw gateway stop
openclaw reset --dry-run
openclaw reset
openclaw onboard --install-daemon

Docs: https://docs.openclaw.ai/cli/reset

Two important notes (because they can make it look like “reset didn’t help”):

If you have OPENROUTER_API_KEY set somewhere globally (systemd/launchd env, shell profile, etc), that can still override what you type later. After reset, try openclaw models status --probe --plain to confirm the OpenRouter probe is actually passing.
If you want the full nuclear option, there’s also openclaw uninstall (removes service + state), but I’d try reset first. Docs: https://docs.openclaw.ai/install/uninstall

#

If you paste the output of openclaw models status --probe --plain after the reset/onboard, we can verify OpenRouter auth is finally good (no secrets shown).

#

models status --probe saying OK is good news: it proves your OpenRouter key itself works.

But it doesn’t prove the running Gateway service is using that same key/config. The giveaway is: the Gateway log still showed HTTP 401: User not found during an embedded run — that’s the daemon making a provider call and getting rejected.

The most common situation is a config/state mismatch (CLI is reading ~/.openclaw, but the service is running under a different user / different state dir, e.g. /root/.openclaw, or a different profile).

Please run these on the gateway host and paste the output (safe to share; no secrets):

openclaw gateway status
openclaw status --deep

In openclaw gateway status, look for something like “Config (cli)” vs “Config (service)” being different. If they differ, that’s your whole problem.

Quick fix if they differ:

Put the OPENROUTER_API_KEY=sk-or-... into the state dir the service is actually using (the one shown by “Config (service)”), then:

#I just installed openclaw, instantly got a 401: User not found error.