[Bug]: Authentication switching issues on codex #11136

Activity

1. AstroZer01

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 10, 2026
2. juliusmarminge commented on Sep 10, 2026

   

   juliusmarminge

   on Sep 10, 2026

   Member

   More actions

   Thanks for the report — this looks real, and the restart workaround is a strong signal.

   What we think is happening

   Codex login is not an in-app OAuth flow. Settings “Authenticated” comes from a short-lived codex app-server status probe that reads the current auth.json. Existing threads keep a long-lived app-server process and reuse it for later messages (until Stop, a T3 restart, or the ~30 minute idle reaper).

   So after you sign into another Codex account:

   1. Settings re-probes and shows the new account.
   2. Threads that already have a live Codex process keep the old tokens and can still hit that account’s usage limit.
   3. Restarting T3 kills those processes; the next turn starts a fresh app-server and the new login works.

   That is the same shape as Claude #9607 / #11048 (CLI loads credentials once per process; T3 keeps the process).

   This is not the same as switching between two configured Codex instances in the model picker (shadow-home / CODEX_HOME setup in the Codex provider docs). Those threads stay bound to the instance they started on unless you pick the other account. A restart alone would not rebind them.

   Workaround

   After changing the Codex login, Stop the affected thread (or restart T3), then send again. A new thread also picks up the new account immediately.

   Fix direction

   When a Codex provider refresh reports a different account identity than the live sessions for that instance, stop those sessions so the next message respawns app-server with current credentials. account/updated is already on the wire but does not trigger that today.

   To confirm the path

   Please add, if you have them:

   • T3 version / desktop vs npx t3
   • Whether you ran codex login on the same Codex home, or added a second Codex instance (shadow home)
   • Whether the thread’s model picker still showed the same Codex instance after the switch
   • The usage-limit error text from the thread

   Accepting as a bug.
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 10, 2026
4. AstroZer01 commented on Sep 10, 2026

   

   AstroZer01

   on Sep 10, 2026

   Author

   More actions

   I just installed t3 so i am unfamiliar on how to see the version it is on, but it is on the latest one as of sending this message.
   I am using both desktop and npx t3 for connecting to my server.
   Both codex login and codex login --device-auth
   Just used normal codex directory, ( couldnt understand shadow home to get it to work yet )
   Just normal codex ran out of usage error that i used to identify that the accounts wherent switched since i switched from one that had ran out of usage to one that had 100% usage, not really important to the issue.
   Just worth mentioning because if i hade usage on both accounts i wouldnt know that it didnt switch the authenticated accounts correctly.
5. Gigioxx

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

   fix(codex): pick up a new login without restarting T3

   ...

   This issue will close once commit 8d3035d is merged into the 'main' branch.

   8d3035d
6. faetschi commented on Oct 13, 2026

   

   faetschi

   on Oct 13, 2026

   Last edited by faetschi

   More actions

   Confirming this on the current T3 nightly version:

   System / version

   • T3 Code: Nightly 0.0.46-nightly.20261013.3053 — Windows desktop app (x64)
   • OS: Windows 10
   • Codex CLI: 0.160.1 (codex login status → "Logged in using ChatGPT")
   • CodexBar: 0.70.0

   Answers to the confirmation questions

   1. Desktop app (Windows), single default Codex provider.
   2. Yes — codex login against the same default Codex home (~/.codex and/or %USERPROFILE%\.codex); no shadow home in the current setup. I also sometimes switch via CodexBar.
   3. Yes — the thread's model picker still showed the same (default) Codex instance after the switch.
   4. The affected chat kept showing Usage limit reached / Reset time unavailable; retry manually, while Settings / Usage showed the newly signed-in account at ~98% remaining (2% used).

   Reproduction (current, single default provider)

   1. Work in a thread on Codex account A until it hits its limit; the thread shows the usage-limit banner and the composer is blocked.
   2. Switch to account B with codex login (or CodexBar).
   3. Settings / Usage shows account B authenticated with ~98% remaining.
   4. Back in the same chat, the limit state does not update — it still reflects account A, so the thread stays stuck.
   5. Fully restart T3 Code, then continue in the same chat: it runs on account B with fresh usage and no handoff, preserving the native Codex session.

   This matches your diagnosis exactly: the long-lived codex app-server process keeps the old tokens until a restart. Stopping the thread also works as a lighter workaround.

   Additional data — two-provider attempt (related: #16613)
   Before this, I tried adding account A and account B as two separate Codex provider instances with the default provider disabled. That did give per-account provider switching, but:

   • switching instances mid-thread fell back to a portable T3 context handoff instead of resuming the native Codex thread ([Bug]: Switching compatible Codex accounts with shared CODEX_HOME uses portable handoff instead of native thread resume #16613), and
   • it repeatedly required re-syncing the codex login, leading to failed chats (this is the [Bug]: Switching compatible Codex accounts with shared CODEX_HOME uses portable handoff instead of native thread resume #16613 path, not the login-switch path above)

   I reverted to one default provider + external CLI/CodexBar switch + restart. So from a user's perspective "use two Codex accounts and switch when one runs out" is close, but the switch only takes effect after a restart and the two-instance path degrades to a handoff.