Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   authIssues related to authentication and accountsIssues related to authentication and accounts

   on Sep 18, 2026
2. 84dnnvbdvp-debug commented on Sep 18, 2026

   

   84dnnvbdvp-debug

   on Sep 18, 2026 – with ChatGPT Codex Connector

   More actions

   Current main (7498521d288b9b3b96ffba4eedf089d8d6e06a84) makes this more destructive than an auth.json atomic-write bug, so the minimal fix sketch should move one boundary earlier.

   codex-rs/cli/src/login.rs has clear_existing_auth_before_login(), and both browser ChatGPT login and device-code login call it before starting the replacement flow. That helper calls logout_with_revoke(...).

   The auth manager's logout_with_revoke path first loads the existing stored auth, calls revoke_auth_tokens(...) for it, and then deletes the auth stores. Revocation failure is only warned about; local logout still proceeds. So by the time a later device-code/token exchange fails, the previous login can be gone in two independent senses:

   1. its local credential record has been deleted; and
   2. its refresh token may already have been revoked server-side.

   That means a temp-file + atomic rename at the eventual save_auth site is not sufficient by itself: restoring the old auth.json after failure can restore a credential whose refresh token was intentionally revoked at flow start.

   I would make replacement login transactional at the login lifecycle, not only at the file-write layer: acquire and validate the replacement credentials first while leaving the current auth untouched; persist the replacement successfully to the configured auth backend; only after that commit should any cleanup/revocation of the superseded credential occur (and cleanup failure should not roll back the now-valid replacement).

   A regression that catches the current ordering specifically:

   • seed valid ChatGPT auth A;
   • start codex login --device-auth (and separately browser login), then force a late replacement-flow failure after startup;
   • assert A is still present and has not had its revoke endpoint called;
   • success case: acquire B, make B durably current, then assert cleanup/revocation of A occurs only after B's persistence succeeds;
   • persistence-failure case: if saving B fails, A remains current/unrevoked.

   The same invariant should be exercised for every configured AuthCredentialsStoreMode rather than being expressed only as an auth.json rename property, because the destructive helper is above the storage backend.

   This keeps explicit codex logout destructive while making codex login a replacement transaction instead of logout-then-hope-login-succeeds.
3. trinity0506 commented on Sep 18, 2026

   

   trinity0506

   on Sep 18, 2026

   Author

   More actions

   Thanks — I verified this against main (7498521d288b) and agree that the file-level sketch is the wrong boundary.

   Concretely:

   • codex-rs/cli/src/login.rs:122 — clear_existing_auth_before_login() calls logout_with_revoke(...) and only tracing::warn!s on failure (:128). It runs before the replacement flow in login_with_chatgpt (:147), run_login_with_device_code (:335) and run_login_with_device_code_fallback_to_browser (:386).
   • codex-rs/login/src/auth/manager.rs:979 — logout_with_revoke() loads the stored auth, calls revoke_auth_tokens(...) (failure only warned, :996), then logout_all_stores(...).

   So the superseded credential can be gone in both senses described above, and restoring auth.json on a late failure may restore an already-revoked refresh token. Superseding the "minimal fix sketch" in the issue body with the lifecycle version:

   1. acquire + validate the replacement credentials while the current auth stays untouched and unrevoked;
   2. persist the replacement durably for every AuthCredentialsStoreMode (not as an auth.json rename property);
   3. only after (2) commits, revoke/clean up the superseded credential, and cleanup failure must not roll back the now-valid replacement.

   Field evidence from our side (headless Linux server, codex-cli 0.153.4): after codex login --device-auth was started and the flow failed late at the token exchange (error sending request for url (https://auth.openai.com/oauth/token)), auth.json was already absent while the flow was still running, and codex login status reported Not logged in. We did not capture whether the revoke endpoint was called, so we cannot confirm the server-side half from our logs.

   One adjacent asymmetry worth checking while the invariant is being moved: run_login_with_api_key (codex-rs/cli/src/login.rs:204) does not go through clear_existing_auth_before_login at all — it calls login_with_api_key directly and overwrites the store, i.e. the previous ChatGPT tokens are dropped locally without being revoked.
4. 84dnnvbdvp-debug commented on Sep 19, 2026

   

   84dnnvbdvp-debug

   on Sep 19, 2026 – with ChatGPT Codex Connector

   More actions

   I checked the adjacent paths on current main, and the asymmetry is broader than only --with-api-key.

   run_login_with_api_key calls login_with_api_key directly; that function constructs a fresh AuthDotJson containing only the API key and calls save_auth. Likewise, run_login_with_access_token calls login_with_access_token without clear_existing_auth_before_login; both PAT and agent-identity branches construct a fresh replacement AuthDotJson and then save_auth. So a prior ChatGPT token set is replaced locally on those successful transitions without going through revoke_auth_tokens.

   That suggests the transactional repair should define post-commit cleanup by credential transition, rather than mechanically moving the existing logout_with_revoke call after every successful login:

   • ChatGPT A -> ChatGPT B: acquire/validate B, persist B, then clean up/revoke A.
   • ChatGPT A -> API key / PAT / agent identity: after the new credential is durable, explicitly decide whether A's refresh token should be revoked or intentionally left valid; today the local record is replaced while the server-side token can remain live.
   • API key / PAT / agent identity -> ChatGPT B: preserve the old local credential until B is durable, but there may be no refresh token to revoke afterward.
   • replacement persistence failure: previous local credential remains current and no cleanup/revocation runs.

   I would make those transitions a table-driven regression family across AuthCredentialsStoreMode. The important invariant is still “never destroy the only working credential before the replacement commits,” but the cleanup action is credential-type-specific. Otherwise a fix for the reported destructive ChatGPT re-login path could accidentally preserve the current stale-server-token asymmetry or revoke something that was never revocable in the first place.