Hi! I have a question regarding the restriction that prevents switching accounts while codex instances are currently running.
The Problem / Use Case:
Account limits often get exhausted before Codex finishes its tasks. Because of the current restriction, users have to wait until an active instance completely finishes its work before they can switch to another account. Meanwhile, other instances cannot continue working because they are already hitting the rate limits of the currently selected account.
Technical Question:
Is this restriction strictly necessary by design?
- If running instances periodically check authorization or read the token from disk (e.g., from
auth.json) on every single request, then locking the account switch makes perfect sense to prevent token conflicts or auth errors.
- However, if each instance loads the token into memory only once at startup and uses it for its entire lifecycle, then preventing an account switch in the UI/app seems unnecessary.
Proposed Solution:
If the tokens are only read at initialization, would it be possible to remove this restriction? Alternatively, you could introduce this as an experimental feature (e.g., a toggle "Allow unsafe account switching") to let us test this behavior in production. This would significantly improve the workflow when dealing with strict account limits.
Thanks!
Hi! I have a question regarding the restriction that prevents switching accounts while
codexinstances are currently running.The Problem / Use Case:
Account limits often get exhausted before Codex finishes its tasks. Because of the current restriction, users have to wait until an active instance completely finishes its work before they can switch to another account. Meanwhile, other instances cannot continue working because they are already hitting the rate limits of the currently selected account.
Technical Question:
Is this restriction strictly necessary by design?
auth.json) on every single request, then locking the account switch makes perfect sense to prevent token conflicts or auth errors.Proposed Solution:
If the tokens are only read at initialization, would it be possible to remove this restriction? Alternatively, you could introduce this as an experimental feature (e.g., a toggle "Allow unsafe account switching") to let us test this behavior in production. This would significantly improve the workflow when dealing with strict account limits.
Thanks!