Skip to content

[Feature]: Allow re-authentication / replacement of an expired pool account instead of blocking with "Account is already in the pool" #4066

Description

@nordz0r

Area

Authentication and account pool

What are you trying to accomplish?

Re-authenticate a Codex pool account that has expired or dropped its session (e.g., token revoked, session expired), so that the account becomes usable again without having to delete it from the pool first.

What prevents this today?

When a pool account expires and the operator tries to log in again via the WebUI (or CLI) using the same account credentials, checkAccountIdCollision (src/codex/auth-collision.ts) sees that the chatgptAccountId already exists in the pool config and rejects the login attempt with:

Account is already in the pool (chatgpt-...)

The only workaround today is a destructive 2-step process:

  1. Delete the expired account from the pool.
  2. Re-add it via a fresh login.

This destroys the account's usage history, quota recovery state, manually configured priority/strategy settings, and pool labels.

What should OpenCodex do?

When a login flow completes and checkAccountIdCollision detects that the account already exists in the pool, it should check if the existing pool account's session is expired, invalid, or being explicitly re-authenticated. Instead of aborting the flow with a collision error, OpenCodex should update the existing account in-place with the new credential/tokens, preserving its id, usage history, and configuration.

If an operator explicitly clicks "Re-authenticate" (or runs an equivalent CLI command), the collision check should be bypassed entirely for that specific account ID, or the merge logic should just overwrite the token material.

Example usage or interface

  1. Dashboard shows a pool account as Expired / Needs re-authentication.
  2. Operator clicks "Re-authenticate" on that account card.
  3. OAuth/Device flow completes.
  4. Instead of Account is already in the pool error, the UI says Account re-authenticated successfully and the token is updated. History and routing settings remain intact.

Alternatives or workarounds

  • Deleting the account and re-adding it — loses all historical usage data, manual aliases, and pool configuration.
  • Manually editing auth.json / config.json on the filesystem — error-prone and defeats the purpose of the management API.

Additional context

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions