#Issue with Claude token

1 messages · Page 1 of 1 (latest)

left jolt
#

When I setup my Claude token, I get the following error in the platform:

HTTP 401 authentication_error: Invalid bearer token

Here's the output from openclaw models status

🦞 OpenClaw 2026.2.22-2 (45febec) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-sonnet-4-6
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : OpenRouter -> openrouter/auto, sonnet -> anthropic/claude-sonnet-4-6
Configured models (3): openrouter/auto, openrouter/moonshotai/kimi-k2.5, anthropic/claude-sonnet-4-6

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

  • anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-o...nyBWgGT1, anthropic:manual=token:sk-ant-o...nyBWgGT1
  • openai effective=env:sk-proj-...fhkwW_IA | env=sk-proj-...fhkwW_IA | source=env: OPENAI_API_KEY
  • openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...1284d77e

OAuth/token status

  • anthropic
    • anthropic:default static
    • anthropic:manual static
shy pilotBOT
#

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

proper heathBOT
#

Your models status output is the key clue:

  • anthropic … (oauth=0, token=2, api_key=0)
  • and your stored value starts with sk-ant-o… which is the setup-token / subscription style (sk-ant-oat-*), so OpenClaw will send it as an Authorization: Bearer … token.

HTTP 401 authentication_error: Invalid bearer token means Anthropic is rejecting that bearer token. That typically happens for one of these reasons:

  1. You meant to use an Anthropic Console API key, but configured the token flow instead
  • API keys are usually sk-ant-api… and should be set up as API key, not “paste setup-token”.
  • Fix: use the recommended API key path (docs): https://docs.openclaw.ai/providers/anthropic
    Easiest is re-run: openclaw onboard → choose Anthropic API key (recommended).
  1. You are using a Claude subscription setup-token, but it’s expired/revoked/invalid
  • Fix: regenerate and re-paste from the gateway host:
claude setup-token
# 
openclaw models auth setup-token --provider anthropic
  • If you generated it on another machine:
openclaw models auth paste-token --provider anthropic
  1. Possible regression with setup-token auth around 2026.2.21-2+
    There’s an open bug report that matches your exact symptom: https://github.com/openclaw/openclaw/issues/23538
    If you just generated a fresh sk-ant-oat-* and it still 401s, the pragmatic workaround is: use an Anthropic API key for now (the docs recommend that anyway): https://docs.openclaw.ai/gateway/authentication

Quick diagnostic to run (and paste the result):

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

That does a real live auth probe and will confirm whether Anthropic is rejecting the currently-selected credential (without you having to run a full agent turn).

left jolt
#

I want to use my subscription. Here's the output from openclaw models status --probe --probe-provider anthropic

🦞 OpenClaw 2026.2.22-2 (45febec) — Because Siri wasn't answering at 3AM.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-sonnet-4-6
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : OpenRouter -> openrouter/auto, sonnet -> anthropic/claude-sonnet-4-6
Configured models (3): openrouter/auto, openrouter/moonshotai/kimi-k2.5, anthropic/claude-sonnet-4-6

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

  • anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-o...nyBWgGT1, anthropic:manual=token:sk-ant-o...nyBWgGT1
  • openai effective=env:sk-proj-...fhkwW_IA | env=sk-proj-...fhkwW_IA | source=env: OPENAI_API_KEY
  • openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...1284d77e

OAuth/token status

  • anthropic
    • anthropic:default static
    • anthropic:manual static

Auth probes
┌─────────────────────────────┬───────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├─────────────────────────────┼───────────────────────────┼────────────┤
│ anthropic/claude-sonnet-4-6 │ anthropic:default (token) │ ok · 2.2s │
│ anthropic/claude-sonnet-4-6 │ anthropic:manual (token) │ ok · 2.3s │
└─────────────────────────────┴───────────────────────────┴────────────┘
Probed 2 targets in 2.4s

proper heathBOT
#

Nice — that --probe result is actually great news: both of your Anthropic setup-token profiles are valid and Anthropic is accepting them (Status: ok). So the token itself isn’t the problem.

That means the “HTTP 401 authentication_error: Invalid bearer token” you’re seeing in the platform is almost certainly coming from a different running Gateway / different state dir / stale daemon, not from the credentials you just probed.

Things to check (in order):

  1. Restart the running Gateway service
openclaw gateway restart

Then try again in the platform. (This fixes the “daemon is still using old auth state” class of issues.)

  1. Confirm the service and your CLI are using the same config/state
    Run:
openclaw gateway status --deep
# 
openclaw status --deep

You’re looking for mismatches like “Config (cli)” vs “Config (service)” pointing at different ~/.openclaw/... locations (common when running as a service user, different $OPENCLAW_STATE_DIR, etc.).

  1. Run a real model call from the same environment
    This removes UI ambiguity:
openclaw agent --agent main --message "Reply with exactly: subscription auth ok" --json
  • If this succeeds but the platform still errors: the platform is likely connected to a different gateway URL/host than the one you’re probing/restarting.
  • If this fails: paste the JSON error (with tokens masked) + the log lines around it from:
openclaw logs --follow

Docs reference for the subscription flow (setup-token must live on the gateway host): https://docs.openclaw.ai/providers/anthropic and https://docs.openclaw.ai/gateway/authentication

#

If you tell me where exactly you see the 401 (Control UI? macOS app? Discord reply?), I can point you to the specific “wrong gateway / wrong profile” failure mode.

left jolt
#

Here's what I see in the UI:

HTTP 401 authentication_error: Invalid bearer token (request_id: req_011CYWvNNLLkA3mkPTuM6rMa)

Here's what I see in console after running the real model call from console:

"payloads": [
  {
    "text": "HTTP 401 authentication_error: Invalid bearer token (request_id: req_011CYWvNNLLkA3mkPTuM6rMa)",
    "mediaUrl": null
  }
proper heathBOT
#

Yep — with that last bit, this is no longer “UI vs CLI” or “stale daemon”.

You now have:

  • openclaw models status --probe --probe-provider anthropic ⇒ ok
  • an actual generation call (openclaw agent …) ⇒ HTTP 401 authentication_error: Invalid bearer token (same style error you see in the UI)

That combination strongly suggests a regression/bug in the setup-token (subscription) path in your OpenClaw version, and it matches this open issue almost exactly:
https://github.com/openclaw/openclaw/issues/23538

What I’d do next (practical)

  1. Sanity-check you’re really using a setup-token
  • A Claude subscription setup-token should start with something like sk-ant-oat-… (not an Anthropic Console API key like sk-ant-api…).
  1. Check you’re not accidentally enabling a beta feature that subscription tokens reject
    Please run and paste (these don’t include secrets):
# 
openclaw config get agents.defaults.models
openclaw config get models.providers

Specifically look for model params like context1m: true / caching overrides / provider header overrides. (Some Anthropic betas are API-key-only.)

  1. Workaround (if you need it working today):
  • Use an Anthropic API key (works reliably), or
  • Switch your default model to your OpenRouter model while this is being fixed.

Helping get it fixed

If you can, add a comment to #23538 with:

  • your version 2026.2.22-2 (45febec)
  • that probe says ok but openclaw agent returns 401
  • the request id req_011CYWvNNLLkA3mkPTuM6rMa

If you paste the two openclaw config get … outputs above, I can tell you quickly whether there’s a config-triggered header/param causing the 401 (vs a pure core bug).

left jolt
#

dan@ubuntu-2gb-ash-1:~$ openclaw config get agents.defaults.models

🦞 OpenClaw 2026.2.22-2 (45febec) — The only crab in your contacts you actually want to hear from. 🦞

{
"openrouter/auto": {
"alias": "OpenRouter"
},
"openrouter/moonshotai/kimi-k2.5": {},
"anthropic/claude-sonnet-4-6": {
"alias": "sonnet"
}
}
dan@ubuntu-2gb-ash-1:~$ openclaw config get models.providers

🦞 OpenClaw 2026.2.22-2 (45febec) — Claws out, commit in—let's ship something mildly responsible.

Config path not found: models.providers

proper heathBOT
#

models.providers “path not found” is totally fine here — it just means you’re using the built‑in Anthropic provider config (no custom baseUrl/apiKey overrides).

The interesting (and weird) part is:

  • openclaw models status --probe --probe-provider anthropic says ok
  • but an actual run (openclaw agent …) returns 401 Invalid bearer token

That pattern usually means the thing doing the real model call is not using the same auth store you just probed (classic: systemd/daemon is running under a different user/state dir, or the service still points at an older install/state).

Can you run this and paste the output?

openclaw gateway status --deep

Specifically we need to see the lines that show Config (cli) vs Config (service) (and any state dir / home info). There’s even an FAQ entry for this exact mismatch:
https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different

#

If those paths differ, the fix is: put the setup-token into the service’s state (or repair the service to point at the same config), then openclaw gateway restart.

If the paths are the same and it still 401s, then it’s very likely the setup-token regression tracked here (and you should add your details/version/request_id to it):
https://github.com/openclaw/openclaw/issues/23538

left jolt
#

dan@ubuntu-2gb-ash-1:~$ openclaw gateway status --deep

🦞 OpenClaw 2026.2.22-2 (45febec)
If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

│
◇ Doctor changes ──────────────────────────────╮
│ │
│ WhatsApp configured, enabled automatically. │
│ │
├───────────────────────────────────────────────╯
│
◇ Unknown config keys ─────────╮
│ │
│ - channels.whatsapp.enabled │
│ │
├───────────────────────────────╯
│
◇ Doctor ──────────────────────────────────────────────╮
│ │
│ Run "openclaw doctor --fix" to apply these changes. │
│ Run "openclaw doctor --fix" to remove these keys. │
│ │
├───────────────────────────────────────────────────────╯
│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-26.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

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

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 26962, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

proper heathBOT
#

Good, that rules out the classic “service is using a different config/state dir” problem — Config (cli) == Config (service) and the gateway is healthy.

At this point, given:

  • you have no custom models.providers overrides (so it’s using the built-in Anthropic endpoint defaults),
  • and a real run (openclaw agent …) hits Anthropic and comes back 401 Invalid bearer token,

this looks extremely consistent with the setup-token/subscription regression that’s already being tracked here:
https://github.com/openclaw/openclaw/issues/23538

A couple quick checks that would still be useful (and safe to paste):

  1. Confirm the token prefix you’re using (don’t paste the token)
  • Is it sk-ant-oat... (setup-token) or something else like sk-ant-o...?
  • claude setup-token should give you an sk-ant-oat... style token.
  1. Restart after auth changes (just to rule out any caching)
# 
openclaw gateway restart

then re-run your openclaw agent ... test once.

  1. Grab the gateway log lines around the failure
    In one terminal:
openclaw logs --follow

In another, run the same openclaw agent ... call. Paste the few log lines around the 401 (tokens are masked).

If you want a “works today” workaround while still using your subscription, there’s also the community proxy route documented here:
https://docs.openclaw.ai/providers/claude-max-api-proxy
(That essentially uses Claude Code CLI under the hood and exposes an OpenAI-compatible endpoint.)

Otherwise, the practical stopgap is switching your default model to your already-configured OpenRouter model until #23538 is fixed.

left jolt
#

Is this bug fixed in v2026.2.24

proper heathBOT
#

I can’t see any mention of an Anthropic setup-token / “Invalid bearer token” fix in the 2026.2.24 changelog section (it lists a bunch of routing/heartbeat/etc fixes, but nothing about Claude setup-token auth).

Given you’re hitting the 401 on a real run on 2026.2.22-2, I would assume it’s not fixed in 2026.2.24 unless proven by testing.

If you want to verify quickly:

openclaw update --tag 2026.2.24
openclaw gateway restart

openclaw models status --probe --probe-provider anthropic
openclaw agent --agent main --message "Reply with exactly: setup-token test ok" --json
  • If the agent call still 401s on 2026.2.24, please add a comment to https://github.com/openclaw/openclaw/issues/23538 with “still broken on 2026.2.24” + your request_id.
  • If it works, also comment there so maintainers know what version fixed it.
#

(If you paste your openclaw update status output, I can also tell you what the updater thinks is available on your channel right now.)

left jolt
#

I just updated to 2026.2.25 and am getting the error

proper heathBOT
#

Yeah — updating to 2026.2.25 doesn’t magically fix this one. There’s nothing in the 2026.2.24/2026.2.25 changelog that indicates a setup‑token (“Claude subscription”) bearer fix landed, and people are still reporting the same 401.

Two quick sanity checks (so we know which bucket you’re in now):

  1. Re-run the live probe on 2026.2.25:
openclaw models status --probe --probe-provider anthropic
  • If the probe is NOT ok → your setup-token is genuinely invalid/revoked. Re-generate it via claude setup-token and paste again on the gateway host.
  • If the probe is ok but openclaw agent … still 401s → it’s almost certainly the same OpenClaw bug/regression path as https://github.com/openclaw/openclaw/issues/23538 (please comment there with “still broken on 2026.2.25” + the request_id you get).
  1. Grab the gateway log lines around the failing call (often includes extra hints):
openclaw logs --follow
# in another terminal, run your same openclaw agent test
#

Workarounds while waiting on a fix:

  • switch to OpenRouter temporarily (you already have it configured), or
  • if you must use the subscription path: the community claude-max-api-proxy route is documented here: https://docs.openclaw.ai/providers/claude-max-api-proxy (not ideal, but tends to work when native setup-token is busted).

If you paste your probe output on 2026.2.25 (the table), I can tell you immediately which branch you’re in.

left jolt
#

format a bug report for me to add to the open ticket please!

proper heathBOT
#

Here’s a copy/paste bug report you can drop into #23538 (or a new issue if they want a separate one). I’ve kept secrets masked and included the key contradiction (probe OK, real run 401).

Title

Anthropic setup-token (Claude subscription) probes OK but real requests fail with HTTP 401 authentication_error: Invalid bearer token (still on 2026.2.25)

Environment

  • OpenClaw: 2026.2.25 (also reproduced on 2026.2.22-2 (45febec))
  • OS: Ubuntu Linux (VPS)
  • Gateway: systemd user service
  • Config path: ~/.openclaw/openclaw.json
  • Agent dir: ~/.openclaw/agents/main/agent
  • Default model: anthropic/claude-sonnet-4-6

Summary

I’m trying to use my Claude subscription via the setup-token flow (token stored as auth-profiles.json entry of type token, token prefix sk-ant-o... masked). OpenClaw shows the token profiles and openclaw models status --probe --probe-provider anthropic reports OK for both token profiles, but any real agent turn results in:

#

HTTP 401 authentication_error: Invalid bearer token (request_id: req_...)

So auth probe succeeds, but the actual inference request fails with 401.

Auth / model configuration (sanitized)

openclaw models status shows:

  • Default: anthropic/claude-sonnet-4-6
  • Anthropic auth profiles: 2 profiles, both token type (no api_key), stored in:
  • ~/.openclaw/agents/main/agent/auth-profiles.json

Config allowlist:

{
"openrouter/auto": { "alias": "OpenRouter" },
"openrouter/moonshotai/kimi-k2.5": {},
"anthropic/claude-sonnet-4-6": { "alias": "sonnet" }
# 
}

No custom models.providers entry (built-in provider):
openclaw config get models.providers → Config path not found: models.providers

Gateway/service points to the same config:
openclaw gateway status --deep shows:

  • Config (cli): ~/.openclaw/openclaw.json
  • Config (service): ~/.openclaw/openclaw.json
  • Runtime: running, RPC probe: ok

Repro steps

  1. Configure Anthropic subscription token via setup-token/paste-token (token stored as type token in auth-profiles.json).
  2. Verify auth probe:
# 
openclaw models status --probe --probe-provider anthropic
  1. Run an actual model call:
openclaw agent --agent main --message "Reply with exactly: setup-token test ok" --json

Observed

  • openclaw models status --probe --probe-provider anthropic shows Status: ok for the Anthropic token profile(s)
  • openclaw agent … fails with:
  • HTTP 401 authentication_error: Invalid bearer token (request_id: req_011CYWvNNLLkA3mkPTuM6rMa) (example request_id)

Expected

If the auth probe is ok, real inference requests using the same provider/profile should succeed.

Notes / suspicion

#

This looks like either:

  • the probe is hitting a different endpoint / using different headers than the real request, or
  • setup-token handling is accepted by a probe but rejected by the normal request path (header/beta flags/token normalization mismatch), or
  • the probe is not representative of the real request auth mode.

Happy to run any debug build or provide logs; I can paste openclaw logs --follow around the failing request if needed (tokens redacted).

If you want, paste your 2026.2.25 versions of:

  • openclaw --version
  • openclaw models status --probe --probe-provider anthropic
  • failing openclaw agent … --json output (it already redacts)
    …and I can tighten the report further with exact versions/SHAs.
left jolt
#

I've posted this to the original issue