rain condor Feb 18, 2026, 7:43 AM

#

I've installed openclaw a few weeks ago, and accidentally set the search perameter too wide, which burned $10 in 3 hours. so I stopped it, and reset it. since then, i've been trying to reinstall and get it to work, however it's keeps getting stuck, it keeps asking if i want to use the old api key but i want to change it and it won't allow me to, no matter how manytimes i reset. both XAi, and OpenAi couldn't help and get stuck in a odd loop. any suggestions?

pallid fractalBOT Feb 18, 2026, 7:43 AM

#

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

glacial matrixBOT Feb 18, 2026, 7:48 AM

#

That “use the old API key?” loop usually means the old key is still saved in your OpenClaw state dir, so reinstalling doesn’t actually clear it.

OpenClaw credentials typically live in one (or more) of these places:

~/.openclaw/.env (common if you run the Gateway as a service/daemon)
~/.openclaw/agents/<agentId>/agent/auth-profiles.json (auth profiles store)
Or you might be using a profile (OPENCLAW_PROFILE / --profile), which changes the state dir to ~/.openclaw-<profile> — so you keep resetting the wrong one.

1) First: confirm what OpenClaw is actually using

Run these and paste the output here:

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

#

(That will also reveal if “Config (cli)” and “Config (service)” don’t match.)

2) Fastest way to replace the saved key (no reinstall)

If you want to switch to a new OpenAI API key:

openclaw models auth paste-token --provider openai --profile-id openai:manual
openclaw models auth order set --provider openai openai:manual
openclaw gateway restart

For xAI:

openclaw models auth paste-token --provider xai --profile-id xai:manual
openclaw models auth order set --provider xai xai:manual

#

openclaw gateway restart

That bypasses the onboarding “reuse old key” prompt by explicitly creating/using a new auth profile.

3) If you want a clean slate (nuclear, but reliable)

Do a dry-run first so you can see what it would remove:

openclaw reset --dry-run

Then wipe config+creds+sessions:

#

openclaw reset --scope config+creds+sessions --yes

After that, rerun onboarding.

4) Avoid burning $10 again

Two easy guardrails:

Keep web search results low (e.g. tools.web.search.maxResults: 3-5)
Use a cheaper model for background/sub-agent work (agents.defaults.subagents.model) if you’re doing lots of “search + summarize” loops

Paste the outputs from step (1) and I’ll tell you exactly which store/file is holding the old key in your setup.

rain condor Feb 18, 2026, 7:51 AM

#

sj@SJs-MacBook-Pro ~ % openclaw --version
2026.2.17
sj@SJs-MacBook-Pro ~ % openclaw status --all

🦞 OpenClaw 2026.2.17 (4134875) — One CLI to rule them all, and one more restart because you changed the port.

│
OpenClaw status --all

Overview
┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.2.17 │
│ OS │ macos 26.2 (arm64) │
│ Node │ 22.22.0 │
│ Config │ ~/.openclaw/openclaw.json

#

│
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.17 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (connect failed: connect │
│ │ ECONNREFUSED 127.0.0.1:18789) │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ LaunchAgent installed · not loaded · unknown │
│ Node service │ LaunchAgent not installed │
│ Agents │ 1 total · 0 bootstrapping · 0 active · 0 sessions │
└─────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────┘

#

Agents
┌────────────┬───────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap │ Sessions │ Active │ Store │
├────────────┼───────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────┤
│ main │ OK │ 0 │ unknown │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴───────────┴──────────┴──────────┴──────────────────────────────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/sj/.openclaw/openclaw.json
Bind: loopback

✗ Config: /Users/sj/.openclaw/openclaw.json
✓ Restart sentinel: none
✓ Port 18789
! Tailscale: off · unknown
error: Error: spawn tailscale ENOENT
✓ Skills: 6 eligible · 0 missing · /Users/sj/.openclaw/workspace
! Channel issues skipped (gateway unreachable)

Gateway health:
connect failed: connect ECONNREFUSED 127.0.0.1:18789

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

#

sj@SJs-MacBook-Pro ~ % openclaw models status

🦞 OpenClaw 2026.2.17 (4134875) — Hot reload for config, cold sweat for deploys.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-opus-4-6
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

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

anthropic effective=env:sk-ant-a...0pQ_xgAA | env=sk-ant-a...0pQ_xgAA | source=env: ANTHROPIC_API_KEY

OAuth/token status

none

#

sj@SJs-MacBook-Pro ~ % openclaw gateway status

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

│
◇
Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json (missing)
Config (service): ~/.openclaw/openclaw.json (missing)

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: unknown (Bad request.
Could not find service "ai.openclaw.gateway" in domain for user gui: 501)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /Users/sj/.openclaw/openclaw.json

Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
sj@SJs-MacBook-Pro ~ %

glacial matrixBOT Feb 18, 2026, 7:52 AM

#

You’re on a good version (2026.2.17), so this is almost certainly just “old creds still being selected” (auth profile order) or you’re editing creds on a different machine than the Gateway is running on.

1) Please paste the rest of these outputs (they got cut off)

Run and paste everything:

openclaw gateway status
openclaw models status

Those two will tell us:

is the Gateway actually running locally (or remote mode)?
which provider it’s trying (openai vs xai) and which auth profile id it’s stuck on

2) Force OpenClaw to use a new API key (no reinstall)

Do the one that matches what you want to use:

#

OpenAI key:

openclaw models auth paste-token --provider openai --profile-id openai:manual
openclaw models auth order set --provider openai openai:manual
openclaw gateway restart

xAI key:

openclaw models auth paste-token --provider xai --profile-id xai:manual
openclaw models auth order set --provider xai xai:manual
openclaw gateway restart

That usually fixes the “it keeps asking to reuse old key” loop because you’re explicitly creating a fresh profile + making it the first one tried.

3) Common gotcha on macOS (daemon doesn’t see your shell env)

#

Your output shows the real blocker right now isn’t the API key — the Gateway isn’t running at all:

unreachable (connect failed: ECONNREFUSED 127.0.0.1:18789)
Gateway service: LaunchAgent installed · not loaded

So the CLI/UI keeps “looping” because there’s nothing listening on 127.0.0.1:18789.

1) Start the Gateway service (LaunchAgent)

Run:

openclaw gateway start
openclaw gateway status

If it starts, gateway status should stop saying “not loaded” and the probe should become reachable.

#

If you previously set keys like OPENAI_API_KEY / XAI_API_KEY in your terminal, but you run OpenClaw as a LaunchAgent/daemon, it won’t inherit that env. In that case put the key in:

~/.openclaw/.env (then openclaw gateway restart)

But do steps (1) + paste the outputs first — the models status output will make it obvious which path you’re on.

#

2) If `gateway start` fails, run it in the foreground to see the actual error

openclaw gateway run --verbose

(Leave it running, and in another terminal try openclaw status again.)

3) Paste these two outputs (they’ll tell us exactly what’s wrong)

openclaw gateway status --deep
openclaw logs --follow

Once the Gateway is reachable again, then we can fix the “keeps asking about the old key” by setting a new auth profile (openclaw models auth paste-token …) — but we need the Gateway up first.

rain condor Feb 18, 2026, 7:53 AM

#

I don't want to use either, i want to use anthropic

#

by the way, i'm a completely noob coder, never coded before...

glacial matrixBOT Feb 18, 2026, 7:54 AM

#

Yep — your logs make this super clear now: your problem isn’t the API key yet; the Gateway isn’t running.

From openclaw gateway status:

Service: LaunchAgent (not loaded) / Service unit not found
Config (cli/service): ~/.openclaw/openclaw.json (missing)
RPC probe fails because nothing is listening on 127.0.0.1:18789

So the dashboard can’t connect, and any “key wizard loop” is kind of a red herring until the Gateway + config exist.

Fix: recreate config + install/start the macOS LaunchAgent

Run:

openclaw onboard --flow quickstart --install-daemon

#

Then verify it’s alive:

openclaw gateway status
openclaw status

At that point Gateway: … reachable should replace the ECONNREFUSED stuff, and the dashboard at http://127.0.0.1:18789/ should load.

Important: your API key is ONLY in your current shell right now

openclaw models status shows:

Shell env: off
source is env: ANTHROPIC_API_KEY

That means even if the key works in your terminal, the LaunchAgent won’t see it.

#

After onboarding (or anytime), set the key into OpenClaw’s auth store instead of relying on terminal env:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw models auth order set --provider anthropic anthropic:manual
openclaw gateway restart

(If you’re actually trying to use OpenAI or xAI instead, tell me which one and I’ll give you the exact paste-token commands for that provider.)

If you paste the output of openclaw onboard … (just the non-secret parts) and the new openclaw gateway status, I can tell you what the next blocker is (if any).

#

Totally fine — you don’t need to “code” for this. It’s mostly running a couple commands and answering prompts.

Right now your output shows the core issue is:

the Gateway isn’t running (ECONNREFUSED 127.0.0.1:18789)
the macOS LaunchAgent service isn’t installed/loaded properly
and relying on “API key in Terminal env” won’t work well with a background service

Do this first (the simple “get it working again” path)

In Terminal, run:

openclaw onboard --flow quickstart --install-daemon

That will:

create the missing config/workspace if needed

#

install the macOS background service (LaunchAgent)
guide you through auth (where you can paste the new key)

Then verify:

openclaw gateway status

You want it to say the service is loaded/running and the RPC probe is ok (not refused).

Quick question (so I give you the exact next step)

Which provider are you trying to use now?

Anthropic (Claude) API key
OpenAI API key
xAI (Grok) API key

#

(Also: don’t paste your full key into Discord; if you share output, redact anything that looks like sk-....)

rain condor Feb 18, 2026, 7:58 AM

#

sj@SJs-MacBook-Pro ~ % openclaw gateway status

🦞 OpenClaw 2026.2.17 (4134875) — Claws out, commit in—let's ship something mildly responsible.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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 73681, state active)
RPC probe: ok

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

#

sj@SJs-MacBook-Pro ~ % openclaw status

🦞 OpenClaw 2026.2.17 (4134875) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

│
◇
│
◇
OpenClaw status

Overview
┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Dashboard │ http://127.0.0.1:18789/ │
│ OS │ macos 26.2 (arm64) · node 22.22.0 │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.17 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 20ms · auth token · SJs-MacBook-Pro. │
│ │ local (192.168.43.72) app 2026.2.17 macos 26.2 │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 73681, state active) │
│ Node service │ LaunchAgent not installed │
│ Agents │ 1 · 1 bootstrapping · sessions 1 · default main active 1m ago │
│ Memory │ 0 files · 0 chunks · dirty · sources memory · plugin memory-core · vector unknown · fts ready · │
│ │ cache on (0)

#

│
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Heartbeat │ 30m (main) │
│ Sessions │ 1 active · default claude-3-haiku-20240307 (200k ctx) · ~/.openclaw/agents/main/sessions/ │
│ │ sessions.json │
└─────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘

Security audit
Summary: 0 critical · 3 warn · 1 info
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
WARN Some gateway.nodes.denyCommands entries are ineffective
gateway.nodes.denyCommands uses exact command-name matching only. - Unknown command names (not in defaults/allowCommands): camera.snap, camera.clip, screen.rec…
Fix: Use exact command names (for example: canvas.present, canvas.hide, canvas.navigate, canvas.eval, canvas.snapshot, canvas.a2ui.push, canvas.a2ui.pushJSONL, canvas.a2ui.reset). If you need broader restrictions, remove risky commands from allowCommands/default workflows.

#

WARN Some configured models are below recommended tiers
Smaller/older models are generally more susceptible to prompt injection and tool misuse. - anthropic/claude-3-haiku-20240307 (Haiku tier (smaller model); Below…
Fix: Use the latest, top-tier model for any bot with tools or untrusted inboxes. Avoid Haiku tiers; prefer GPT-5+ and Claude 4.5+.
Full report: openclaw security audit
Deep probe: openclaw security audit --deep

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config (8556…CgR4 · len 46) · accounts 1/1 │
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────┘

Sessions
┌────────────────────────────────────────────────────┬────────┬─────────┬─────────────────────────┬───────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├────────────────────────────────────────────────────┼────────┼─────────┼─────────────────────────┼───────────────────┤
│ agent:main:main │ direct │ 1m ago │ claude-3-haiku-20240307 │ unknown/200k (?%) │
└────────────────────────────────────────────────────┴────────┴─────────┴─────────────────────────┴───────────────────┘

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting

Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Need to test channels? openclaw status --deep

glacial matrixBOT Feb 18, 2026, 7:59 AM

#

Nice — that output means you’re back to a healthy baseline:

LaunchAgent loaded
Gateway running
RPC probe: ok
Dashboard should work at http://127.0.0.1:18789/

If the Dashboard asks for a token

Run this and paste the value into the UI (don’t post it here):

openclaw config get gateway.auth.token

Now: actually switching to a new API key (the reliable way)

Because the Gateway is a background service on macOS, it often won’t use whatever key you set in your Terminal. Best practice is to store the key in OpenClaw’s auth store.

#

Pick the provider you want, run ONE of these, paste your NEW key when prompted, then restart:

Anthropic (Claude):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw models auth order set --provider anthropic anthropic:manual
openclaw gateway restart

OpenAI:

openclaw models auth paste-token --provider openai --profile-id openai:manual
openclaw models auth order set --provider openai openai:manual
openclaw gateway restart

xAI (Grok):

#

Perfect — you’re back in the “working” state now.

Key bits from your openclaw status:

Gateway is reachable (reachable 20ms)
It’s running with auth token (so the Dashboard may ask for a token)
Agent is bootstrapping (normal right after setup; should settle after a minute)

Next steps

1) Open the Dashboard

Go to: http://127.0.0.1:18789/

If it asks for a token, get it locally (don’t paste it into Discord):

#

openclaw models auth paste-token --provider xai --profile-id xai:manual
openclaw models auth order set --provider xai xai:manual
openclaw gateway restart

Then confirm what it’s using (redact anything that looks like sk-... if you paste output):

openclaw models status

Quick question

Which API key are you trying to use going forward: Anthropic, OpenAI, or xAI? (Your current models status earlier showed an Anthropic key present, but we can switch you cleanly to whichever you want.)

rain condor Feb 18, 2026, 8:00 AM

#

dashboard is working, just can't connect, (disconnected 1008)

#

i'm tring to use Anthropic

glacial matrixBOT Feb 18, 2026, 8:01 AM

#

openclaw config get gateway.auth.token

2) Confirm your model/provider auth (this is where the “old key” issue shows up)

Run and paste the output here with keys redacted:

openclaw models status

3) If you want to force a NEW API key (recommended vs env vars)

Pick the provider you want long-term and run one of these (it will prompt you to paste the new key):

OpenAI

rain condor Feb 18, 2026, 8:01 AM

#

the model has an old anthropic key, i want to change to a new anthropic key

glacial matrixBOT Feb 18, 2026, 8:01 AM

#

That’s all good news — you’re basically “unstuck” now.

From what you pasted:

Gateway reachable + authenticated (so Dashboard can connect)
1 active session (it’s running)
It’s currently using Claude Haiku for the session, which is the cheap Claude tier (so you shouldn’t see the same burn rate as Opus-type defaults).

About those Security Audit warnings

“Reverse proxy headers not trusted” → you’re on gateway.bind=loopback, so this only matters if you later put the dashboard behind a reverse proxy. Safe to ignore for a local-only setup.
“denyCommands entries ineffective” → also not critical for getting you working; it’s just telling you some command names don’t match exact tool names.

Next: if your goal is “use a NEW API key and stop it asking about the old one”

Now that the Gateway is running, do it the reliable way (store the key in OpenClaw’s auth store, not terminal env):

Run this and paste the output (redact any sk-...):

#

openclaw models auth paste-token --provider openai --profile-id openai:manual
openclaw models auth order set --provider openai openai:manual
openclaw gateway restart

xAI

openclaw models auth paste-token --provider xai --profile-id xai:manual
openclaw models auth order set --provider xai xai:manual
openclaw gateway restart

Anthropic

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual

#

openclaw models status

Then tell me which provider you want to use going forward (Anthropic / OpenAI / xAI), and I’ll give you the exact one-liner to set that key + make it the one OpenClaw prefers.

Optional: prevent future “search burned $10” incidents

If you’re using web search, cap it (example: 3 results):

openclaw config set tools.web.search.maxResults 3

(Then openclaw gateway restart if it doesn’t hot-reload.)

If the main issue is solved now, tell me what part is still failing: Dashboard login/token, API key swap, or channel connect.

#

Awesome — you’re fully back online now:

RPC probe: ok
Gateway service is loaded + running
Telegram channel is ON / OK

So at this point the “can’t connect / can’t install” part is solved.

About that security warning (Haiku)

That warning is basically: “small models are easier to trick if strangers can message your bot + it has tools.”

If this bot is only you (Telegram allowFrom set to your user) it’s usually fine.
If it’s exposed to groups/strangers, you should switch to a stronger model later.

(Also: this warning does not block anything; it’s informational.)

If your remaining goal is “swap to a NEW API key and stop it using the old one”

#

openclaw models auth order set --provider anthropic anthropic:manual
openclaw gateway restart

4) If “bootstrapping” never stops

If it stays bootstrapping for ~5+ minutes, run:

openclaw logs --follow

…and paste the first obvious error lines.

One quick question: which provider are you trying to use going forward (OpenAI, xAI, or Anthropic)?

#

Do this (don’t paste keys into Discord):

If you want to keep using Anthropic (Claude)

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw models auth order set --provider anthropic anthropic:manual
openclaw gateway restart

If you want OpenAI instead

openclaw models auth paste-token --provider openai --profile-id openai:manual
openclaw models auth order set --provider openai openai:manual
openclaw gateway restart

If you want xAI instead

#

openclaw models auth paste-token --provider xai --profile-id xai:manual
openclaw models auth order set --provider xai xai:manual
openclaw gateway restart

Then confirm (redact any sk-... if you paste output):

openclaw models status

Cost guardrail (optional but recommended)

If you don’t want background activity, disable heartbeat (it runs every 30m by default):

openclaw config set agents.defaults.heartbeat.every 0m
openclaw gateway restart

#

One question so I give you the exact final step: are you trying to switch keys for Anthropic, OpenAI, or xAI?

#

Got it — Anthropic is the easiest here.

Right now OpenClaw is clearly using ANTHROPIC_API_KEY from env (your earlier openclaw models status showed source=env: ANTHROPIC_API_KEY). On macOS, since the Gateway runs as a LaunchAgent, the reliable place to put that key is:

~/.openclaw/.env

Update to your new Anthropic key (no coding needed)

Open the env file in TextEdit:

open -e ~/.openclaw/.env

Put (or replace) this line with your new key, then save:

#

ANTHROPIC_API_KEY=sk-ant-...

Do not paste the key into Discord.

Restart the Gateway so it picks up the change:

openclaw gateway restart

Verify it’s using the new one (it will only show a shortened/redacted version):

openclaw models status

#

If after that it still shows the old key, paste the non-secret parts of openclaw models status (redact anything starting with sk-) and we’ll find the other place it’s being loaded from.

#

If it’s still using the old Anthropic key, it means that key is being loaded from somewhere on your machine (usually ~/.openclaw/.env, sometimes your shell/LaunchAgent env).

0) First: confirm where it’s coming from (safe to paste, it’s redacted)

Run:

openclaw models status

Look for the line that says source=... (and don’t paste anything starting with sk-).

If `models status` says `source=env: ANTHROPIC_API_KEY`

That means OpenClaw is reading the key from environment variables (most commonly ~/.openclaw/.env).

Edit the OpenClaw env file:

#

open -e ~/.openclaw/.env

Replace (or add) this line with your new key, save:

ANTHROPIC_API_KEY=sk-ant-...

Restart the gateway:

openclaw gateway restart

Re-check:

#

openclaw models status

If you’d rather store it in OpenClaw’s auth store (also good)

This writes into ~/.openclaw/agents/main/agent/auth-profiles.json:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw models auth order set --provider anthropic anthropic:manual
openclaw gateway restart
openclaw models status

Important: if ANTHROPIC_API_KEY is still set in your env, OpenClaw may keep using that. So if you do the auth-store method, also remove/replace the key in ~/.openclaw/.env.

#

If you paste the redacted openclaw models status output, I’ll tell you exactly which of the above applies and what line to change.

rain condor Feb 18, 2026, 8:07 AM

#

dash still sayd disconnected (1008) unauthorized: device token mismatch

glacial matrixBOT Feb 18, 2026, 8:09 AM

#

That error is dashboard auth, not the Anthropic API key.

disconnected (1008) unauthorized: device token mismatch means: the Control UI is sending a saved gateway token that doesn’t match the gateway’s current gateway.auth.token.

Fix (don’t paste tokens into Discord)

Get the current gateway token from your machine:

openclaw config get gateway.auth.token

Easiest way: let OpenClaw open the dashboard with the right token:

openclaw dashboard

#

(Or openclaw dashboard --no-open to just print the URL.)

If you’re already on the dashboard page:

Open Control UI settings → Gateway Access
Paste the token into the Gateway Token field (not password)
Click Connect

If it still keeps reusing the wrong token, open the dashboard in an Incognito/Private window (or clear site data for 127.0.0.1) and try again.

Once the dashboard connects, we can finish the Anthropic key swap—but this 1008 error has to be cleared first.

rain condor Feb 18, 2026, 8:11 AM

#

ok nice, dash is on, but still not connected to telegram

#

on dash it sayd unsupported schema node, use raw mode

glacial matrixBOT Feb 18, 2026, 8:14 AM

#

If the Dashboard is up and Telegram shows “ON / OK”, the usual reason it still “doesn’t work” is Telegram DM access control (default is dmPolicy: "pairing"), meaning: your bot will receive messages, but it won’t reply until your Telegram user is approved.

1) Pair your Telegram DM (most common fix)

In Telegram, open a DM with your bot and send hi (or /start).
On your Mac, run:

openclaw pairing list telegram

You should see a pending code.
3. Approve it:

openclaw pairing approve telegram <CODE>

#

Then message the bot again in Telegram.

2) If you don’t see a pairing code, tail logs while you DM the bot

In one terminal:

openclaw logs --follow

Then DM the bot in Telegram again. You’ll usually see a log line like “DM blocked: not paired” or “sender not in allowFrom”, which tells us exactly what to change.

3) Quick diagnostic snapshot (paste output here; no secrets)

openclaw status --deep

Also: are you DM’ing the bot, or trying to use it in a Telegram group? (Groups often require an @mention by default, and Telegram privacy mode can block group messages.)

#

That “unsupported schema node, use raw mode” message is just the Dashboard’s config form renderer complaining — it can’t render some parts of the config schema as nice UI fields.

It does not mean Telegram is broken.

What to do about the “unsupported schema node”

In the Dashboard, go to the config editor and switch to Raw mode (raw JSON/JSON5 editor). Or skip the dashboard for config edits and use the CLI (openclaw config set …) instead.

Why Telegram still “isn’t connected” (most common cause)

Even when Telegram shows ON / OK, OpenClaw will not reply to your DM until you pair/approve your Telegram user (default dmPolicy is usually pairing).

Do this:

In Telegram, DM your bot and send: hi (or /start)
On your Mac, run:

rain condor Feb 18, 2026, 8:15 AM

#

it says "no pending telegram pairing requests"

glacial matrixBOT Feb 18, 2026, 8:15 AM

#

openclaw pairing list telegram

Approve the code it shows:

openclaw pairing approve telegram <CODE>

DM the bot again in Telegram.

If `pairing list` shows nothing

Run this in one terminal:

openclaw logs --follow

Then DM the bot again — the logs will say exactly why it didn’t respond (not paired / not allowed / etc.). Paste the non-secret log line(s) here.

rain condor Feb 18, 2026, 8:16 AM

#

[openclaw] failed to start CLI: Error: no pending pairing request found

glacial matrixBOT Feb 18, 2026, 8:17 AM

#

“No pending telegram pairing requests” means the Gateway hasn’t seen any Telegram DM from you that would trigger a pairing request (or your Telegram DMs aren’t using pairing at all).

Let’s force it into a known-good state and verify the Gateway is actually seeing your Telegram messages.

1) Force Telegram DMs to use pairing (safe default)

Run this on your Mac:

openclaw config set channels.telegram.dmPolicy "pairing"
openclaw gateway restart

2) Trigger a pairing request

In Telegram, DM your bot and send /start (then send “hi”).

Then run:

#

openclaw pairing list telegram

You should now see a code. Approve it:

openclaw pairing approve telegram <CODE>

3) If it STILL says “no pending…”, we need to see if Telegram messages reach the Gateway

Run this in a terminal:

openclaw logs --follow

#

While that’s running, DM the bot again in Telegram. If no log line appears at all, you’re likely messaging the wrong bot account (or Telegram isn’t delivering updates to that token).

If log lines appear, paste the non-secret bits here (just the Telegram-related lines; redact anything that looks like a token).

Also quick check: are you DM’ing the bot, or trying in a Telegram group? (Pairing is for DMs; groups have separate rules like “require mention”.)

#

“No pending telegram pairing requests” + that pairing approve … no pending pairing request found error just means: OpenClaw hasn’t received a Telegram DM from you that created a pairing request (or Telegram polling is failing).

Let’s debug in a way that tells us exactly what’s happening:

1) Probe Telegram health (paste output)

Run:

openclaw channels status --probe

This will usually surface auth/polling errors.

2) Check Telegram logs (paste output)

openclaw channels logs --channel telegram --lines 200

#

I’m specifically looking for errors like “409 Conflict: terminated by other getUpdates request” (happens if some other app/old OpenClaw instance is also using the same bot token), or network/DNS errors.

3) While watching logs, DM the bot

In one terminal:

openclaw logs --follow

Then in Telegram, DM your bot and send /start (and then “hi”).

If you see Telegram inbound logs: great — we’ll get the pairing code from openclaw pairing list telegram.
If you see nothing at all when you DM: you’re likely messaging a different bot than the token you configured, or Telegram updates are being consumed elsewhere (409 conflict).

Quick note on the Dashboard message

“unsupported schema node, use raw mode” is just the dashboard’s config UI saying “I can’t render this nicely”. It doesn’t break Telegram—use Raw view or the CLI.

#

Paste the outputs from (1) and (2) and we’ll nail the exact cause in one step.

rain condor Feb 18, 2026, 8:19 AM

#

still says no pendig telegram pairing

glacial matrixBOT Feb 18, 2026, 8:20 AM

#

If it still says “no pending telegram pairing”, one of these is true:

Your Telegram DMs are not set to pairing (so no pairing request will ever be created), or
The Gateway is not receiving Telegram updates at all (wrong bot token, webhook set somewhere else, or another process is consuming updates).

Let’s identify which in 60 seconds.

Step A — confirm DM policy

Run:

openclaw config get channels.telegram.dmPolicy

If it’s not pairing, set it and restart:

#

openclaw config set channels.telegram.dmPolicy "pairing"
openclaw gateway restart

Then DM your bot in Telegram (/start, then “hi”) and run:

openclaw pairing list telegram

Step B — if dmPolicy is `pairing` and still no pending requests

That means OpenClaw likely isn’t seeing your Telegram messages. Please paste these outputs:

openclaw channels status --probe

#

openclaw channels logs --channel telegram --lines 120

Those logs usually show the exact reason (common ones: wrong token / webhook enabled / “409 Conflict: another getUpdates is running”).

Also confirm: you’re DM’ing the same bot username that channels status --probe reports (easy to accidentally message an old bot).

rain condor Feb 18, 2026, 8:22 AM

#

ok i see it now, on terminal, so how to confirm pair?

glacial matrixBOT Feb 18, 2026, 8:23 AM

#

If you can see the pairing code in Terminal, you’re basically done.

1) Approve the pairing code

Run (replace with your code):

openclaw pairing approve telegram <CODE>

Example:

openclaw pairing approve telegram ABCD1234

2) (Optional) Notify yourself on Telegram

If you want it to send a confirmation message back to you in Telegram when you approve:

#

openclaw pairing approve telegram <CODE> --notify

3) Verify it worked

Run:

openclaw pairing list telegram

It should now show no pending requests (because it’s approved).

Then just DM your bot again in Telegram (“hi”) — it should respond normally.

If it still doesn’t reply after approval, paste the last ~30 lines from:

#

openclaw channels logs --channel telegram --lines 80

rain condor Feb 18, 2026, 8:24 AM

#

perfect, next lock to unlock, when I message bot on telegram, it respond with
http 401 authantication_error invalid x-api-key

#

but im not using xapi, i'm using anthropic

glacial matrixBOT Feb 18, 2026, 8:26 AM

#

That Telegram reply is coming from Anthropic, and:

HTTP 401 authentication_error: invalid x-api-key

means the Anthropic API key that the Gateway is currently using is invalid (typo, old/revoked key, wrong key type, or the service didn’t pick up the new one).

Fix it (most reliable)

Paste/store your new Anthropic key into OpenClaw’s auth store:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw models auth order set --provider anthropic anthropic:manual
openclaw gateway restart

Verify the Gateway sees Anthropic auth:

#

openclaw models status

(You should see Anthropic as “effective=…” and it’ll show a redacted key.)

If it still says invalid x-api-key

You almost certainly still have an old/invalid ANTHROPIC_API_KEY being loaded from ~/.openclaw/.env (LaunchAgent service reads that file).

Open it and make sure there’s exactly one correct line (no quotes, no spaces):

open -e ~/.openclaw/.env

Line should look like:

#

ANTHROPIC_API_KEY=sk-ant-...

Save → then:

openclaw gateway restart

If you paste your openclaw models status output (redact anything starting with sk-), I can tell you which source it’s using and why it’s not switching.

rain condor Feb 19, 2026, 6:31 AM

#

when I imput the command: open -e ~/.openclaw/.env
it says "file /users/sj/.openclaw/.env does not exist

#

this was the main issue i was running into, the old anthropic key is like locked in, it won't change

glacial matrixBOT Feb 19, 2026, 6:36 AM

#

That error is totally normal: OpenClaw does not create ~/.openclaw/.env by default. The docs just say it’s a supported fallback location.

1) Create the file (macOS)

mkdir -p ~/.openclaw
touch ~/.openclaw/.env
open -e ~/.openclaw/.env

Then put your new key(s) in there, e.g.

OPENAI_API_KEY=sk-...
XAI_API_KEY=...

Restart the gateway after changing env:

#

openclaw gateway restart

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

2) Important gotcha: `.env` does not override an existing env var

From the FAQ: neither .env overrides env vars already set in your shell/service.

So if you previously put the old key in ~/.zshrc, ~/.bash_profile, etc. (or you exported it in a terminal), OpenClaw will keep seeing the old one.

Quick check in your current terminal:

echo "$OPENAI_API_KEY"

#

If that prints the old key, update/remove it in your shell config (or unset OPENAI_API_KEY and open a fresh terminal), then restart the gateway.

3) If onboarding keeps “remembering” the old key: it’s usually auth profiles (not `.env`)

OpenClaw also stores API keys/OAuth in auth profiles under your state dir (~/.openclaw/.../auth-profiles.json) — so “reinstalling” won’t necessarily clear it.

To see what OpenClaw thinks it has configured, run and paste the output here:

openclaw --version
openclaw models status --plain

If you want to directly replace via the CLI (often easiest), do:

openclaw models auth paste-token --provider openai

#

(paste the new key when prompted)

If you paste openclaw models status --plain here, I can tell you exactly whether it’s pulling the old key from shell env, ~/.openclaw/.env, or auth-profiles.json, and the cleanest way to flip it.

#

Yep — that “locked in” feeling usually means the old Anthropic credential is stored in your auth profiles, not just coming from a .env file… and openclaw reset (the common scopes people run) doesn’t wipe auth-profiles.

Here’s the clean way to replace it (no reinstall needed):

1) Overwrite the stored Anthropic credential

Run this and paste the new Anthropic key when prompted (don’t paste the key in Discord):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default

Then restart:

openclaw gateway restart

#

Docs: https://docs.openclaw.ai/gateway/authentication

2) Verify what OpenClaw is actually using (safe to paste output)

openclaw --version
openclaw models status --plain

That output typically shows which auth-profiles.json it’s reading and which profile it will try next (and it redacts secrets).

3) If it still keeps preferring the old one: clear any per-agent “auth order” pin

Sometimes the agent is pinned to a specific profile order.

#

openclaw models auth order get --provider anthropic
openclaw models auth order clear --provider anthropic
openclaw gateway restart

4) Last resort “wipe it from orbit” (ONLY if you really want a full reset)

Do a dry-run first so you can see what it would delete:

openclaw reset --dry-run --scope full --yes --non-interactive

Full scope removes state (including auth profiles), so it’s destructive.

#

If you paste openclaw --version + openclaw models status --plain here, I can point to the exact place the old key is coming from (env vs auth-profiles vs order override) and the minimal fix.

rain condor Feb 19, 2026, 6:41 AM

#

glacial matrix (paste the new key when prompted) --- If you paste `openclaw models status --p...

show's the correct model

glacial matrixBOT Feb 19, 2026, 6:42 AM

#

If openclaw models status shows the right model, that only confirms model selection is correct — it doesn’t prove the Gateway is actually using the new Anthropic credential.

The two most common reasons it still “feels locked” are:

The Gateway service is running with a different config/state dir than your CLI, so it keeps reading the old auth-profiles.json.
The old ANTHROPIC_API_KEY is still set in your shell/launchd environment, and .env / pasted tokens won’t override it.

Can you run these and paste the output (they redact secrets)?

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

What I’m looking for:

In gateway status: whether Config (cli) and Config (service) differ.

#

In the probe output: which profile id it’s using (e.g. anthropic:default) and whether the probe succeeds.

If gateway status shows different config paths, that’s almost always the “it won’t change” culprit — we’ll fix it by making the service point at the same state/config you’re editing.

Also: are you still seeing a prompt that says something like “use old api key” (and where exactly — openclaw onboard, openclaw configure, the TUI, or the dashboard)? The exact line matters.

rain condor Feb 19, 2026, 6:46 AM

#

version: 2026.2.17
sj@SJs-MacBook-Pro ~ % openclaw gateway status

🦞 OpenClaw 2026.2.17 (4134875) — IPC, but it's your phone.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-18.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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 75476, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
sj@SJs-MacBook-Pro ~ % openclaw models status --plain --prove --prove-provider anthropic

🦞 OpenClaw 2026.2.17 (4134875) — Pairing codes exist because even bots believe in consent—and good security hygiene.

anthropic/claude-3-haiku-20240307

glacial matrixBOT Feb 19, 2026, 6:48 AM

#

Your gateway status looks perfect (CLI + LaunchAgent are using the same ~/.openclaw/openclaw.json, so it’s not a “service is reading a different config” problem).

One thing though: you typo’d the flags — --prove / --prove-provider don’t run a live auth check, so you only ended up printing the model line.

1) Run a real Anthropic auth probe

openclaw models status --plain --probe --probe-provider anthropic

(If you paste the output, it won’t include your key.)

2) Force-replace the exact Anthropic stored credential (most common “locked key” fix)

This overwrites the stored profile that the system usually expects (anthropic:default):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart

#

openclaw models status --plain --probe --probe-provider anthropic --probe-profile anthropic:default

3) If you ever pinned an auth order, clear it (so it stops insisting on the “old” profile id)

openclaw models auth order get --provider anthropic
openclaw models auth order clear --provider anthropic
openclaw gateway restart

If you reply with the output of:

openclaw models status --plain --probe --probe-provider anthropic
openclaw models auth order get --provider anthropic

…I can tell you exactly which profile ID it’s trying first (that’s usually why it feels “stuck”).

rain condor Feb 19, 2026, 6:51 AM

#

ah! so with the correct --probe command, it says "[openclaw] Failed to start CLI: Error: --probe cannot be used with --plain output

glacial matrixBOT Feb 19, 2026, 6:51 AM

#

Yep — that error is expected. --probe and --plain are mutually exclusive (plain mode is “pretty compact output”, probe mode needs a richer format).

Run the probe without --plain:

openclaw models status --probe --probe-provider anthropic

If you want it narrower (only check one profile id):

openclaw models status --probe --probe-provider anthropic --probe-profile anthropic:default

And if you want something pasteable-but-structured, use JSON:

#

openclaw models status --json --probe --probe-provider anthropic

Paste the output (it should redact secrets). That’ll show whether Anthropic auth is actually succeeding, and which auth profile is being tried.

rain condor Feb 19, 2026, 6:53 AM

#

shows two api keys

#

one is default, one is manual

glacial matrixBOT Feb 19, 2026, 6:54 AM

#

If the probe output is showing the old Anthropic key, that means OpenClaw is still reading that credential from somewhere (env var or auth store). The quickest way to pinpoint it is to check the “source=” line.

1) Run this (and paste just the “Auth overview” section)

openclaw models status

In the output, find the Anthropic line — it’ll look like one of these:

source=env: ANTHROPIC_API_KEY ← env var is “winning”
source=profile: anthropic:default (or anthropic:<email>) ← stored in auth-profiles.json

(Everything is redacted, so it’s safe to paste as-is, but don’t paste any raw keys.)

2) Fix depending on what “source=” says

#

A) If it says `source=env: ANTHROPIC_API_KEY`

On macOS LaunchAgents, this is often set via launchctl (or your shell profile).

Check what the service sees:

launchctl getenv ANTHROPIC_API_KEY

If that prints the old key, update/remove it:

launchctl unsetenv ANTHROPIC_API_KEY
# then put the NEW key into ~/.openclaw/.env (recommended for the daemon)
mkdir -p ~/.openclaw
open -e ~/.openclaw/.env

Add:

#

  ANTHROPIC_API_KEY=...new...

Then restart:

openclaw gateway restart

Also make sure you don’t still have the old key in ~/.zshrc, ~/.zprofile, etc.

B) If it says it’s using a `profile:` (auth store)

Overwrite the exact profile id it’s using (example uses anthropic:default):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart

#

If you paste the Auth overview block from openclaw models status, I can tell you exactly which branch you’re in and the minimal change to kill the “old key is locked in” behavior.

#

That explains it: you’ve got two Anthropic auth profiles saved (typically anthropic:default and anthropic:manual). OpenClaw will keep using whichever profile is first in the auth order / rotation, so it can look like the “old key is locked”.

You’ve got two clean options:

Option A (simplest): overwrite the one it keeps picking

If it’s currently using anthropic:default, just replace that profile’s key:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart

(Then re-run openclaw models status --probe --probe-provider anthropic to confirm.)

Option B: tell OpenClaw to prefer the `manual` profile

Set the Anthropic auth order so manual is tried first:

#

openclaw models auth order set --provider anthropic anthropic:manual anthropic:default
openclaw gateway restart

To confirm what it’s currently set to:

openclaw models auth order get --provider anthropic

If you want to remove the old one entirely

Your openclaw models status output shows the exact path to the auth store (usually something like):
~/.openclaw/state/agents/main/agent/auth-profiles.json

You can open that file and delete the old profile entry (make a backup first).

#

If you paste the output of:

openclaw models auth order get --provider anthropic

I can tell you exactly which profile it’s prioritizing right now and what to set it to.

rain condor Feb 19, 2026, 6:58 AM

#

nothing happen when i type launchctl getenv ANTHROPIC_API_KEY

glacial matrixBOT Feb 19, 2026, 6:59 AM

#

That’s actually good news: launchctl getenv ANTHROPIC_API_KEY printing “nothing” usually means it’s not set in launchd’s environment at all (if it were set, it would echo a value).

So the old Anthropic key you’re seeing is almost certainly coming from stored auth profiles (your anthropic:default / anthropic:manual situation), not from launchctl.

Fix (pick one)

Option A: overwrite `anthropic:default` with the new key (fastest)

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart

Option B: keep both, but force OpenClaw to prefer `manual`

openclaw models auth order set --provider anthropic anthropic:manual anthropic:default
openclaw gateway restart

#

To confirm what order it’s using right now:

openclaw models auth order get --provider anthropic

Then verify with a live probe (no `--plain`)

openclaw models status --probe --probe-provider anthropic

If you paste the output of openclaw models auth order get --provider anthropic + the non-secret parts of the probe (it should already redact), I can tell you exactly why it kept picking the old one.

rain condor Feb 19, 2026, 7:03 AM

#

sj@SJs-MacBook-Pro ~ % openclaw models status --probe --probe-provider anthropic

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

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-3-haiku-20240307
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-3-haiku-20240307

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-a...0pkpMQAA, anthropic:manual=token:sk-ant-a...0pkpMQAA | env=sk-ant-a...0pQ_xgAA | source=env: ANTHROPIC_API_KEY
openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | openai:manual=token:Symbol(c...:cancel)

OAuth/token status

anthropic
- anthropic:default static
- anthropic:manual static
openai
- openai:manual static

Auth probes
┌──────────────────────────────────┬──────────────────────────┬───────────────────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────────────────┼──────────────────────────┼───────────────────────────────────────────────────────┤
│ anthropic/claude-3-haiku- │ anthropic:default │ unknown · - │
│ 20240307 │ (token) │ ↳ Excluded by auth.order for this provider. │
│ anthropic/claude-3-haiku- │ anthropic:manual (token) │ ok · 1.5s │
│ 20240307 │

#

here's the ending: ──────────────────────────────────────────────────┘
Probed 1 target in 1.5s
sj@SJs-MacBook-Pro ~ %

glacial matrixBOT Feb 19, 2026, 7:04 AM

#

Your probe output is the smoking gun:

source=env: ANTHROPIC_API_KEY

So OpenClaw is not “locked” to the stored profiles right now — it’s actively pulling Anthropic from an environment variable, which overrides/prefers over the saved anthropic:default/manual tokens.

That’s also why you can see multiple keys at once (2 in profiles + 1 from env).

Step 1: confirm it’s your current terminal env (quick test)

In the same terminal, run:

echo "$ANTHROPIC_API_KEY"

If that prints the old key, then do:

#

Perfect — the key line in your probe is still this:

source=env: ANTHROPIC_API_KEY

So the fix is: stop exporting ANTHROPIC_API_KEY in your environment (or update it), then restart. Right now, even though anthropic:manual probes OK, OpenClaw is still selecting the env key as the “effective” source.

Do this in order:

1) See what your current terminal is exporting

echo "$ANTHROPIC_API_KEY"

2) Temporarily remove it (to confirm the diagnosis)

unset ANTHROPIC_API_KEY

#

openclaw models status --probe --probe-provider anthropic

After this, you should see source=profiles: ... (or similar), not source=env:.

3) Make it permanent (remove the old export from wherever it’s set)

Most common places:

~/.zshrc
~/.zprofile
~/.bash_profile (less common on newer macOS)
~/.openclaw/.env
~/.env (yes, some people have this)

Quick search (safe):

#

grep -RIn "ANTHROPIC_API_KEY" ~/.zshrc ~/.zprofile ~/.bash_profile ~/.bashrc ~/.profile ~/.openclaw/.env ~/.env 2>/dev/null

Edit the file it finds and either delete the old line or replace it with the new key.

4) Restart the gateway

openclaw gateway restart

If you paste the output of the grep ... command (it will show the file path and the line, but please redact the key), I can tell you exactly which file to edit.

#

unset ANTHROPIC_API_KEY
openclaw models status --probe --probe-provider anthropic

After unset, the probe should stop saying source=env: ANTHROPIC_API_KEY and should use the anthropic:manual profile (your probe already shows anthropic:manual … ok).

Step 2: remove where that env var is coming from (so it doesn’t come back)

Common places on macOS:

A .env in your home dir (OpenClaw loads .env from the current working directory):

ls -la ~/.env

If it exists, open it and remove/update ANTHROPIC_API_KEY=....

The OpenClaw fallback env file:

#

ls -la ~/.openclaw/.env

If it exists, open it and update ANTHROPIC_API_KEY=....

Your shell startup files (~/.zshrc, ~/.zprofile, etc.) if you previously added export ANTHROPIC_API_KEY=....

(You don’t need to paste those contents here—just remove the old export.)

Step 3: set the key in the place you actually want

If you want to use the stored profile (recommended), just overwrite manual:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw gateway restart

#

Then verify again:

openclaw models status --probe --probe-provider anthropic

If you tell me whether echo "$ANTHROPIC_API_KEY" shows the old key before you unset it, I can point you to the most likely file it’s coming from (~/.env vs shell config vs ~/.openclaw/.env).

rain condor Feb 19, 2026, 7:13 AM

#

so this is my first time coding, i don't quite understand this:
Quick search (safe):
grep -RIn "ANTHROPIC_API_KEY" ~/.zshrc ~/.zprofile ~/.bash_profile ~/.bashrc ~/.profile ~/.openclaw/.env ~/.env 2>/dev/null

glacial matrixBOT Feb 19, 2026, 7:13 AM

#

No worries — that line is just a “find where you saved the old key” command.

What that command does (in plain English)

It searches a handful of common macOS config files for the text ANTHROPIC_API_KEY.

If you ever added something like:

export ANTHROPIC_API_KEY=sk-ant-...

…this command helps locate which file it’s in.

Copy/paste this into Terminal

grep -RIn "ANTHROPIC_API_KEY" ~/.zshrc ~/.zprofile ~/.bash_profile ~/.bashrc ~/.profile ~/.openclaw/.env ~/.env 2>/dev/null

#

What you’ll see (example)

If it finds it, you’ll get output like:

/Users/sj/.zshrc:12:export ANTHROPIC_API_KEY=sk-ant-...old...

That means: file ~/.zshrc, line 12 contains the key.

If it prints nothing

That means it’s not in those files. (Still could be set somewhere else, but this is the most common spot.)

Next step: edit the file it reports

Example if it said ~/.zshrc:

#

open -e ~/.zshrc

Then:

delete the line that sets ANTHROPIC_API_KEY=... (or replace it with the new key)
save the file
close Terminal and reopen it (important)

Quick check after reopening Terminal

echo "$ANTHROPIC_API_KEY"

If it prints nothing, the old key is no longer being exported by your shell.

(Also: don’t paste any real sk-ant-... keys into Discord—redact them if you share output.)

rain condor Feb 19, 2026, 7:23 AM

#

when i type this in: grep -RIn "ANTHROPIC_API_KEY" ~/.zshrc ~/.zprofile ~/.bash_profile ~/.bashrc ~/.profile ~/.openclaw/.env ~/.env 2>/dev/null

three api key shows up: 2 of the old one and a new one

glacial matrixBOT Feb 19, 2026, 7:26 AM

#

Nice — that grep result is exactly what we needed. It means you’ve set ANTHROPIC_API_KEY in multiple places, and OpenClaw will keep grabbing the old one as long as it’s still present anywhere that gets loaded.

What to do

Goal: make sure the old key appears 0 times, and the new key appears 1 time (ideally in ~/.openclaw/.env).

1) Look at the `grep` output and note the file names

It should look like this (example):

/Users/sj/.zshrc:12:export ANTHROPIC_API_KEY=...
/Users/sj/.openclaw/.env:1:ANTHROPIC_API_KEY=...
/Users/sj/.env:3:ANTHROPIC_API_KEY=...

2) Open each file that showed up and delete the OLD ones

Run these (only the ones that appeared in your output):

#

open -e ~/.zshrc
open -e ~/.zprofile
open -e ~/.env
open -e ~/.openclaw/.env

Then:

Delete the two lines that contain the old key
Keep only one ANTHROPIC_API_KEY=... line total (with the new key)

Strong recommendation: keep the new one in ~/.openclaw/.env and remove it from ~/.zshrc / ~/.zprofile / ~/.env to avoid this happening again.

3) Restart things so changes take effect

Close Terminal completely and open a new Terminal window (important on macOS).
Restart the gateway:

#

openclaw gateway restart

4) Verify

openclaw models status --probe --probe-provider anthropic

You should no longer see it using the old key.

If you paste the grep output but redact the keys (leave just the file paths + line numbers), I can tell you exactly which one to keep and which two to delete.

rain condor Feb 19, 2026, 7:39 AM

#

so it now doesn't show the old key anymore

#

however, telegram still sayd http 401 invalid x-api-key

glacial matrixBOT Feb 19, 2026, 7:40 AM

#

Awesome — that means you successfully removed the old ANTHROPIC_API_KEY sources and OpenClaw is no longer picking it up.

To fully confirm you’re “clean”:

In a fresh terminal, make sure your shell isn’t exporting the old key:

echo "$ANTHROPIC_API_KEY"

It should be either empty (if you moved it into auth profiles) or show the new one.

Confirm OpenClaw’s effective auth source + probe:

openclaw models status --probe --probe-provider anthropic

You want to see either:

source=env: ANTHROPIC_API_KEY (and it’s the new key), or
source=profiles: ... and the probe is ok.

#

If this fixed your loop, please mark the message that helped as the solution (right‑click it → Apps → ✅ Mark Solution). That helps Answer Overflow index it for the next person.

#

That HTTP 401 invalid x-api-key is Anthropic rejecting the key (Telegram is just where you see the error).

From the probe output you pasted earlier, the important part was:

source=env: ANTHROPIC_API_KEY

So OpenClaw is currently using the environment variable ANTHROPIC_API_KEY (not necessarily the anthropic:manual profile you probed as “ok”). If the env-var key is wrong/typo’d/revoked, you’ll get exactly that 401.

Fix: stop using the env var, and use the working profile instead

Open your OpenClaw env file:

open -e ~/.openclaw/.env

Delete the entire line that starts with:

#

ANTHROPIC_API_KEY=

(save the file)

Restart the gateway:

openclaw gateway restart

Re-check:

openclaw models status --probe --probe-provider anthropic

Now it should no longer say source=env: ANTHROPIC_API_KEY — it should say it’s using profiles, and the probe should be ok.

#

If you want the NEW key to be used (recommended way)

Instead of env vars, paste it into the profile OpenClaw is already using:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw gateway restart

Then test Telegram again.

If after removing ANTHROPIC_API_KEY you still get 401, paste the new models status --probe --probe-provider anthropic output and we’ll see which profile it’s actually trying.

rain condor Feb 19, 2026, 7:48 AM

#

sj@SJs-MacBook-Pro ~ % openclaw models status --probe --probe-provider anthropic

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

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-3-haiku-20240307
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-3-haiku-20240307

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-a...0pkpMQAA, anthropic:manual=token:sk-ant-a...0pkpMQAA
openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | openai:manual=token:Symbol(c...:cancel)

OAuth/token status

anthropic
- anthropic:default static
- anthropic:manual static
openai
- openai:manual static

Auth probes
┌──────────────────────────────────┬──────────────────────────┬───────────────────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────────────────┼──────────────────────────┼───────────────────────────────────────────────────────┤
│ anthropic/claude-3-haiku- │ anthropic:default │ unknown · - │
│ 20240307 │ (token) │ ↳ Excluded by auth.order for this provider. │
│ anthropic/claude-3-haiku- │ anthropic:manual (token) │ ok · 1.6s │
│ 20240307 │ │ │

glacial matrixBOT Feb 19, 2026, 7:50 AM

#

Good news: that probe output shows Anthropic auth is working now:

anthropic:manual … ok
anthropic:default … excluded by auth.order

So OpenClaw can talk to Anthropic with the current config.

If Telegram is still showing HTTP 401 invalid x-api-key, it usually means one of these is true:

You’re looking at an older error (from before the fix), or
Telegram messages are being handled by a different agent/gateway than the one you just probed, or
The Gateway needs a restart / the Telegram session is pinned to something weird.

Do this exact repro + capture

Restart the Gateway service:

#

openclaw gateway restart

Start watching logs:

openclaw logs --follow --plain

From Telegram, send:

/new
then a simple: hi

When the error happens, copy/paste the log lines around the 401 here (redact any sk-... just in case, but usually logs are safe/redacted).

Also run this and paste output

This checks whether Telegram itself is connected OK:

#

openclaw channels status --probe

That will let us answer: “Is Telegram failing to connect?” vs “Telegram is fine, but the model call is failing (Anthropic 401) and why.”

If you want, paste the exact Telegram message you see (just the error text, no keys).

rain condor Feb 19, 2026, 7:55 AM

#

HTTP 401 authenticatoin_error: invalid x-api-key (request_id:req_011CYH4onSkFdyC3ABrjXMeF)

glacial matrixBOT Feb 19, 2026, 7:59 AM

#

That error text is coming from Anthropic (not Telegram): it means the Anthropic key that was used for that specific request was rejected.

But your local probe shows anthropic:manual is OK, so one of these is happening:

1) Telegram is being handled by a different OpenClaw instance (most common)

Easiest way to verify:

In Terminal, start log follow:
```
openclaw logs --follow --plain
```
Then send a fresh message from Telegram (e.g. /new then hi).

What to look for

If you see the Telegram inbound + the Anthropic request in the logs on this Mac: great — it’s this instance, we can fix it by reading the log context.
If you see nothing in the logs when you message Telegram: your Telegram bot is connected to some other OpenClaw you ran earlier (or another machine), and that one still has the bad key. You’ll need to stop the other instance or re-point Telegram to this one.

#

To check what this Mac thinks is configured for channels:

openclaw channels status --probe
openclaw channels list

2) Telegram is routed to a different agent with different credentials

If you have multi-agent routing, Telegram might not be using the same agent you just probed.

Run:

openclaw channels list --json

and look for Telegram’s agentId. Then run:

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

#

3) Safety net: update BOTH Anthropic profiles (so nothing can accidentally use the “wrong one”)

Even though default is excluded by auth.order, I’d still overwrite both so it can’t bite you later:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart

If you paste:

the output of openclaw channels status --probe and
the few log lines around req_011CYH4onSkFdyC3ABrjXMeF

…I can tell you which of the 3 cases you’re in immediately.

rain condor Feb 19, 2026, 8:00 AM

#

how do i stop the previous log? it's still running

#

in terminal

#

when i type ctrl + c twice, it shows: bash-3.2$

glacial matrixBOT Feb 19, 2026, 8:01 AM

#

If you ran:

openclaw logs --follow --plain

…it will keep streaming until you stop it.

Stop it (normal way)

In that same Terminal window/tab, press:

Ctrl + C

That should return you to your normal shell prompt (sj@... %).

If Ctrl+C doesn’t work

Click into the Terminal so it has focus, then try Ctrl + C again.

#

Yep — in the Terminal window where it’s streaming, just press:

Control + C (hold Control, tap C)

That stops the openclaw logs --follow ... command and returns you to the normal prompt.

If it doesn’t stop:

Click inside the Terminal window first (so it has focus), then try Ctrl+C again.
Worst case, close that Terminal tab/window — it only stops the log streaming, not OpenClaw itself.

#

Or just close that Terminal tab/window.

Last resort (kill just the log follower)

In a new terminal tab:

ps aux | grep "openclaw logs" | grep -v grep

Copy the PID number from the left, then:

kill <PID>

(That kills the log tail, not the gateway service.)

#

Yep — that means you successfully stopped the log follower.

bash-3.2$ is just your shell prompt (you’re currently in a Bash shell). You can either:

keep going from there (totally fine), or
go back to your normal macOS shell by typing:
```
exit
```
(you might need to type exit once or twice)

For the Telegram HTTP 401 … invalid x-api-key next:

In Telegram, send:

/new

#

then hi

Sometimes the Telegram chat session is “stuck” using an old pinned auth/model, and /new clears that.

If it still errors, grab the last ~200 log lines right after it happens:

openclaw logs --plain --limit 200

Paste those lines here (they should be redacted—just don’t paste any sk-... values if you see them). That’ll show which Anthropic profile/key it actually used for the failing request.

rain condor Feb 19, 2026, 8:09 AM

#

Log file: /tmp/openclaw/openclaw-2026-02-19.log
2026-02-19T08:00:02.257Z error Gateway failed to start: gateway already running (pid 75872); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
2026-02-19T08:00:02.326Z error Port 18789 is already in use.
2026-02-19T08:00:02.327Z error - pid 75872 sj: openclaw-gateway (127.0.0.1:18789)
2026-02-19T08:00:02.327Z error - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
2026-02-19T08:00:02.334Z error Gateway service appears loaded. Stop it first.
2026-02-19T08:00:02.334Z error Tip: openclaw gateway stop
2026-02-19T08:00:02.335Z error Or: launchctl bootout gui/$UID/ai.openclaw.gateway
2026-02-19T08:00:13.233Z error Gateway failed to start: gateway already running (pid 75872); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
2026-02-19T08:00:13.292Z error Port 18789 is already in use.
2026-02-19T08:00:13.293Z error - pid 75872 sj: openclaw-gateway (127.0.0.1:18789)
2026-02-19T08:00:13.293Z error - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
2026-02-19T08:00:13.298Z error Gateway service appears loaded. Stop it first.
2026-02-19T08:00:13.298Z error Tip: openclaw gateway stop
2026-02-19T08:00:13.299Z error Or: launchctl bootout gui/$UID/ai.openclaw.gateway
2026-02-19T08:00:24.178Z error Gateway failed to start: gateway already running (pid 75872); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
2026-02-19T08:00:24.235Z error Port 18789 is already in use.
2026-02-19T08:00:24.235Z error - pid 75872 sj: openclaw-gateway (127.0.0.1:18789)
2026-02-19T08:00:24.236Z error - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
2026-02-19T08:00:24.240Z error Gateway service

glacial matrixBOT Feb 19, 2026, 8:11 AM

#

That probe output means your Anthropic auth on this Mac is fine right now (anthropic:manual = ok). So if Telegram still shows:

HTTP 401 authentication_error: invalid x-api-key …

…then almost always it’s one of these:

Telegram is still talking to a different OpenClaw instance (old gateway still polling your bot), or
You’re seeing an old cached error message in Telegram from before the fix, or
Telegram is routed to a different agent/profile (less common).

Let’s confirm which one in the simplest way:

Step 1 — Check if THIS gateway is the one handling Telegram

Run:

openclaw channels status --probe

#

You should see Telegram in there and it should look healthy/connected. If Telegram is missing or unhealthy, then Telegram messages are going somewhere else.

Step 2 — Prove it with logs (quick)

Start log follow:
```
openclaw logs --follow --plain
```
Immediately send in Telegram:
- /new
- then hi
Watch the terminal:
- If you see Telegram inbound lines (and/or the Anthropic 401) → it’s this gateway.
- If you see nothing at all when you message Telegram → Telegram is being handled by another OpenClaw process/machine still running with the old key.

Stop the follow with Ctrl+C once you’ve captured it.

If it’s another gateway

#

The log snippet you pasted earlier (gateway already running, port 18789 already in use) suggests you’ve accidentally tried to start a second gateway locally. That’s fine — but it also means it’s possible you have another OpenClaw running elsewhere (or another profile) still connected to Telegram.

Reply with the output of openclaw channels status --probe and tell me whether openclaw logs --follow --plain shows anything when you send hi from Telegram, and I’ll tell you the exact next step.

rain condor Feb 19, 2026, 8:14 AM

#

it says telegram default: enabled, configured, running, in:19m ago, out:9m ago...

glacial matrixBOT Feb 19, 2026, 8:17 AM

#

If Telegram shows HTTP 401 … invalid x-api-key, that means some OpenClaw process is still sending Anthropic requests with a bad key.

But your Anthropic probe is OK (anthropic:manual … ok), so the most likely explanation is:

Telegram is routed to a different agent (with a different auth store / old key)

Let’s confirm which agent Telegram is using.

Run this and paste the output:

openclaw channels list
openclaw agents list

In channels list, look for the telegram entry and see what agentId it’s bound to (might be main, might be something else).

Then probe Anthropic for that agent:

#

openclaw models status --agent <agentId-from-telegram> --probe --probe-provider anthropic

If that probe fails / shows the old key, we just need to update the Anthropic token for that agent:

openclaw models auth paste-token --agent <agentId-from-telegram> --provider anthropic --profile-id anthropic:manual
openclaw gateway restart

Why I’m confident this is the issue

Your current probe output shows it’s using auth profiles from:

~/.openclaw/agents/main/agent/auth-profiles.json

#

If Telegram is using a different agent, it will read a different file (and can still have the old key).

Paste openclaw channels list and I’ll tell you exactly which --agent ... to use.

rain condor Feb 19, 2026, 8:42 AM

#

sj@SJs-MacBook-Pro ~ % openclaw channels list

🦞 OpenClaw 2026.2.17 (4134875) — IPC, but it's your phone.

Chat channels:

Telegram default: configured, token=config, enabled

Auth providers (OAuth + API keys):

anthropic:default (token)
openai:manual (token)
anthropic:manual (token)

│
◇
Usage:
Claude: HTTP 401: Invalid bearer token

Docs: gateway/configuration
sj@SJs-MacBook-Pro ~ % openclaw agents list

🦞 OpenClaw 2026.2.17 (4134875) — End-to-end encrypted, drama-to-drama excluded.

Agents:

main (default)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Model: anthropic/claude-3-haiku-20240307
Routing rules: 0
Routing: default (no explicit rules)
Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
Channel status reflects local config/creds. For live health: openclaw channels status --probe.

glacial matrixBOT Feb 19, 2026, 8:45 AM

#

Got it — and thanks for pasting channels list / agents list. You only have one agent (main), so it’s not a routing-to-a-different-agent problem.

The remaining “Telegram says HTTP 401 … invalid x-api-key” usually comes down to one of these two:

The key stored in your Anthropic profiles is still the old/bad one (even though it looks similar when redacted), or
You have another OpenClaw running somewhere with the Telegram bot token, and that instance is replying with the bad key.

Let’s do the easiest “can’t fail” fix first.

Step 1: Overwrite BOTH Anthropic profiles with the new key

Run these two commands (it will prompt you to paste the key each time):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:manual
openclaw models auth paste-token --provider anthropic --profile-id anthropic:default

#

Then restart:

openclaw gateway restart

Then verify:

openclaw models status --probe --probe-provider anthropic

(You want to see the probe ok for anthropic:manual again.)

Step 2: Test Telegram with a fresh session

In Telegram send:

/new
then hi

#

If it still replies with invalid x-api-key, then it’s almost certainly another OpenClaw instance replying.

Quick check for multiple gateways on this Mac

Run:

ps aux | grep -E "openclaw.*gateway|openclaw-gateway" | grep -v grep

If you see more than one gateway-ish process, paste that output (no secrets in it), and we’ll stop the extra one.

Also: the line you saw in openclaw channels list:

Usage: Claude: HTTP 401: Invalid bearer token

…is a separate “usage snapshot” thing and can be ignored for now (you can hide it with openclaw channels list --no-usage). The Telegram x-api-key error is the important one.

rain condor Feb 19, 2026, 8:52 AM

#

so yeah, there's two gateways:
sj@SJs-MacBook-Pro ~ % ps aux | grep -E "openclaw.*gateway|openclaw-gateway" | grep -v grep
sj 98040 2.9 1.7 446475872 284848 ?? S 12:51AM 0:01.07 openclaw-gateway
sj 75872 0.0 1.9 457052208 323136 ?? Ss 11:00PM 0:30.72 openclaw-gateway

glacial matrixBOT Feb 19, 2026, 8:52 AM

#

Yep — that’ll do it. Two gateways can both try to handle Telegram, and the “wrong” one (with the old/bad Anthropic key) will keep replying with the 401.

Let’s get you down to one gateway.

1) See which PID is the LaunchAgent/service one

Run:

openclaw gateway status

It will show something like: Runtime: running (pid XXXXX).

Compare that PID to the two you found:

98040
75872

2) Kill the other one (the extra gateway)

If openclaw gateway status shows the service is PID 75872, then kill 98040:

#

kill 98040

If it doesn’t disappear after ~5 seconds:

kill -9 98040

(If the service PID is 98040, then kill 75872 instead.)

Verify only one remains:

ps aux | grep -E "openclaw.*gateway|openclaw-gateway" | grep -v grep

3) Restart the remaining gateway (clean state)

#

openclaw gateway restart

4) Re-test Anthropic + Telegram

openclaw models status --probe --probe-provider anthropic

Then in Telegram:

/new
hi

If you tell me which PID openclaw gateway status reports, I can tell you exactly which one to kill.

rain condor Feb 19, 2026, 8:55 AM

#

sj@SJs-MacBook-Pro ~ % openclaw gateway status

🦞 OpenClaw 2026.2.17 (4134875) — The only crab in your contacts you actually want to hear from. 🦞

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-19.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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: stopped (state active)
RPC probe: ok

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-02-19.log
Launchd stdout (if installed): /Users/sj/.openclaw/logs/gateway.log
Launchd stderr (if installed): /Users/sj/.openclaw/logs/gateway.err.log

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

glacial matrixBOT Feb 19, 2026, 8:55 AM

#

That output is the giveaway:

LaunchAgent says “Runtime: stopped” (the service process exited)
but RPC probe: ok + Listening 127.0.0.1:18789 means some other gateway process is still running and answering on that port.

So the LaunchAgent can’t start (or immediately exits) because the port is already taken by the “other” gateway.

Fix: stop everything, then start only the LaunchAgent gateway

Stop the LaunchAgent (safe even if it’s already stopped):

openclaw gateway stop

Kill the two leftover gateway processes you found:

#

kill 98040 75872

If one refuses to die after ~5 seconds:

kill -9 98040 75872

Confirm nothing is listening on the gateway port anymore:

lsof -nP -iTCP:18789 -sTCP:LISTEN

That should print nothing.

Start the LaunchAgent cleanly:

#

openclaw gateway start

Verify:

openclaw gateway status

Now it should say Runtime: running (pid …) and RPC probe ok.

Then re-test Anthropic + Telegram

openclaw models status --probe --probe-provider anthropic

…and send /new then hi in Telegram.

Going forward: if you have the service installed, avoid running openclaw gateway run in another terminal — that’s the usual way people accidentally end up with two gateways.

rain condor Feb 19, 2026, 8:57 AM

#

after typing kill it says:
bash: kill: (98040) - no such process

glacial matrixBOT Feb 19, 2026, 8:57 AM

#

That’s fine — it just means PID 98040 was already gone by the time you ran kill. Good.

Now we just need to find (and stop) whatever is still listening on port 18789, because that’s what’s preventing the LaunchAgent from running cleanly.

1) See what’s still running / listening

Run:

ps aux | grep -E "openclaw.*gateway|openclaw-gateway" | grep -v grep
lsof -nP -iTCP:18789 -sTCP:LISTEN

ps ... shows any leftover gateway processes.
lsof ... shows the exact PID currently holding port 18789.

2) Kill the PID that `lsof` shows

If lsof shows something like PID 75872, then:

#

kill 75872

If it still shows up after a few seconds, force it:

kill -9 75872

3) Start the gateway service cleanly

openclaw gateway start
openclaw gateway status

Once gateway status says Runtime: running (pid …) (not “stopped”), try Telegram again (/new then hi).

#

If you paste the output of the lsof ... command, I can tell you exactly which PID to kill.

rain condor Feb 19, 2026, 8:59 AM

#

nothing shows up, after that ps aux command

glacial matrixBOT Feb 19, 2026, 8:59 AM

#

If ps aux | grep ... shows nothing, that usually means you successfully killed the extra gateways. Now we just need to confirm whether anything is still listening on port 18789, and then start the LaunchAgent cleanly.

1) Check if anything is listening on 18789

Run this and tell me if it prints anything (or paste the output):

lsof -nP -iTCP:18789 -sTCP:LISTEN

If it prints nothing → the port is free. Go to step 2.
If it prints a line with a PID → that PID is still holding the port; we’ll kill that PID.

2) Start the LaunchAgent gateway (the “one true” gateway)

openclaw gateway start
openclaw gateway status

#

You want gateway status to say Runtime: running (pid …) (not “stopped”).

3) If it still says “stopped” right after starting

Grab the error log (this is usually the reason it exited):

tail -n 80 ~/.openclaw/logs/gateway.err.log

Paste that tail here.

Also: once you have the LaunchAgent running, don’t start another one with openclaw gateway run in a terminal—use openclaw gateway restart instead.

rain condor Feb 19, 2026, 9:01 AM

#

ok so obviously i have to leave bash right? how do i do that?

glacial matrixBOT Feb 19, 2026, 9:01 AM

#

Yep — you’re just inside a Bash shell (bash-3.2$). To leave it:

Exit bash

Type:

exit

and press Enter.

If it still shows another prompt that isn’t your normal sj@SJs-MacBook-Pro ~ %, type exit again.

Shortcut

You can also press Ctrl + D (that exits the current shell).

Once you’re back at your normal prompt (usually ends with % on macOS), run:

#

openclaw gateway start
openclaw gateway status

rain condor Feb 19, 2026, 9:02 AM

#

it says gateway service no loaded

glacial matrixBOT Feb 19, 2026, 9:03 AM

#

“Gateway service not loaded” just means the background daemon (LaunchAgent) isn’t installed/loaded right now (so Telegram won’t be reliably online).

On macOS, fix is:

1) Install (or reinstall) the LaunchAgent

openclaw gateway install --force

2) Start it

openclaw gateway start

3) Verify it’s actually running

#

openclaw gateway status

You want to see Service: LaunchAgent (loaded) and Runtime: running (pid …).

If you want a quick “just run it now” (no service)

This runs in the foreground (but you must keep the terminal open):

openclaw gateway run

Important: don’t run gateway run and the LaunchAgent at the same time, or you’ll end up with the “two gateways / port 18789 in use” situation again.

Once it’s running, try Telegram again (/new then hi). If you still see the 401, paste openclaw models status --probe --probe-provider anthropic and we’ll trace which key it’s actually using.

rain condor Feb 19, 2026, 9:05 AM

#

bash-3.2$ openclaw gateway status

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

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-19.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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 99231, state active)
RPC probe: ok

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

#

also

glacial matrixBOT Feb 19, 2026, 9:06 AM

#

Nice — you’re good now:

LaunchAgent loaded
Runtime running (pid 99231)
RPC probe ok
Listening on 127.0.0.1:18789

So you’re back to one healthy gateway.

Two quick notes:

You’re still in bash-3.2$ (that’s fine), but if you want to go back to your normal macOS prompt, type:

exit

Now re-test Telegram cleanly:

#

In Telegram send: /new
then: hi

If you still get HTTP 401 invalid x-api-key, run this right after it happens and paste the relevant lines:

openclaw logs --plain --limit 200

Also re-run the Anthropic probe once (just to be sure the running gateway is using the right auth):

openclaw models status --probe --probe-provider anthropic

#

What’s the “also” part—are you still getting the Telegram HTTP 401 invalid x-api-key, or is it something different now?

If it’s still the 401, do these two checks (and paste outputs):

Re-probe Anthropic (no secrets):

openclaw models status --probe --probe-provider anthropic

Trigger the error once in Telegram (/new then hi), then grab logs:

openclaw logs --plain --limit 200

If it’s not about Telegram: tell me what message/error you’re seeing and where (Terminal / Telegram / Dashboard).

rain condor Feb 19, 2026, 9:10 AM

#

sj@SJs-MacBook-Pro ~ % openclaw models status --probe -- probe-provider anthropic

🦞 OpenClaw 2026.2.17 (4134875) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-3-haiku-20240307
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-3-haiku-20240307

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-a...0pkpMQAA, anthropic:manual=token:sk-ant-a...0pkpMQAA
openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | openai:manual=token:Symbol(c...:cancel)

OAuth/token status

anthropic
- anthropic:default static
- anthropic:manual static
openai
- openai:manual static

Auth probes
┌──────────────────────────────────┬──────────────────────────┬───────────────────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────────────────┼──────────────────────────┼───────────────────────────────────────────────────────┤
│ anthropic/claude-3-haiku- │ anthropic:default │ unknown · - │
│ 20240307 │ (token) │ ↳ Excluded by auth.order for this provider. │
│ anthropic/claude-3-haiku- │ anthropic:manual (token) │ ok · 1.4s │
│ 20240307 │ │ │

glacial matrixBOT Feb 19, 2026, 9:11 AM

#

That output looks good now:

anthropic:manual (token) │ ok
and it’s using profiles (not ANTHROPIC_API_KEY env)

So Anthropic auth on this gateway is working.

Next: confirm you only have ONE gateway process now

Run:

ps aux | grep openclaw-gateway | grep -v grep

You should see one line.

Then re-test Telegram with a fresh session

In Telegram send:

/new

#

hi

If it still replies with HTTP 401 … invalid x-api-key, grab the gateway logs right after it happens:

openclaw logs --plain --limit 200

Paste the chunk around the 401 (you can omit unrelated lines). That will tell us which profile it actually used for the failing request.

One more small thing: earlier you typed -- probe-provider with a space — the correct flag is:

openclaw models status --probe --probe-provider anthropic

rain condor Feb 19, 2026, 9:12 AM

#

ok can't send you the message for the log

glacial matrixBOT Feb 19, 2026, 9:13 AM

#

No problem — Discord has a pretty tight message limit (and big log dumps often won’t paste).

Easiest: paste only the few lines that matter

Trigger the error again in Telegram so you get a fresh request_id:req_....
Then in Terminal run (replace the request id with yours):

openclaw logs --plain --limit 800 | grep "req_011CYH4onSkFdyC3ABrjXMeF"

If that prints nothing (maybe it rotated out), do:

openclaw logs --plain --limit 800 | egrep -i "telegram|anthropic|x-api-key|authentication_error|req_" | tail -n 80

#

Then paste just those results (should be short enough).

While we’re here: quickest “just make it stop 401’ing” fix

Even though anthropic:manual probes OK, Telegram might be pinned to anthropic:default from an older session.

So do both:

In Telegram: send /new (then hi).
In Terminal: overwrite the default profile too (so even if something uses it, it won’t be bad):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart

#

(Do not paste the key into Discord—only into the Terminal prompt.)

If you paste the short grep output (or just tell me the new request_id:req_...), I can tell you exactly which profile/key was used for the failing request.

rain condor Feb 19, 2026, 9:13 AM

#

where do i find request id? (Then in Terminal run (replace the request id with yours):

glacial matrixBOT Feb 19, 2026, 9:14 AM

#

The request id is in the Telegram error message itself — it’s the part that looks like:

request_id:req_...

Example you pasted earlier:
request_id:req_011CYH4onSkFdyC3ABrjXMeF

So:

In Telegram, send /new then hi (to reproduce the error).
Copy the error text and look for request_id:req_...
Copy just that req_... string.

If Telegram doesn’t show the request id (sometimes it won’t), you can pull it from logs directly:

#

openclaw logs --plain --limit 800 | egrep -o "req_[A-Za-z0-9]+" | tail -n 20

That prints the most recent Anthropic request ids seen in the gateway logs.

Then you can search logs for the specific one:

openclaw logs --plain --limit 800 | grep "req_XXXXXXXX"

rain condor Feb 19, 2026, 9:15 AM

#

thank you, i'll resume this tomorrow

glacial matrixBOT Feb 19, 2026, 9:16 AM

#

Sounds good.

When you pick it up tomorrow, quickest path is:

In Telegram: /new then hi (to reproduce)
Grab the request_id:req_... from the error (or run the egrep -o "req_..." command from logs)
Then run:

openclaw logs --plain --limit 800 | grep "req_..."

If the 401 is still happening, we’ll use that to see exactly which Anthropic profile/key it’s using and fix it.

If this thread helped so far, feel free to mark the helpful message as the solution (right‑click → Apps → ✅ Mark Solution) so others can find it later.

rain condor Feb 21, 2026, 4:30 AM

#

still show 401 authantication_error: invalid x-api-key

glacial matrixBOT Feb 21, 2026, 4:34 AM

#

That 401 authentication_error: invalid x-api-key is coming from the xAI provider — OpenClaw is still sending an old / wrong xAI key somewhere.

Key detail: for xAI, the built-in provider is xai and it authenticates via XAI_API_KEY.
Docs: https://docs.openclaw.ai/concepts/model-providers (see “xAI: xai (XAI_API_KEY)”)

Why “reset” didn’t fix it

openclaw reset resets OpenClaw state, but it does not magically change whatever your shell / service environment is still exporting. If XAI_API_KEY is still set to the old value, the wizard will keep “finding” it and offering to reuse it.

Fix checklist (do this on the gateway host, not your laptop if the gateway is remote)

Verify what xAI sees (redact secrets):

openclaw --version
openclaw models status --probe-provider xai

Update the xAI key in the place the Gateway actually reads it from:

#

Option A (recommended): store it via OpenClaw auth profiles

openclaw models auth paste-token --provider xai

(paste the new key when prompted)

Option B: if you’re using env vars / daemon env

Check if you still have an old key in your shell:
```
echo "$XAI_API_KEY"
```
And check the daemon env file too:
```
rg "XAI_API_KEY" ~/.openclaw/.env || true
```
Update that value to the new key.

#

Restart the gateway so it actually picks up the new key:

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

If it still loops

Paste the output of:

openclaw models status --probe-provider xai --plain
openclaw gateway status

(please redact any key/token values)

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

rain condor Feb 21, 2026, 4:36 AM

#

is it because openai is key is still here?

sj@SJs-MacBook-Pro ~ % openclaw models status --probe-provider xai

🦞 OpenClaw 2026.2.17 (4134875) — One CLI to rule them all, and one more restart because you changed the port.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-3-haiku-20240307
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-3-haiku-20240307

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-a...0pkpMQAA, anthropic:manual=token:sk-ant-a...0pkpMQAA
openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | openai:manual=token:Symbol(c...:cancel)

OAuth/token status

anthropic
- anthropic:default static
- anthropic:manual static
openai
- openai:manual static

glacial matrixBOT Feb 21, 2026, 4:38 AM

#

No — an OpenAI key sitting in your auth store won’t cause an xAI error like invalid x-api-key.

In the output you pasted, OpenClaw isn’t even configured to use xAI right now:

Default model is anthropic/claude-3-haiku-20240307
No xai provider shows up in “Auth overview” (only anthropic + openai profiles are present)
Fallbacks (0)

So if you’re still seeing 401 ... invalid x-api-key, it’s almost certainly one of these:

Your Gateway service is running with a different config/state than the CLI
- Run and paste:
```
openclaw gateway status
```
Check whether it shows Config (cli) and Config (service) pointing to different places.

#

xAI key is coming from the daemon env (~/.openclaw/.env) and it’s stale
Your models status shows Shell env: off, which is normal for a service — it won’t see env vars you exported in your terminal. Keys must live in ~/.openclaw/.env (or be stored in auth profiles).
Quick redacted check:
```
rg -n '^XAI_API_KEY=' ~/.openclaw/.env 2>/dev/null | sed 's/=.*/=<redacted>/'
```

If you do want to use xAI (Grok) now

On the gateway host:

openclaw models auth paste-token --provider xai
openclaw gateway restart

Then re-check:

#

openclaw models status --probe-provider xai

Next thing I need from you

Paste:

openclaw gateway status
openclaw logs --follow

…and then reproduce the error once (so the log shows which provider/URL is throwing invalid x-api-key). That will tell us exactly where the stale key is coming from.

rain condor Feb 21, 2026, 4:44 AM

#

i don't want to use xAI, and this is the gateway status
sj@SJs-MacBook-Pro ~ % openclaw gateway status

🦞 OpenClaw 2026.2.17 (4134875) — The UNIX philosophy meets your DMs.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-20.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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 99231, state active)
RPC probe: ok

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

#

here's the log:

#

sj@SJs-MacBook-Pro ~ % openclaw logs --follow

🦞 OpenClaw 2026.2.17 (4134875) — Think different. Actually think.

Log file: /tmp/openclaw/openclaw-2026-02-20.log
04:35:02 info 2026.2.17
04:39:16 info Service: LaunchAgent (loaded)
04:39:16 info File logs: /tmp/openclaw/openclaw-2026-02-20.log
04:39:16 info Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
04:39:16 info Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
04:39:16 info Service env: OPENCLAW_GATEWAY_PORT=18789
04:39:16 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-02-21T04:39:16.458Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048:46","fileName":"entry.js","fileNameWithLine":"entry.js:2048","fileColumn":"46","fileLine":"2048","filePath":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048","method":"console.log"}},"time":"2026-02-21T04:39:16.458Z"}
04:39:16 info Config (cli): ~/.openclaw/openclaw.json
04:39:16 info Config (service): ~/.openclaw/openclaw.json
04:39:16 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-02-21T04:39:16.459Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048:46","fileName":"entry.js","fileNameWithLine":"entry.js:2048","fileColumn":"46","fileLine":"2048","filePath":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048","method":"console.log"}},"time":"2026-02-21T04:39:16.459Z"}
04:39:16 info Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
04:39:16 info Probe target: ws://127.0.0.1:18789
04:39:16 info Dashboard:

#

04:39:16 info Probe note: Loopback-only gateway; only local clients can connect.
04:39:16 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-02-21T04:39:16.459Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048:46","fileName":"entry.js","fileNameWithLine":"entry.js:2048","fileColumn":"46","fileLine":"2048","filePath":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048","method":"console.log"}},"time":"2026-02-21T04:39:16.459Z"}
04:39:16 info Runtime: running (pid 99231, state active)
04:39:16 info RPC probe: ok
04:39:16 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-02-21T04:39:16.460Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048:46","fileName":"entry.js","fileNameWithLine":"entry.js:2048","fileColumn":"46","fileLine":"2048","filePath":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js:2048","method":"console.log"}},"time":"2026-02-21T04:39:16.460Z"}
04:39:16 info Listening: 127.0.0.1:18789
04:39:16 info Troubles: run openclaw status
04:39:16 info Troubleshooting: https://docs.openclaw.ai/troubleshooting

glacial matrixBOT Feb 21, 2026, 4:50 AM

#

I don’t see the log content in your message (looks like it didn’t paste). Can you paste it again?

Best way (so we get the right clues, with secrets auto-redacted):

Paste this whole command output (it’s safe to share — tokens are redacted):

openclaw status --all

Paste this too (shows whether the service is using a different config than your CLI):

openclaw gateway status

Then grab the ~20–50 lines around the 401 invalid x-api-key from:

#

openclaw logs --follow

(you can Ctrl+C once you see the error, then paste the relevant chunk)

If the log is massive, just paste the section that includes:

the 401 line
any line right above it mentioning provider (xai/openai/etc) or base URL
any “using config…” / “auth profile…” lines nearby

Once I can see those lines, I can tell you exactly where the stale xAI key is coming from (service env vs auth-profiles vs different state dir/profile).

rain condor Feb 21, 2026, 4:58 AM

#

i removed the message and paste the second half of the log

#

sj@SJs-MacBook-Pro ~ % openclaw status --all

🦞 OpenClaw 2026.2.17 (4134875) — I read logs so you can keep pretending you don't have to.

│
OpenClaw status --all

Overview
┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.2.17 │
│ OS │ macos 26.2 (arm64) │
│ Node │ 22.22.0 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default)

#

│
│ Update │ pnpm · npm update 2026.2.19-2 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 23ms · auth token │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ SJs-MacBook-Pro.local (192.168.43.72) app 2026.2.17 macos 26.2 │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 99231) │
│ Node service │ LaunchAgent not installed │
│ Agents │ 1 total · 1 bootstrapping · 0 active · 1 sessions │
└─────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config (sha256:e5517339 · len 46) · accounts 1/1 │
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────┘

#

Telegram accounts
┌──────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config │
└──────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────────────┘

Agents
┌────────────┬───────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap │ Sessions │ Active │ Store │
├────────────┼───────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────┤
│ main │ PENDING │ 1 │ 44h ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴───────────┴──────────┴──────────┴──────────────────────────────────────────────────────────────────────┘

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/sj/.openclaw/openclaw.json
Bind: loopback

✓ Config: /Users/sj/.openclaw/openclaw.json
✓ Restart sentinel: none

Gateway last log line:
2026-02-21T04:28:49.639Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
! Port 18789
Port 18789 is already in use.

pid 99231 sj: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
error: Error: spawn tailscale ENOENT
✓ Skills: 6 eligible · 0 missing · /Users/sj/.openclaw/workspace

#

Gateway logs (tail, summarized): /Users/sj/.openclaw/logs

stderr: /Users/sj/.openclaw/logs/gateway.err.log

2026-02-20T09:15:18.526Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T09:38:11.564Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T10:11:34.524Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T10:44:09.548Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T11:16:45.551Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T11:49:55.580Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
… 18 lines omitted …
2026-02-20T21:30:15.457Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T21:56:33.409Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T22:27:07.434Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T22:59:16.396Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T23:31:55.400Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-20T23:56:01.392Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T00:33:34.383Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T00:59:26.414Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T01:34:35.377Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.

#

2026-02-21T02:01:16.368Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T02:36:12.399Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T03:01:47.360Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T03:32:16.358Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T04:04:40.362Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.
2026-02-21T04:28:49.639Z [telegram] network error: Network request for 'getUpdates' failed!; retrying in 30s.

stdout: /Users/sj/.openclaw/logs/gateway.log

2026-02-19T08:56:36.896Z [gateway] signal SIGTERM received
2026-02-19T08:56:36.900Z [gateway] received SIGTERM; shutting down
2026-02-19T08:56:36.918Z [gmail-watcher] gmail watcher stopped
2026-02-19T08:56:37.104Z [ws] webchat disconnected code=1006 reason=n/a conn=853a8ecd-72ea-45f4-b6df-f2bf6acfefb1
2026-02-19T09:03:49.344Z [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /Users/sj/.openclaw/canvas)
2026-02-19T09:03:49.374Z [heartbeat] started
… 18 lines omitted …
2026-02-19T09:04:20.908Z [heartbeat] started
2026-02-19T09:04:20.909Z [health-monitor] started (interval: 300s, grace: 60s)
2026-02-19T09:04:20.910Z [gateway] agent model: anthropic/claude-3-haiku-20240307
2026-02-19T09:04:20.910Z [gateway] listening on ws://127.0.0.1:18789 (PID 99231)

#

2026-02-19T09:04:20.910Z [gateway] listening on ws://[::1]:18789
2026-02-19T09:04:20.911Z [gateway] log file: /tmp/openclaw/openclaw-2026-02-19.log
2026-02-19T09:04:20.919Z [browser/service] Browser control service ready (profiles=2)
2026-02-19T09:04:21.526Z [ws] webchat connected conn=a5f98089-002b-49df-8358-380c4f79c2c6 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
2026-02-19T09:04:22.175Z [telegram] [default] starting provider (@jewbagle_bot)
2026-02-19T09:04:22.185Z [telegram] autoSelectFamily=true (default-node22)
2026-02-19T09:04:22.851Z [ws] ⇄ res ✓ health 1312ms conn=a5f98089…c2c6 id=308d9156…e75e
2026-02-19T16:39:14.727Z [ws] ⇄ res ✓ node.list 207ms conn=a5f98089…c2c6 id=3a7bca82…fd75
2026-02-20T01:21:17.656Z [ws] ⇄ res ✓ node.list 124ms conn=a5f98089…c2c6 id=430d57d2…8734
2026-02-21T04:58:38.226Z [ws] ⇄ res ✓ config.get 156ms conn=e295a4d4…d440 id=95f9f712…df1e
2026-02-21T04:58:38.227Z [ws] ⇄ res ✓ status 159ms conn=e295a4d4…d440 id=5b9d25a0…cbef
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

#

sj@SJs-MacBook-Pro ~ % openclaw gateway status

🦞 OpenClaw 2026.2.17 (4134875) — End-to-end encrypted, drama-to-drama excluded.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-20.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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 99231, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
sj@SJs-MacBook-Pro ~ %

rain condor Feb 21, 2026, 5:27 AM

#

the logs didn't have 401 line

glacial matrixBOT Feb 21, 2026, 5:30 AM

#

If the Gateway logs don’t show any 401, that usually means the Gateway isn’t currently calling xAI at all (so the invalid x-api-key you saw is coming from some other run / other gateway instance / the wizard itself).

A stale OpenAI key won’t cause an x-api-key error — that header is xAI-specific.

To find where that xAI key is still lurking, can you run these and paste the outputs (they’re safe; but don’t paste any raw keys):

1) Make sure you don’t have two gateways / mismatched config

openclaw gateway status --deep

This often catches the “CLI is using config A, service is using config B” situation.

2) Check whether xAI is still configured anywhere

openclaw config get models.providers

#

openclaw config get env

If either output contains secrets, feel free to paste just: “contains XAI_API_KEY: yes/no” (no values).

3) Check the daemon env file (most common place xAI key is stored)

rg -n '^(XAI_API_KEY|OPENAI_API_KEY)=' ~/.openclaw/.env 2>/dev/null | sed 's/=.*/=<redacted>/'

Also: where exactly are you seeing 401 authentication_error: invalid x-api-key now?

in the onboarding wizard UI?
in the dashboard UI?
from a specific CLI command (which one)?

#

That one detail will tell us whether we’re hunting a stale key in ~/.openclaw/.env vs an old gateway still running.

rain condor Feb 21, 2026, 5:35 AM

#

either command of openclaw config resulted in path not found, and nothing happend when inputing daemon evn file.

401 found on openclaw dashboard

glacial matrixBOT Feb 21, 2026, 5:36 AM

#

If the 401 is on the OpenClaw dashboard, that’s usually Gateway auth (token/password / wrong Gateway URL) — not OpenAI vs xAI keys.

But there are two different “401” flavors people see in the dashboard:

Dashboard can’t connect / says unauthorized → wrong Gateway token/password or you’re pointed at the wrong Gateway instance.
Models / provider probe shows 401 … invalid x-api-key → that Gateway instance is trying to call xAI with a bad XAI_API_KEY.

Right now we need to figure out which one you’re seeing.

1) Confirm the dashboard is pointed at the same Gateway your CLI is talking to

Run and paste the output (this is the money command):

openclaw gateway status

In that output, look for lines like:

#

Config (cli): ...
Config (service): ...
and the probe URL / port

If Config (cli) and Config (service) are different, that explains everything: you’re editing one config, but the dashboard is connected to a Gateway service using another.

2) “path not found” from `openclaw config get ...` is often normal

It just means that config key isn’t set in your ~/.openclaw/openclaw.json (defaults apply). Not a failure.

Try these (they should exist):

openclaw config get gateway
openclaw config get agents.defaults.model

3) If you edited `~/.openclaw/.env`, you must restart the Gateway service

Otherwise the running daemon won’t pick it up:

#

openclaw gateway restart

(Also note: ~/.openclaw/.env won’t override an already-set env var, but for the service that’s usually fine since it typically has no shell env.)

4) One question: where exactly in the dashboard do you see the 401?

Please paste the exact text the dashboard shows (or a screenshot with keys redacted):

Is it on the Connect step (“unauthorized”)?
Or inside Models / Status / Probe, specifically mentioning x-api-key?

Once you paste openclaw gateway status + the exact dashboard 401 text, I can tell you the next precise step (either fixing the gateway token in the UI, or fixing/removing the xAI key on the service config that the dashboard is actually hitting).

rain condor Feb 21, 2026, 5:37 AM

#

couldn't post photo, it's on the overview dashboard, one right next to the top right of overview, one at the bottom of the snapshot box

glacial matrixBOT Feb 21, 2026, 5:38 AM

#

Those two “401” badges on Overview (top-right + the Snapshot card) are almost always Dashboard ↔ Gateway auth, not your model API keys.

Fix:

On the Dashboard go to Control → Overview → Gateway Access
There are two auth fields side-by-side (Gateway Token and Password).
Paste your Gateway Token and click Connect.
Get the token from the machine running the Gateway:

openclaw config get gateway.auth.token

If that prints nothing / you don’t have one yet:

openclaw doctor --generate-gateway-token

#

openclaw config get gateway.auth.token

If you previously reset/reinstalled: the Dashboard may be holding an old token in browser storage. Updating the Gateway Token in “Gateway Access” (or clearing site data for the dashboard URL) fixes it.

Docs: https://docs.openclaw.ai/help/faq#how-do-i-authenticate-the-dashboard-token-on-localhost-vs-remote

If you paste openclaw gateway status output, I can sanity-check you’re connecting to the right host/port (CLI vs service config mismatch is the other common cause).

rain condor Feb 21, 2026, 5:39 AM

#

this is what it says:
HTTP 401 authentication_error: invalid x-api-key (request_id: req_011CYLfLnLPKCcoaLutVvy8o)

#

here's the full gateway status:
sj@SJs-MacBook-Pro ~ % openclaw gateway status

🦞 OpenClaw 2026.2.17 (4134875) — End-to-end encrypted, drama-to-drama excluded.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-20.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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 99231, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
sj@SJs-MacBook-Pro ~ %

glacial matrixBOT Feb 21, 2026, 5:40 AM

#

That error message is not xAI — authentication_error: invalid x-api-key is the classic Anthropic auth failure (Anthropic uses the x-api-key header, and their request ids look like req_...).

And your models status shows your default model is Anthropic (anthropic/claude-3-haiku-20240307), so the dashboard snapshot will keep hitting Anthropic and failing until that key is fixed.

Do this on the same machine that runs your Gateway:

Confirm it’s Anthropic failing:

openclaw models status --probe-provider anthropic

Overwrite the stored Anthropic credential with your new one:

If you have an Anthropic API key (sk-ant-...):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default

Paste the new key when prompted.

#

If you meant to use a Claude subscription setup-token instead:

claude setup-token
openclaw models auth setup-token --provider anthropic

Restart + re-check:

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

Then reload the dashboard Overview page.

If --probe-provider anthropic is clean but the dashboard still shows the error, paste openclaw gateway status — that will tell us if the dashboard is connected to a different gateway/service/config than your CLI.

#

Config/service match and the Gateway is healthy (RPC probe: ok). So the dashboard is talking to the right Gateway — the remaining problem is simply:

Your current Anthropic credential is invalid/revoked, and since your default model is Anthropic, the Overview “Snapshot” call fails with:

HTTP 401 authentication_error: invalid x-api-key

Fix (Anthropic)

On the same Mac (gateway host), re-enter your Anthropic key into the default profile:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart
openclaw models status --probe-provider anthropic

Then reload the dashboard.

#

If you don’t want to use Anthropic at all

Right now you’re defaulting to Anthropic (anthropic/claude-3-haiku-20240307). If your intention is to use OpenAI or xAI instead, you need to switch the default model + set that provider’s key, otherwise the dashboard snapshot will keep hitting Anthropic.

Tell me which provider you actually want to run with (Anthropic vs OpenAI vs xAI), and I’ll give you the exact openclaw models set ... + auth command for that path.

rain condor Feb 21, 2026, 5:41 AM

#

wait hold up, could it be because i haven't re-enabled the api key?

#

for anthropic?

glacial matrixBOT Feb 21, 2026, 5:42 AM

#

Yeah — if you revoked/disabled/rotated the Anthropic API key (or created a new one and the old one got invalidated), you’ll get exactly this:

HTTP 401 authentication_error: invalid x-api-key

There isn’t really a “re-enable” inside OpenClaw; OpenClaw will keep using whatever key is stored in ~/.openclaw/agents/main/agent/auth-profiles.json until you replace it.

What to do:

In the Anthropic Console, confirm the key you expect to use is active (not deleted/revoked). If in doubt: create a fresh key.
Paste the new key into OpenClaw (this overwrites the one it’s currently using):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw gateway restart
openclaw models status --probe-provider anthropic

#

Reload the dashboard Overview — the 401 should disappear.

If you paste the output of openclaw models status --probe-provider anthropic (it redacts secrets), I can confirm it’s now picking up the right profile.

rain condor Feb 21, 2026, 5:43 AM

#

than it's not openclaw issue

#

i'll need to activate it on claude

#

got it

#

it works now, my noob dumbass didn't turn it on

#

thak you

glacial matrixBOT Feb 21, 2026, 5:44 AM

#

You’re welcome.

If anything else acts weird after a key change, the quick sanity trio is:

openclaw status
openclaw models status --probe
openclaw logs --follow

#

Perfect — that was it.

If you want to double-check everything’s clean now:

openclaw models status --probe-provider anthropic

and reload the dashboard Overview.

Glad that helped — if this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for others.

#API key can't reset or update to new api key, now it won't properly instal nor connect

1) First: confirm what OpenClaw is actually using

2) Fastest way to replace the saved key (no reinstall)

3) If you want a clean slate (nuclear, but reliable)

4) Avoid burning $10 again

1) Please paste the rest of these outputs (they got cut off)

2) Force OpenClaw to use a new API key (no reinstall)

3) Common gotcha on macOS (daemon doesn’t see your shell env)

1) Start the Gateway service (LaunchAgent)

2) If gateway start fails, run it in the foreground to see the actual error

3) Paste these two outputs (they’ll tell us exactly what’s wrong)

Fix: recreate config + install/start the macOS LaunchAgent

Important: your API key is ONLY in your current shell right now

Do this first (the simple “get it working again” path)

Quick question (so I give you the exact next step)

If the Dashboard asks for a token

Now: actually switching to a new API key (the reliable way)

Next steps

1) Open the Dashboard

Quick question

2) Confirm your model/provider auth (this is where the “old key” issue shows up)

3) If you want to force a NEW API key (recommended vs env vars)

About those Security Audit warnings

Next: if your goal is “use a NEW API key and stop it asking about the old one”

Optional: prevent future “search burned $10” incidents

About that security warning (Haiku)

If your remaining goal is “swap to a NEW API key and stop it using the old one”

4) If “bootstrapping” never stops

If you want to keep using Anthropic (Claude)

If you want OpenAI instead

If you want xAI instead

Cost guardrail (optional but recommended)

Update to your new Anthropic key (no coding needed)

0) First: confirm where it’s coming from (safe to paste, it’s redacted)

If models status says source=env: ANTHROPIC_API_KEY

If you’d rather store it in OpenClaw’s auth store (also good)

Fix (don’t paste tokens into Discord)

1) Pair your Telegram DM (most common fix)

2) If you don’t see a pairing code, tail logs while you DM the bot

3) Quick diagnostic snapshot (paste output here; no secrets)

What to do about the “unsupported schema node”

Why Telegram still “isn’t connected” (most common cause)

Do this:

If pairing list shows nothing

1) Force Telegram DMs to use pairing (safe default)

2) Trigger a pairing request

3) If it STILL says “no pending…”, we need to see if Telegram messages reach the Gateway

1) Probe Telegram health (paste output)

2) Check Telegram logs (paste output)

3) While watching logs, DM the bot

Quick note on the Dashboard message

Step A — confirm DM policy

Step B — if dmPolicy is pairing and still no pending requests

1) Approve the pairing code

2) (Optional) Notify yourself on Telegram

3) Verify it worked

Fix it (most reliable)

If it still says invalid x-api-key

1) Create the file (macOS)

2) Important gotcha: .env does not override an existing env var

3) If onboarding keeps “remembering” the old key: it’s usually auth profiles (not .env)

1) Overwrite the stored Anthropic credential

2) Verify what OpenClaw is actually using (safe to paste output)

3) If it still keeps preferring the old one: clear any per-agent “auth order” pin

4) Last resort “wipe it from orbit” (ONLY if you really want a full reset)

1) Run a real Anthropic auth probe

2) Force-replace the exact Anthropic stored credential (most common “locked key” fix)

3) If you ever pinned an auth order, clear it (so it stops insisting on the “old” profile id)

1) Run this (and paste just the “Auth overview” section)

2) Fix depending on what “source=” says

A) If it says source=env: ANTHROPIC_API_KEY

B) If it says it’s using a profile: (auth store)

Option A (simplest): overwrite the one it keeps picking

Option B: tell OpenClaw to prefer the manual profile

If you want to remove the old one entirely

Fix (pick one)

Option A: overwrite anthropic:default with the new key (fastest)

Option B: keep both, but force OpenClaw to prefer manual

Then verify with a live probe (no --plain)

Step 1: confirm it’s your current terminal env (quick test)

2) If `gateway start` fails, run it in the foreground to see the actual error

If `models status` says `source=env: ANTHROPIC_API_KEY`

If `pairing list` shows nothing

Step B — if dmPolicy is `pairing` and still no pending requests

2) Important gotcha: `.env` does not override an existing env var

3) If onboarding keeps “remembering” the old key: it’s usually auth profiles (not `.env`)

A) If it says `source=env: ANTHROPIC_API_KEY`

B) If it says it’s using a `profile:` (auth store)

Option B: tell OpenClaw to prefer the `manual` profile

Option A: overwrite `anthropic:default` with the new key (fastest)

Option B: keep both, but force OpenClaw to prefer `manual`

Then verify with a live probe (no `--plain`)

1) Look at the `grep` output and note the file names

2) Kill the PID that `lsof` shows

2) “path not found” from `openclaw config get ...` is often normal