Disabling Account Pooler breaks Claude: running turns 503-retry for ~3 min, new threads fail with an expired local OAuth login #4352

Activity

1. brsbl

   added

   providersCross-provider bridges, models, loginCross-provider bridges, models, login

   provider-claude-codeBuilt-in plugin: provider-claude-codeBuilt-in plugin: provider-claude-code

   pluginsPlugin SDK, runtime, marketplacePlugin SDK, runtime, marketplace

   on Sep 25, 2026
2. brsbl

   changed the title [-]Disabling Account Pooler mid-turn fails running Claude turns after ~3 min of 503 retries[/-] [+]Disabling Account Pooler breaks Claude: running turns 503-retry for ~3 min, new threads fail with an expired local OAuth login[/+] on Sep 25, 2026
3. bb-slop-cop

   added the

   Bug

   issue type on Sep 25, 2026
4. bb-slop-cop

   added

   partial-reproBug partially reproduced; some claims unverified; see linked reportBug partially reproduced; some claims unverified; see linked report

   on Sep 25, 2026
5. bb-slop-cop commented on Sep 25, 2026

   

   bb-slop-copBot

   on Sep 25, 2026

   Contributor

   More actions

   🚨 SLOP COP 🚨 · new-issue-autopilot

   Preserved Bug · Priority: Medium · Effort: Medium and providers, provider-claude-code, plugins. Added partial-repro.

   Reproduction report: PARTIALLY REPRODUCED, high confidence in the HTTP root cause. Two clean checkouts of trusted main reproduced a working plugin route returning 503 after disable; the focused non-server-error regression assertion failed in both. The proxy treats intentional disablement like a transient unavailable state. Claude retry timing and OAuth invalidation remain unverified.

   No PR: selecting shutdown behavior and changing the HTTP contract or credential ownership exceeds this rule’s simple-fix limits.

   AGENT GENERATED
6. seklow commented on Oct 23, 2026

   

   seklow

   on Oct 23, 2026

   More actions

   This is live evidence for the "Likely cause" hypothesis in this issue, from a second installation. The hypothesis holds: --import gives the pool the same refresh-token chain as the host's Claude Code login, and the two holders keep taking it from each other. One assumption in it does not hold: pool-routed Claude Code threads still refresh the host login, so the host copy is never idle. I'm adding this here because it is the same root cause. If you would rather keep this issue about the disable/503 path, I can move the --import part to its own issue.

   Summary

   On one Linux host I added Claude accounts with bb pool account add --provider claude --import and kept using Claude Code on that host: bb threads routed through the pool, plus a terminal account switcher. Anthropic rotates the refresh token on every refresh and rejects the spent one at once. So whenever an access token came within 5 minutes of expiry, the pool and a host-side refresher raced for the same refresh token.

   • Over 3.7 days the host side refreshed first in 15 of 67 such windows.
   • 6 of those 15 ended in HTTP 400 invalid_grant for the pool, on 5 different pool accounts, and the pool marked the account error.
   • Twice, the failed account was the only eligible one, and pooled threads got a 429 that pointed 43 min and 2 h 10 min ahead.
   • When the pool wins instead, the host's copy is spent. According to the Claude Code binary, Claude Code then clears its stored login at its next refresh. That is the OAuth session expired and could not be refreshed failure reported above. I did not observe the wipe itself on this host.

   Meanwhile the pool docs say "Prefer --import for an existing Claude Code login".

   Versions and environment

   • bb 0.46.1 (latest release, desktop-v0.46.1), installed with npm (bb-app), running as a systemd user service. Linux x86_64 (Debian 13, kernel 6.12), Node v24.22.1.
   • Built-in Account Pooler (account-pool 0.1.0) with Claude routing on.
     • Six Claude subscription accounts and two Codex accounts were added on 2026-10-19 with --import, switching the host login between them.
     • One more Claude account (the reserve, "account E" below) was imported on 2026-10-22 at 10:12:47Z from the login that was active on the host.
   • Claude Code 2.1.306 to 2.1.308 when the races happened (2.1.309 now, with the same refresh logic). codex-cli 0.163.0.
   • Two unusual parts of this setup matter here:
     • A third-party Claude Code and Codex account switcher, ccswap v0.39.2, keeps a copy of each login, swaps one into ~/.claude/.credentials.json, and refreshes the idle copies when 5 minutes or less are left.
     • A local bb script automation ran about once a minute as a workaround for this race. It copied whichever copy was newer (by expiresAt) between the pool's secret files and the switcher, then ran bb pool account enable to clear the pool error.
       • Because of it, the shared grant survived each race, and the race came back every 8 hours.
       • Without it, each imported account would lose one side once and stay broken.
   • Code is cited at main @ 1e80ca7b44bccd06c6da75ed9ca6ba497bd380f5, and the behavior is unchanged on main.
     • Between desktop-v0.46.1 and that commit, plugins/account-pool changed only in row styling, env contribution without a thread id, and a JWT schema type. None of it touches import, refresh, remove, or the docs.
     • I also checked the installed account-pool/dist/server.js for the same import, refresh, and remove code.

   Steps to reproduce

   I saw this in normal use and did not trigger it on purpose, because each run costs either a pool account or the host login.

   1. On the bb server host, run claude /login. On Linux the login is stored in ~/.claude/.credentials.json.
   2. Run bb plugin enable account-pool, then bb pool account add --provider claude --import, then bb pool routing claude.
   3. Keep using Claude Code on that host. Pool-routed bb Claude threads are enough; a terminal claude works too.
   4. Wait until the access token is within 5 minutes of expiresAt. Tokens last 8 hours. The pool and Claude Code both refresh when now + 300 s >= expiresAt.
   5. Whichever side refreshes first wins:
      • Host first: the pool's next refresh gets HTTP 400 invalid_grant and the account goes to error. If it was the only eligible account, pooled threads get a 429.
      • Pool first: Claude Code's next refresh gets invalid_grant, Claude Code clears its stored login, and the host is signed out. This branch comes from the Claude Code binary, not from an observed wipe; see Evidence.

   Not observed: any Codex failure. Codex --import shares the ~/.codex/auth.json grant in the same way, but Codex tokens last about 10 days and no Codex refresh fell inside the window.

   Expected vs actual

   Actual. Pool log ~/.bb/plugins/account-pool/logs/plugin.log, verbatim except that account ids are replaced:

   {"ts":1792577155839,"level":"warn","message":"Account Pooler claude account <account D> OAuth refresh failed: OAuth refresh failed with HTTP 400. invalid_grant. expiresAt=1792577453039, forced=false."}
   {"ts":1792669618276,"level":"warn","message":"Account Pooler claude account <account E> OAuth refresh failed: OAuth refresh failed with HTTP 400. invalid_grant. expiresAt=1792669886129, forced=false."}
   {"ts":1792716590876,"level":"warn","message":"Account Pooler claude account <account B> OAuth refresh failed: OAuth refresh failed with HTTP 400. invalid_grant. expiresAt=1792716887319, forced=false."}
   

   The access token still had 297 s, 268 s and 296 s left, respectively. Right after the last line, bb thread log thr_cv4aev22bx shows the following; thr_cehnf3bqqh and thr_t9xt22j7id got the same 2 to 4 s later:

   2026-10-23T00:49:51.367Z provider/error
   API Error: Request rejected (429) · No Account Pooler account is currently eligible. Next account is expected to be available at 2026-10-23T02:59:59.798Z (in 7809 seconds).
   

   The external script cleared the account's error at 00:50:07Z.

   Expected. Adding an account should not quietly create a second, uncoordinated holder of a login that is still in use. Concretely:

   1. Docs recommend --login. Replace "Prefer --import for an existing Claude Code login" with a recommendation for --login. Describe --import as handing the login over to the pool: it is safe only if nothing on that machine uses the login again. Pool-routed Claude Code threads on the same machine count as users (see Evidence).
   2. Import warns. bb pool account add --import and the settings item "Import from this machine" should say two things: the pool and the host will share one single-use refresh token, and one of them will be signed out at the next refresh. They should point to Sign in instead, for example by requiring --yes on the CLI and a confirmation in the UI.
   3. Docs say that remove does not revoke. bb pool account remove only deletes the pool's entry and secret file; nothing is revoked upstream. Users should know what that means:
      • Removing an imported account does not sign the host out. But if the pool refreshed last, the host's copy is already spent, and the host needs claude /login.
      • A removed --login grant stays valid upstream until it expires.
   4. Optional: record where an account came from. The original report notes that the pool cannot tell an imported account from a signed-in one. With that recorded:
      • bb pool status and the disable flow could warn "this account shares its login with this machine".
      • An invalid_grant on an imported account could say "another program on this machine refreshed this login first; sign in again with --login" (or re-login in place, Account Pooler: re-authenticate an existing account in place, add accounts disabled or with a priority, and show login expiry #6170) instead of the bare error.
      • The docs should also stop promising that bb pool account refresh clears such an error: it forces a refresh with the stored refresh token, which is the spent one.

   Evidence

   All six pool invalid_grant failures in the window (UTC). Every pool-refreshed Claude token lasted exactly 28800 s (all 65 Claude refreshes in the log). So the other side's refresh time is the previousExpiresAt of the pool's next refresh minus 8 h. I cross-checked it against the host credentials file and the switcher's log.

   Pool invalid_grant	Account	Token left	Who refreshed first	Lead	Effect
   10-19 10:18:20.229	A	60 s	switcher, idle copy (inferred)	—	158 invalid_grant in total over 13.4 h, repeated by the 5-minute background usage refresh; unusable about 14 h
   10-19 17:29:16.384	B	expired 85 s before (a network error at 17:24:07 had delayed the first attempt)	switcher, idle copy, 17:26:55	2 min 21 s	82 invalid_grant in total; unusable about 7 h
   10-20 14:13:06.588	C	76 s	switcher, idle copy, 14:10:50	2 min 16 s	about 3 min
   10-21 10:05:55.839	D	297 s	Claude Code 2.1.306 in pool-routed thr_a2dvs6byg3, 10:05:55.121	0.72 s	the request failed over to another account
   10-22 11:46:58.276	E (imported 94 min earlier)	268 s	Claude Code 2.1.306 in pool-routed thr_biw5z6pxki, 11:46:57.727	0.55 s	429 in thr_biw5z6pxki: "Next account … 2026-10-22T12:29:59.646Z"
   10-23 00:49:50.876	B	296 s	Claude Code 2.1.308 in pool-routed thr_cv4aev22bx, 00:49:50.440	0.44 s	429 in thr_cv4aev22bx, thr_cehnf3bqqh, thr_t9xt22j7id: "Next account … 2026-10-23T02:59:59.798Z"

   Counts. A "window" is one 8-hour expiry of one shared account, from 2026-10-19 08:49Z to 2026-10-23 01:25Z. Six shared Claude accounts give about 18 windows per day, 67 in total.

   • The pool refreshed first in 52 windows.
   • The host side refreshed first in 15: 8 by Claude Code on the active login and 7 by the switcher on idle copies.
   • 6 of those 15 produced the pool failures above, 3 from each source.

   Pool-routed bb threads refresh the host login. The original hypothesis assumed that nothing refreshes the local login once every session goes through the pool. That is not the case here.

   • In all three active-login races, the winner was the Claude Code process of a bb thread whose provider.env-resolved had ANTHROPIC_BASE_URL/ANTHROPIC_AUTH_TOKEN from account-pool.
   • In thr_cv4aev22bx, a Claude Code workflow subagent of the thread's session rewrote ~/.claude/.credentials.json at 00:49:50.440. It sent its next API request at 00:49:50.455, through the pool, and the pool's refresh for that request lost at 00:49:50.876.
   • The Claude Code side of this is [BUG] CLI holding an env credential still renews the stored claude.ai login; on macOS sandboxed processes split it to .credentials.json and a later 400 wipes it anthropics/claude-code#104359. The bb side is filed separately as Account Pooler: pool-routed Claude Code and Codex threads, and CLIs they start, should authenticate only with the hub token and leave the host's own logins untouched #6171: pool-routed threads should not touch the host login at all. This comment is only about --import handing out the shared grant.

   When the host loses.

   • Observed once directly, on 2026-10-23 while the sync script was paused: the pool refreshed account D at 01:45:07.248Z, and after that the switcher's copy of D failed with invalid_grant and was flagged dead.
   • For Claude Code, I read the behavior in the 2.1.309 binary. On invalid_grant it emits tengu_oauth_refresh_token_marked_dead_invalid_grant. If the stored refresh token is still the rejected one, it overwrites refreshToken, accessToken, and expiresAt with empty values (tengu_oauth_refresh_token_cleared_on_disk). That leaves the host in exactly this issue's "OAuth session expired and could not be refreshed" state.
   • I did not see a Claude Code wipe on this host during the window.

   Code (at 1e80ca7):

   • Import copies the host's refresh token into the pool secret: credentials.ts#L221-L240, claude-adapter.ts#L61-L80. Codex does the same: credentials.ts#L147-L159, codex-adapter.ts#L398-L411.
   • The pool refreshes inside the same 5-minute window as Claude Code: provider-adapter.ts#L121-L134 (window constant #L13-L14). It sends the stored refresh token and writes the rotated one only to its own store: claude-adapter.ts#L107-L131.
   • A 400/401 from the token endpoint is non-transient: provider-adapter.ts#L175-L186. On the request path that marks the account error: hub.ts#L537-L549. Marking it error while the access token is still valid for about 5 minutes is a separate pool problem, Account Pooler: a rejected proactive OAuth refresh errors an account whose access token is still valid; background refresh keeps replaying the rejected token #6167.
   • remove deletes the entry and the secret file and revokes nothing: store.ts#L104-L113, operations.ts#L162-L169. The only "revoke" in the plugin is an error-description string.
   • Guidance and UI:
     • "Prefer --import": accounts-and-routing.md#L57-L62.
     • The refresh recovery promise: #L66-L72.
     • Settings item "Import from this machine — Copies the server host's ~/.claude login" with no warning: app.tsx#L578-L590.
     • CLI help: cli.ts#L264-L268.
     • Overview: PLUGIN_OVERVIEW.md#L5-L5.

   What I ruled out

   • Not network or server trouble: all six are HTTP 400 invalid_grant. In the three active-login cases, another holder had refreshed the same token 0.44 to 0.72 s earlier.
   • Not caused by the sync script: it never calls the token endpoint itself; it copies stored tokens and runs bb pool account enable/refresh. The winning refreshes came from Claude Code (3) and the switcher (3). The script only made the shared grant last longer.
   • Not the disable path: the pool stayed enabled throughout.
   • Still on main at 1e80ca7; see the links above.
   • Not a duplicate of the other issues:
     • Claude Code OAuth expiry: classify authorization failures and recover sign-in inside BB #3337 is about bb's Claude Code provider seat losing its refresh token, a different code path in provider-claude-code.
     • provider-retry never retries Account Pooler 429/502 failures #4839, Fix provider retries for exhausted account pools #5283, Retry turns that fail on provider server and connection errors #5931 and Account Pooler quota exhaustion leaves Codex reconnecting inside active turns and blocks the shared concurrency queue #6116 are about Provider Retry and Codex behavior after a pool 429.
     • Account Pooler: last-resort accounts, per-account switch thresholds, and an opt-in order by earliest weekly reset #4468 and Account Pooler blocks Claude extra usage when subscription quota reaches the switch threshold #4475 are about switch thresholds.
     • None of them covers --import sharing a grant.
   • Not verified: that a second --login of the same Anthropic account leaves the host's login working.
     • Anthropic does not document this, and the pool's sign-in uses the same OAuth client id as Claude Code (oauth-login.ts#L8-L8).
     • This host is moving to --login now, but has not been through a full 8-hour rotation yet.

   Suggested priority and effort

   Medium priority. This hits anyone who imports a login that is still used on that machine, and that includes the bb server's own pool-routed Claude threads. Work stops when the losing pool account was the only eligible one, or when the host is signed out. Workaround: add the accounts with --login, remove the imported ones, and run claude /login on the host if its copy was already spent. Effort is low for the docs and the import warning, and medium for recording the account source.

   Investigation: bb thread thr_agudxusj98 (reports under pool-research/ in its thread storage). Affected threads: thr_a2dvs6byg3, thr_biw5z6pxki, thr_cv4aev22bx, thr_cehnf3bqqh, thr_t9xt22j7id.

   BB-Thread-ID: thr_agudxusj98

   AGENT GENERATED
7. ymichael

   added a commit that references this issue on Oct 30, 2026

   Make the Account Pooler hold its own logins (#6691)

   ...

   17d3cbc