TL;DR: A 401 saying your session has ended usually does not mean your session ended. It means the refresh token OpenClaw sent was rejected, most often because a rotated replacement was never written to disk. Logging in again works, and then it fails again a cycle later, which is the tell. The fix is in the credential store’s ownership and writability, not in your account.
OpenAI Codex token refresh failed (401): "Your session has ended. Please log in again." is one of the more misleading errors an OpenClaw operator will hit, because the remedy it suggests works, and works only briefly.
Contents
- What the Error Actually Says
- Why Re-Authenticating Is Not a Fix
- Reused Versus Invalidated
- Telling It Apart From a Real Logout
- Where to Look
- FAQ
What the Error Actually Says
Three separate facts are compressed into that one line, and only the first is reliably true.
The provider rejected the refresh token that OpenClaw presented. That is what the 401 establishes.
The text “your session has ended” is the provider’s generic phrasing for a rejected refresh, not a statement that anyone logged you out. And “please log in again” is advice about how to obtain a working token, not a diagnosis of why the last one stopped working.
So the error is accurate about the response and misleading about the cause. Treating it as an expiry problem sends you to your account settings, which is the one place the fault is not. For the wider set of failures that print something misleading or nothing at all, see OpenClaw errors explained .
Why Re-Authenticating Is Not a Fix
Modern OAuth deployments commonly issue single-use refresh tokens. Each time the client redeems one, the provider returns a new access token and a new refresh token, and invalidates the one just used. Rotation is the point: a refresh token that can only be spent once makes a stolen copy detectable, because the theft shows up as a reuse.
That design puts a hard requirement on the client. The replacement has to be written down before the next cycle, or the client will present a spent token.
If that write does not land, the sequence is quietly deterministic:
- You log in. A valid refresh token is written to the credential store.
- The agent runs. At the first refresh, the token is redeemed and a replacement comes back.
- The replacement is not persisted. The store still holds the original.
- The next refresh presents the original again. The provider has already seen it.
- “Your session has ended.”
Logging in again restarts that loop at step one, which is exactly why it appears to work. A fix that survives one cycle and fails on the next is the signature of a persistence problem, not an expiry one, and the interval between failures will roughly match your token lifetime rather than anything about your account.
Reused Versus Invalidated
Two codes show up around this failure and they are usually one story rather than two.
refresh_token_reused is the provider reporting that it received a token it had already redeemed. In a genuine attack this is the alarm the rotation design exists to raise. In practice, on a self-hosted agent, it much more often means the replacement was never saved and the client presented the old one again.
refresh_token_invalidated is frequently what follows. Providers that detect reuse commonly invalidate the entire token chain rather than just the offending token, on the reasonable assumption that if a token has been used twice, one of the two users should not have it.
Seeing reuse and then invalidation is the ordinary sequence for this fault. It does not mean two things went wrong.
Telling It Apart From a Real Logout
Sessions do genuinely end. Three checks separate the cases quickly.
Does anything else using the same account still work? A revoked authorisation, a password change or a provider-side logout breaks every client at once. A persistence fault breaks exactly one agent: the one that could not write its token down.
Has the credential file been modified since you last logged in by hand? If its modified time still points at your last manual login, then nothing has been written back to it across every refresh since, which answers the question on its own.
Does the failure interval match the token lifetime? Expiry and revocation are events; they happen once, when they happen. A rotation fault is periodic, and its period is the refresh cycle.
Where to Look
The failure sits at the write, so the things that break writes are the things to check: which user the gateway runs as, who owns the credential file and its directory, whether the file is writable by that user, and whether a stale lock is preventing the update from completing. A related error naming a failure to update the auth profile store, or a lock that may still be held, is pointing at the same place from the other side. Both sit alongside the other quiet failures in the OpenClaw production gotchas , and the gateway token management guide covers the separate case where the gateway’s own token is the one that stopped matching.
This is also why the identical version behaves differently on two machines. Nothing about the provider or the agent’s code differs between them; the ownership of one file does.
The auth store lock error, in the words it prints
If the write is what failed, you may see the lock say so directly. OpenClaw raises two closely related messages, and the difference between them tells you which operation was interrupted:
Failed to update auth profile store; the auth store lock may be busy. Wait a moment and retry.
Failed to remove auth profile "<profile-id>"; the auth store lock may be busy. Wait a moment and retry.
The first appears when a profile is being written, which is exactly what a rotated refresh token has to do. The second names the profile it was trying to delete, so a message carrying a profile id is a removal, not a refresh.
“Wait a moment and retry” is good advice for a genuine collision between two processes, and it is the wrong advice when the lock is not busy but stale, or when the file could not have been written anyway because the gateway does not own it. If retrying clears it once and it returns on the next refresh cycle, treat it as the write-permission case above rather than as contention.
If the credential file is root-owned because an install ran under sudo while the gateway runs as an unprivileged user, every refresh will succeed at the provider and fail at the disk, forever, with no error at the moment the write is dropped. The only symptom you get is a 401 one cycle later, describing a session that never ended.
Frequently Asked Questions
What does "token refresh failed (401): Your session has ended. Please log in again" mean in OpenClaw?
It means the refresh token OpenClaw presented was rejected by the provider, so the agent has no valid access token and every model call fails. The wording is misleading in the common case: you were not logged out by the provider and your credentials are not wrong. The stored refresh token was either never replaced after its last use, or it was used twice. Logging in again writes a fresh token and the agent works, which is why this reads as a session-expiry problem rather than a persistence one.
Why does re-authenticating fix it and then it comes back?
Because logging in again treats the symptom. Providers that issue single-use refresh tokens hand back a NEW refresh token every time one is redeemed, and the client must persist that replacement. If the write does not land, the old token stays on disk and works exactly once more, so the failure returns on the next refresh cycle rather than immediately. A fix that survives one cycle and fails on the next is the signature of a persistence problem, not an expiry one.
What is the difference between refresh_token_invalidated and refresh_token_reused?
They describe the two ends of the same failure. refresh_token_reused means the provider saw a refresh token it had already redeemed, which normally means the replacement was not saved and the old one was presented again. refresh_token_invalidated means the token is no longer accepted at all, which is often what the provider does to the whole chain after it detects a reuse. Seeing reuse followed by invalidation is the ordinary sequence, not two separate faults.
How do I tell this apart from a genuine logout?
Check whether other clients using the same account still work. A real logout, a revoked authorisation or a changed password breaks every client at once. A rotation or persistence fault breaks only the agent that failed to store its replacement token, and re-authenticating that one agent restores it while everything else was never affected. Check the modified time on the credential file too: if it has not changed since your last manual login, nothing has been written back to it.
Can the auth store lock cause this?
It can produce the same outcome by a different route. If the credential store is locked or not writable when the refresh completes, the new token cannot be persisted even though the exchange succeeded, which lands you in the same state as a client that never tried to save it. OpenClaw prints this as "Failed to update auth profile store; the auth store lock may be busy. Wait a moment and retry." A message in those words points at the store rather than at the provider, and a variant naming a profile id is a removal rather than a refresh.
Is this an OpenClaw bug or a provider problem?
Usually neither, in the sense that the provider is behaving as specified and the agent is running the flow it was given. Single-use refresh tokens are a deliberate security design: rotation is what makes a stolen token detectable. The failure sits where the rotated token has to be written down and read back, which is the part that depends on file ownership, permissions and locking on the host. That is also why the same version works on one machine and not another.
Stop Googling OpenClaw errors.
Your agents message ours on Telegram. Production-tested OpenClaw fixes. $99/mo.