bug: Re-auth multiple times a day

[mikabytes]

Pre-flight checklist

• I searched existing issues and confirmed this is not a duplicate.
• I am running a supported codex-lb version (see Releases).
• I can reproduce the problem with the steps below.

codex-lb version

1.20.1

Deployment method

Other (describe below)

Client used against codex-lb

Codex CLI, ОpenCode

ChatGPT account plan(s) involved

Business

Model(s) involved

gpt-5.5

What happened?

Today I had to re-authenticate three times. I've been using codex-lb for quite a while, and while I normally have to re-authenticate maybe once a month, this is new behavior. Authentication would work for a few hours, then I'd be forced to re-authenticate again.

After the first two occurrences, I assumed there might be some mismatch or issue on the Codex CLI side. To rule that out, I switched to OpenCode. A few hours later, I was logged out again.

The sequence was:

1. First time: a single account was affected.
2. Second time: all accounts were affected.
3. Third time: a different single account was affected.

To investigate further, I asked GPT to analyze the Kubernetes cluster hosting codex-lb. It suggested the following:

# Likely Cause
The strongest explanation is duplicate OAuth sessions for the same ChatGPT account. Re-authing one stored row appears to revoke refresh tokens held by older rows for that same chatgpt_account_id, and codex-lb then later tries to use/refresh one of those revoked rows.
That matches the repeated re-auth pattern and the exact token_revoked / session has ended log messages.

For context, we have six business accounts, all within the same OpenAI organization. All accounts use email addresses on the same domain (e.g. @mycompany.com).

Since these are paid business accounts and we're transparent that they all belong to the same company, I wouldn't expect any kind of multiple-accounts-on-the-same-IP abuse prevention mechanism to be involved.

One additional detail: about a week ago, all accounts were required to be associated with a phone number. This wasn't a problem for us, just a bit inconvenient. I'm curious whether that was a new requirement rolled out broadly, or if it may have been related to our particular setup.

Notably, none of the affected accounts were logged out of chatgpt.com itself. The issue appears to be isolated to Codex usage.

I can't say with certainty that codex-lb is the cause, but at the moment it seems like a plausible suspect.

What did you expect to happen?

Ideally, never need to re-auth. But I'd be content with the roughly once-a-month dance. Several times a day is not sustainable.

Steps to reproduce

1. Do re-auth in codex-lb. With this version, double accounts doesn't seem to be created anymore. Yay!

2. Use Codex CLI / OpenCode lightly for a few hours.

3. Codex-lb reports account needs to re-auth.

Relevant logs

# Persisted request log, before pod recreation
2026-06-24 10:20:11.273698 acct=<account-row-F> model=gpt-5.5 status=error error=invalid_api_key msg=Your session has ended. Please log in again.

2026-06-24 10:20:15.323226 acct=<none> model=gpt-5.5 status=error error=no_accounts msg=No available accounts. Service is operating in degraded mode: all upstream accounts are unavailable
# App/container logs
2026-06-24T13:59:58.725441409Z WARNING app.core.clients.usage Usage fetch failed request_id=None status=401 code=token_revoked message=Encountered invalidated oauth token for user, failing request

2026-06-24T13:59:58.900379137Z WARNING app.core.auth.refresh Token refresh failed request_id=None status=401
# Read-only DB metadata query, with account IDs anonymized
chatgpt_account_id=<same-chatgpt-account> count=6 account_rows=<account-row-A>,<account-row-B>,<account-row-C>,<account-row-D>,<account-row-E>,<account-row-F>
statuses=active,active,reauth_required,active,active,reauth_required

suffix=<account-row-C> status=reauth_required last_refresh=2026-06-24 13:18:04.514703 reason=Refresh token was revoked - re-login required
suffix=<account-row-F> status=reauth_required last_refresh=2026-06-19 07:32:39.686384 reason=Refresh token was revoked - re-login required
The key point to include: multiple stored account rows share the same underlying chatgpt_account_id; two rows ended up reauth_required due to revoked refresh tokens, and the logs show token_revoked / invalid_api_key around the forced re-auths.

Configuration / environment

My setup is based on the docker compose examples, adjusted to work in Kubernetes.

Additional context

I asked GPT to try to find a fix given my specific logs and checked out 1.20.1 codebase. It said a lot of things, but I couldn't make out the veracity of its suggestions. I probably lack enough knowledge of codex API to make a good contribution here. I'll post its output here for reference:

Current Diagnosis
The shared chatgpt_account_id is probably expected. The real issue looks like two codex-lb behaviors around reauth/session handling:
1. Re-authenticate is not row-specific.
frontend/src/features/accounts/components/account-actions.tsx calls onReauth with no account ID, and accounts-page.tsx just opens the generic OAuth dialog. Backend OAuth persistence in app/modules/oauth/service.py chooses the target row from token claims: upstream account ID plus email/workspace. So clicking reauth on row A can refresh row B if the browser signs into B.
2. HTTP bridge sessions can keep using an account after the DB row is marked reauth_required.
Normal selection is correct: load_balancer.py excludes REAUTH_REQUIRED, DEACTIVATED, and PAUSED, and permanent failures invalidate the selection cache. But HTTP bridge reuse checks the in-memory session.account.status == ACTIVE, not the DB row. A background usage/auth refresh can mark the DB row reauth_required without updating already-open bridge session objects.
Live Evidence
- All six shared-upstream slots are currently active again because two more reauths happened at 16:49 and 16:51.
- At 13:59:27, a prompt-cache bridge session was created for account suffix 4737cbcd.
- At 13:59:58, logs show:
- Usage fetch failed ... status=401 code=token_revoked
- Token refresh failed ... status=401
- After that, the same bridge key/account suffix 4737cbcd kept being reused at 14:00+.
- Earlier DB evidence showed 4737cbcd became reauth_required, which matches the token refresh failure timing.
- Live dashboard setting http_responses_session_bridge_prompt_cache_idle_ttl_seconds=3600, so prompt-cache bridge sessions can survive up to an hour.
Likely Root Cause
OpenAI/upstream invalidated multiple stored refresh/session tokens for distinct local email slots under the same upstream chatgpt_account_id. codex-lb then correctly marked rows as needing reauth, but existing HTTP bridge sessions could continue using stale in-memory account snapshots. Separately, the UI made reauth confusing because it does not target the selected row.
Recommended Fixes
1. Close or evict HTTP bridge sessions whenever an account is marked reauth_required or deactivated.
2. Revalidate session.account.id against the DB before HTTP bridge reuse, or maintain an account-status generation/invalidation hook that bridge sessions observe.
3. Make reauth targeted: pass accountId through OAuth start/manual-callback and reject the callback if the signed-in identity does not match the selected row.
4. If targeted reauth is not implemented yet, change the UI copy from Re-authenticate to something like Sign in with OAuth and warn that it refreshes the account represented by the signed-in browser identity.

[tulnovdl]

Can confirm — all plus/business accounts started asking for re-auth, and 1 pro x5 account got deactivated. All accounts had been working fine for 5+ months, and the pro account for 2+ months.

Not sure if codex-lb is the reason, but it might be.

[nonexphere]

One hypothesis is that they invalidate the token when they detect multiple accounts making requests simultaneously from the same ip.

These issues started for me two weeks ago;.

Then i stopped of using codex-lb and begun using a different method to switch credentials in my codex and one time I was using two accounts in parallel and I had to re-auth.

After that, i used only one account at a time and didn't need to re-auth anymore.

[mikabytes]

Last night just before going to bed I gave OpenCode a big task (through codex-lb). This morning I was logged out from my Android phone, but no re-auth needed on the Codex accounts. I admit it is hard to find the pattern in this.

@nonexphere That is something I was considering, but then I remembered that Business accounts are actually meant to be used this way. I would give that hypothesis more credit for individual accounts.

[mikabytes]

Another two days passed without needing to re-auth. During this time I was only using OpenCode. So I figured, let's see what happens if I remove the auth.json from Codex CLI, and try again. It asked me to login, I picked API key and wrote "123" because I figured codex-lb will just ignore whatever auth I use anyway.

I entered Codex CLI and wrote "Please say hello". It said "Hello!" and immediately, Codex LB shows two of my accounts as needing re-auth. These were the one that said "Hello", and the only other one I had used with OpenCode today.

So there are a few interesting pieces of information gathered here:

1. Something in Codex CLI (through LB) makes re-auth trip.
2. It does not only trip the account being used, but also another unrelated account.
3. The re-auth requirement may be a false positive. If it was truly needed, the model would not have replied "Hello!".

[mikabytes]

Just to be clear: I only used Codex CLI once today, the "say hello" prompt. I did not leave Codex CLI running. I shut it down immediately.

Still, 18 minutes later, a third account was marked as re-auth while I was using it with OpenCode.

So it seems that this single request with Codex CLI has now caused three of my accounts to be marked as re-auth.

I am not re-auth'ing any of them for now, to keep from polluting the test.

[mikabytes]

A short while later, another two accounts were marked as re-auth.

I'm inspecting the code. Seems we leak quite a bit of client data to the servers, such as user agent. If the server sees that all of a sudden I'm using Codex CLI instead of OpenCode, while using the same token, it might rightly invalidate the token as this is not normal usage. Why that would spill over to other accounts, however, I have no explanation for. Perhaps it is being overly protective.

So perhaps what I'm seeing today is mostly evidence of anti-abuse, not necessarily related to my original issue.

[DaanVT86]

Having the same issue... Just using codex cli + codex-lb. Somehow the access tokens seem to be dropped by openai, which doesn't happen when using them without codex-lb in auth.json .

Hope the reason behind this can be found. I haven't yet..

[mikabytes]

I've been working on the second issue (which may or may not be the same as the first issue) for some 8 hours already. Codex LB currently mints fresh OAuth token using a codex_chatgpt_desktop originator. Then, when making normal requests, it will forward whatever user-agent and other fields that the client sends (for me and @DaanVT86 that would be Codex CLI codex_cli_rs originator). This is already revealing to the server that we are messing with the communication. The theory I'm working on now is that when I switch clients, that finally trips the anti-abuse immediately. Perhaps, it invalidates this and any related tokens by IP/account just to be on the safe side.

I hope to have a PR for this ready by day's end. It'll strip client identifying fields and inject codex_chatgpt_desktop everywhere so that originator is congruent across all calls. We should be very careful not to merge it too quickly though as I'm not very confident in this codebase. I place a lot of trust in GPT 5.5 to do my bidding 😄

[mikabytes]

Found that a PR that does some anti-fingerprinting work has already been merged since the v1.20.1 release: #1089

However, the originator is still different from when the OAuth token was minted.

[DaanVT86]

Great that you're willing to dig into this. It's a quite annoying problem especially since it also logs out the browser session and you need to phone-verify the logins every time. I haven't found a pattern yet.. sometimes they stay valid for days, sometimes the tokens get busted every few hours. Funny thing is that is happens with some accounts more often then others (at least my observations are correct).

By the way I'm also using codex desktop trough the cli app server on this host (remote ssh). Not sure if that keeps the cli originator or not?

[bjspi]

This problem drives me crazy as well and I'm really curious if you are onto something and can somehow confirm, so that this could be fixed somehow. It's so damn annoying, it's exactly as you describe - sometimes one, sometimes two, sometimes all of my accounts get "re-auth" at the same time... Sometimes twice a day, sometimes only after 2 or 3 days again ...

[bjspi]

Not sure if this also belongs to the issue described here
#975 (comment)
Especially the code review

I guess this is the biggest flaw in the repo right now that GPT has some counter-measures against using CodexLB. If it's not gonna be fixed there's unfortunately no way of using it further :(

In the meantime will try and use https://github.com/Loongphy/codex-auth/ again even if it's not so convenient because you gotta switch manually, let's see if it helps

[mikabytes]

@DaanVT86 That supports my working theory. Because you also switch between clients, that same OAuth token are being seen by the server with alternating values.

@bjspi Good to know it's a widespread issue because then it's not just my setup, haha. Curious though, what client(s) are you using? If using CLI, or more than one, that would fit you right into the working theory.

main branch on this repo is kind of broken right now. The backend can emit requestKind: "prewarm" in /api/request-logs, but the frontend schema only accepts "normal" | "warmup" | "limit_warmup". So my attempt at fixing this yesterday was blocked by this external bug.

I'm hoping to be able to experiment some more soon.