[Bug][v0.10.0] Long-running session stays stuck on a revoked Anthropic OAuth token (401 'has been revoked'); /reload does not recover

[felipecsl]

Summary

A long-running session worker keeps sending an Anthropic OAuth access token that has been revoked. It never recovers. Other sessions on the same machine refresh the shared token in auth.json, and the old worker keeps using its own copy. Every later turn fails with:

⚠ Error: Retry failed after 1 attempts: Provider authentication failed (authentication_error, 401): OAuth access token has been revoked.

This hits sessions driven by heartbeats hardest. They live for days, so each heartbeat run fails the same way.

Observed (v0.10.0, Linux x64, binary install, daemon mode, Anthropic OAuth / Claude Max)

• The session worker started 2026-10-12 14:47Z. Its last successful turn was at 15:11Z.
• Other sessions started later (23:14Z, 02:16Z, 16:31Z the next day) and refreshed the shared Anthropic credential in auth.json.
• Another long-lived worker (started 15:46Z) got 401 OAuth access token has expired at 23:13Z. That was one minute before a new session refreshed the token.
• From 2026-10-13 06:06Z on, every turn in the first worker failed with 401 ... has been revoked: 14 heartbeat runs over about 10.5 hours, plus manual prompts. Other sessions used the fresh token without problems during that time.
• Running /reload in the stuck session did not help. The next prompt still failed with revoked, even though auth.json already held the valid token that other sessions were using.

Why (from reading the 0.10.0 bundle)

• AuthStorage.getApiKeyWithSourceToken uses the in-memory this.data[provider]. It reads disk (refreshOAuthTokenWithLock) only when the in-memory expires time has passed. A token that another process has rotated or revoked still looks valid to this worker.
• On a structured auth failure, completeWithProviderRetry / _handleRetryableError retry once with the same credential. isPermanentProviderFailureKind returns true once retriesPerformed > 0 && kind === "auth". Then _markProviderAuthStaleForRetryFailure marks the source stale. Nothing re-reads auth.json or forces a refresh.
• /reload (AgentSession.reload → authStorage.reload()) should have loaded the fresh token, but the worker still sent a revoked one. So the token may also be cached somewhere else, or the stale marking may interfere. I have not confirmed which.

Expected

When an OAuth credential gets a 401 (revoked / expired):

1. Re-read auth.json under its lock. If the access token on disk is different, retry with it.
2. If it is the same, force a refresh even though the local expires has not passed, save the result, then retry once.
3. Only then report the auth error. /reload should be enough to recover in any case.

Workaround

Restart the stuck session worker (kill its process; the daemon starts it again for the next due heartbeat). /reload does not work.

Related: #1768 (refresh tokens rotate on use), #2297 / #2093 (tail 401 after long waits).

[kevinjosethomas]

We merged #3393 earlier today so /reload rereads the credential store and refreshes the running session's credentials. This will be in the next stable release. Automatic recovery after a revoked-token 401 is still separate, so keeping this open.

[chrispatil]

This looks like the same root cause as #3669, seen from the expired-token side. In my case a session held by a worker for about three days failed with 401 OAuth access token has expired. login rewrote auth.json, but resuming the session still failed. New sessions worked, and killing the old worker process fixed it. It happened to me again on 0.10.1 on Oct 23, in a session that had been running for several hours.

This doesn't only hit sessions that sit idle and get resumed later. It also hits sessions that are actively working. The session stops mid-task, and its subagents stop with it. That makes Prime Agent hard to rely on for long-running tasks, which is where it should be strongest.

[maxkunisch]

Still reproducing on prime-agent 0.10.1, macOS arm64, using the release binary in daemon mode with Anthropic OAuth and claude-opus-5-5.

One long-running session has required repeated worker restarts. Latest sequence (UTC):

• Oct 24, 17:01: restarted the worker after repeated 401 OAuth access token has been revoked errors. The session subsequently completed more turns.
• Oct 25, 01:09: the same worker failed with 401 OAuth access token has expired. Re-authenticate to continue. Its automatic retry failed the same way.
• Oct 25, 12:26: a heartbeat failed twice with 401 OAuth access token has been revoked.
• At 12:28, auth.json already held an Anthropic credential with an expiry of 20:21 UTC, but the session was still served by the worker started the previous day. After confirming there were no running tools, subagents, or queued actions, we restarted only that worker. The daemon registered a new ready worker for the same saved session.

The latest restart is confirmed; we have not yet verified a successful model call after that restart. Earlier worker restarts restored the session, but the failure returned after later credential expiry/rotation.

A local workaround that restarts only idle, unattached workers cannot reliably protect long-running or heartbeat-driven sessions without interrupting work. Automatic credential re-resolution/recovery is needed in the worker request path, rather than requiring periodic process restarts.

We have not tested /reload during this latest occurrence. This report concerns the automatic recovery gap noted above, not a claim that the manual /reload fix in #3393 is broken.

[baudehlo]

Also reproducing every day on prime-agent 0.10.0 → 0.10.1, macOS arm64, daemon mode, Anthropic OAuth, claude-opus-5-5. Our setup is heartbeat-driven: one root session runs a daily cron heartbeat and steers three sibling root sessions over agent_message, one after another.

What we see (times UTC):

• 2026-10-12 13:39, 10-13 13:49: the sibling that received the morning message failed every turn with 401 OAuth access token has been revoked.
• 2026-10-14 13:40: two siblings failed with 401 OAuth access token has expired. Re-authenticate to continue.
• 2026-10-26 13:41: this time the coordinator's own heartbeat run failed (last_error on the heartbeat: 401 ... has been revoked).

Each time, the only recovery was a human opening the sessions in the UI. A heartbeat-driven session can't recover on its own, because the heartbeat turn itself is the thing that fails. So for anyone using heartbeats for daily work, this bug makes them unusable without a person checking in every morning.

A side effect, in case it helps: after the 26 Oct failure, the queued heartbeat prompts for Saturday, Sunday and Monday were all delivered together when the session came back, about 20 minutes later.