401 invalid bearer token errors

[twin stirrup]

I’m running into a persistent OpenClaw issue and wanted to see if anyone has seen this before.

Every time the gateway disconnects or closes and I restart it, the agent comes back to the same conversation thread from about two days ago instead of the current one. I can have a new conversation, but after a reboot or reconnect it snaps back to that older conversation and starts showing the same errors again.

Main symptoms:
• Anthropic 401 invalid bearer token errors
• Gateway/relay often shows as connected
• Browser relay appears active, but the agent cannot actually see or use the open browser windows
• Agent seems unable to save or persist newer session state correctly
• After restart, it resumes the same older conversation
• Cron appears to be running correctly

This makes me think the issue is not cron, but possibly stale session state, memory persistence, auth profile issues, or browser/gateway control.

Has anyone dealt with OpenClaw:
• restoring old sessions after restart
• failing to persist new conversation state
• showing relay connected but not controlling the browser
• looping Anthropic auth errors after restart

Note: Cron appears to be running correctly, so the issue seems more related to session persistence, auth, gateway/browser control, or relay behavior than task scheduling.

I can share redacted logs if helpful.

[lethal reef]

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

[twin stirrup]

I also frequently see “typing TTL reached – stopping typing indicator”, which stops the agent reply before it finishes.

provider=anthropic error=HTTP 401 authentication_error: Invalid bearer token
reason=token_mismatch
typing TTL reached – stopping typing indicator
gateway/relay connected but browser control unavailable

[craggy needle]

This combo of symptoms (snaps back to an older convo after restart + Anthropic 401s coming back + “relay connected but can’t control browser”) is most often one root cause:

Your gateway service is restarting into a different state/config than the one you think you’re using (profile / state dir / workspace / env mismatch). That means on restart it loads the old sessions + old auth profiles, so you get the same 401 loop and the same “can’t see the browser” situation.

0) First: what version + what does the service think it’s running?

Can you paste (these are read-only + safe to share; tokens are redacted):

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

Key thing I’m looking for in openclaw gateway status is whether it shows Config (cli) vs Config (service) different (the FAQ calls this out as a common gotcha). If those differ, the service is literally booting with a different config/state than your CLI edits.

Docs: https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different

1) Fix the “reverts to 2-days-ago session” issue (most common path)

If Config (cli) ≠ Config (service), fix is usually:

openclaw gateway install --force
openclaw gateway restart

Run that from the exact profile/environment you actually want the daemon to use (this is where people accidentally have --profile or OPENCLAW_STATE_DIR drift).

Why this matches your symptoms:

• Sessions live under ~/.openclaw/agents/<agentId>/sessions/… (so different state dir = different session store)
• Auth profiles live under ~/.openclaw/agents/<agentId>/agent/auth-profiles.json (so different state dir = different Anthropic token on restart)

2) Anthropic 401 “invalid bearer token” after restart

Two usual causes:

A) The gateway service doesn’t have the same env vars as your shell
So it restarts and “loses” the correct key/token and falls back to whatever is stored on disk (possibly stale/invalid).

Fix options from the FAQ:

• Put the key/token in ~/.openclaw/.env on the gateway host, or
• enable shell env import (env.shellEnv.enabled: true), or
• re-paste the token via the CLI so it’s stored in auth profiles.

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

B) You’re using an old / revoked setup-token
If you’re on Anthropic “setup-token” auth, it won’t auto-refresh. Re-generate and paste again (the FAQ has the exact commands).

3) “Browser relay connected but browser control unavailable”

With the Chrome extension relay specifically, two classic gotchas:

• No tab is actually attached. The extension only controls tabs where you clicked the toolbar icon and the badge shows ON.

• Gateway token mismatch in the extension Options. If your gateway token changed (or you’re accidentally talking to a different gateway/profile), the extension can look “alive” but won’t authorize properly.

Also important if your Gateway is remote: you typically need a node host on the machine running Chrome (docs are explicit on this).

Docs: https://docs.openclaw.ai/tools/chrome-extension

4) “typing TTL reached”

That’s usually just Discord’s typing indicator timing out; it’s noisy but not the root cause. If the model run is slow/blocked (e.g. repeated 401 retries), you’ll see this more.

---

If you paste the 4 command outputs above, I can tell you pretty quickly whether you’re in the “service vs CLI config mismatch” trap, and which exact state dir / agentId is being used on restart.

[loud torrent]

Not sure about OP but I’m still getting the HTTP 401 authentication_error: Invalid bearer token. I’ve reset the token many times and still have not fixed it. Could this be an issue with my claude account being banned from linking my max account or is this something that other people are experiencing as well? I’m a very low usage user who started yesterday so would be surprised if I was already banned. For additional context, I already had sonnet up and running before trying to switch to opus when I ran into this issue

[craggy needle]

HTTP 401 authentication_error: Invalid bearer token is almost always “the credential the gateway is actually using is not valid anymore / not the one you think”, not “the model is broken”.

Also: switching from one Anthropic model to another shouldn’t cause a 401 — the same Anthropic credential is used either way. So I’d focus on auth/profile drift, not “opus vs sonnet”.

A few very common gotchas to rule out:

1) Which “token” are you resetting?

There are (at least) two different tokens people mix up:

• Gateway UI token (gateway.auth.token) → only for Control UI / relay auth
• Anthropic credential (API key or Claude setup-token) → what Anthropic validates; this is what triggers the 401

Resetting/regenerating the gateway token won’t fix an Anthropic 401.

Docs (setup-token): https://docs.openclaw.ai/help/faq#how-does-anthropic-setuptoken-auth-work

2) The daemon/service isn’t picking up your new Anthropic token

If you run the gateway via launchd/systemd, it often does not inherit your shell env, so you paste/set a new token in your terminal, restart the service, and… it boots with the old env/auth again.

Fix patterns:

• put the credential in ~/.openclaw/.env on the gateway host, or
• store it via OpenClaw auth profiles (wizard / openclaw models auth …), not only in your shell env

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

3) You updated one agent, but you’re running a different one

Auth is per-agent, stored in:
~/.openclaw/agents/<agentId>/agent/auth-profiles.json

So if you have multiple agents (or profiles), it’s easy to update the wrong place and keep seeing the old bearer token after restart.

4) You have a stale auth profile pinned / being preferred

This is why I always ask for:

openclaw --version
openclaw models status

openclaw models status will show which Anthropic auth profile it’s actually trying/using.

---

What I’d do next (and what to paste here)

1. Run and paste (redacted output is fine; it won’t print your secret):

openclaw --version
openclaw models status
openclaw gateway status

2. Tell us explicitly:

• Are you using Anthropic API key or Claude setup-token (Max/Pro)?
• Are you running the gateway as a service/daemon or in a terminal?

If all of that looks correct and you still get 401, then yes, it could be an Anthropic-side token/account issue — but in practice, 90% of the time it’s one of the “wrong token / wrong place / wrong process” issues above.

[loud torrent]

I don’t think it’s an account ban, and I also don’t think Opus itself is the cause. Sonnet was working for me earlier, and switching models shouldn’t by itself cause a 401 since both Sonnet and Opus use the same Anthropic credential. What I’m seeing is that HTTP 401 authentication_error: Invalid bearer token keeps coming back even after regenerating the Claude setup-token multiple times.

A few more specifics from my side:
• I already confirmed my CLI and gateway service are using the same OpenClaw config/state, so it doesn’t look like a config mismatch.
• I tested token-only auth and it still 401s.
• I also tried adding an Anthropic API key, but I had mixed auth profiles for a bit, so I’m now cleaning that up.
• The logs suggest the gateway was still trying to use an old Anthropic bearer-token profile.

So my current theory is not “my Max account got banned,” but either:
1. the gateway is still picking up a stale Anthropic auth profile somewhere, or
2. the Anthropic setup-token path is just unstable / being rejected for some users right now.

Have you seen other people in the same boat where Sonnet worked, then after trying to switch models they started getting persistent Invalid bearer token errors even after regenerating setup-tokens? And have you seen cases where the probe/auth setup looks okay, but actual runs still 401?

[loud torrent]

@craggy needle do you need me to rephrase the question above?

[craggy needle]

No rephrase needed — the question is clear.

What I do need to unblock this is a couple concrete “what is the gateway actually running with” snapshots (these are safe to paste; they redact secrets):

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

And two quick clarifiers (one line each is fine):

1. Are you authenticating Anthropic via API key or Claude setup-token (Max/Pro)?
2. Are you running the gateway as a service/daemon (launchd/systemd) or in a terminal?

Big reason: “comes back to a 2-days-old conversation after restart” + “401 invalid bearer token after restart” strongly suggests the service is restarting with a different config/state/auth store than the one you’re editing/testing. Those commands make that obvious immediately.

[loud torrent]

Quick clarifiers:
1. I’ve tried both, but the original path that worked earlier was Claude setup-token. Right now I’m testing whether that token path is broken versus whether OpenClaw is picking up stale auth.
2. I’m running the gateway as a launchd service/daemon, not just in a terminal.

A bit more context in case it helps:
• Sonnet was working earlier.
• After I tried switching to Opus, I started getting persistent HTTP 401 authentication_error: Invalid bearer token.
• Regenerating the Claude setup-token multiple times did not fix it.
• I also noticed behavior where after restart it seemed to snap back to older state/conversation, which is why I’m also suspicious of state/auth-store drift.

Would you want me to paste the outputs directly here for you to compare, especially the Config (cli) vs Config (service) lines and whatever auth profile the gateway says it’s actually using?

[craggy needle]

Yep — please paste them here. That’s exactly what will tell us whether this is (a) state/config drift vs (b) a genuinely-invalid Anthropic setup-token.

Paste (as-is; don’t manually edit unless you’re removing paths/usernames — the CLI already redacts secrets):

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

What I’ll be checking in your output

In openclaw gateway status:

• Config (cli) vs Config (service) (if those differ, that perfectly explains “snaps back to old convo” + “keeps using an old bearer token”)
• the effective state dir/profile the daemon is using

In openclaw models status:

• which Anthropic auth profile it’s actually trying (and whether it’s reading from the auth store you expect)
• any hints that it’s pinned to a stale profile/order

Why this matters (with launchd specifically)

launchd commonly ends up running OpenClaw with a different profile/state dir than your interactive terminal (or a different install path), so you keep regenerating a setup-token “successfully”… just not in the same place the daemon reads on restart.

If we do see config drift, the usual fix is to reinstall the service metadata from the profile you want:

openclaw gateway install --force
openclaw gateway restart

(But let’s confirm from your pasted output first.)

One more small but important question

When you “regenerated the Claude setup-token”, how did you apply it to OpenClaw?