If you run the Codex CLI hard enough, you will meet the 429. A long autonomous session, a big refactor, or a second agent running in parallel can push one account into a rate limit right in the middle of useful work. Codex Multi-Auth is an open source tool built for exactly that moment. It pools several ChatGPT accounts behind a loopback proxy for the official Codex CLI, picks the healthiest account for each request, and fails over automatically when one account hits a limit, so your session keeps running instead of stopping at the first 429.
Key Takeaways
Codex Multi-Auth is an open source account pooler for the official Codex CLI, not a replacement for it.
Its loopback proxy rotates multiple ChatGPT accounts, refreshes tokens, and fails over on rate limits within a bounded retry budget.
It runs only through its wrapper (codex-multi-auth-codex or mcodex) or an opt-in desktop app bind. It never installs or shadows a plain codex binary.
You need Node.js 22.19 or later and the official Codex CLI on PATH. Accounts are stored locally, with files at 0600 and directories at 0700.
At the time of writing it has 560 stars, 74 forks, and 2,253 commits, with version 2.24.0 as the current stable release.
Rotation helps with quota limits, but it does not make pooled accounts terms-proof. The project itself says it is intended for personal development use.
Watch the 30-second repo signal
What Codex Multi-Auth Actually Is
Codex Multi-Auth, by ndycode, describes itself as a "Codex CLI multi-account OAuth manager with account switching, health checks, runtime rotation, diagnostics, and recovery tools for @openai/codex". In plain terms, it is a manager for several ChatGPT logins that the Codex CLI can draw on, instead of being tied to a single account for a whole session.
That distinction matters. The official Codex CLI, by OpenAI, is a lightweight coding agent that runs in your terminal, with 132,273 stars at the time of writing, and OpenAI recommends signing in with a ChatGPT account under a Plus, Pro, Business, Edu, or Enterprise plan, or using an API key with additional setup. Codex Multi-Auth does not replace any of that. It sits in front of the official tool, manages the accounts, and hands Codex a working login for each request.
The project is not brand new. The repository was created on 2026-02-22, it is MIT licensed, and it has 73 releases, which suggests steady maintenance rather than a one weekend experiment. At the time of writing it has 560 stars and 74 forks, so it is a niche tool with a real user base, not a mainstream utility.
How the Proxy and Rotation Work
The core idea is simple, and the implementation is where the value sits. Codex Multi-Auth runs a loopback-only proxy, meaning the proxy listens on your own machine, not on the network. When you run Codex through the wrapper, requests go through that proxy, which picks an account from your pool.
Step | What happens |
|---|---|
Pick | The proxy picks the healthiest account for the request, by default |
Refresh | It refreshes tokens as needed, so a stale login does not kill a session |
Fail over | On a rate limit, it switches to another account in the pool |
Bound | Retries stay within a bounded retry budget, so it does not loop forever |
Recheck | A local rate-limit block is valid for at most 1 hour before it rechecks upstream |
Two details are worth noting. First, the tool also has a Luna Reserve fallback that kicks in after a genuine Luna quota 429, which is a second safety net when the main pool is exhausted. Second, rotation only works inside the wrapper or an opt-in desktop app bind. If you run plain codex directly, you get plain single-account Codex, untouched. That restraint is a feature: the tool never installs or shadows a codex binary, so uninstalling it leaves your normal setup alone.
The tool ships with 31 subcommands and 4 binaries: codex-multi-auth, codex-ma, the codex-multi-auth-codex wrapper, and the mcodex launcher. That command surface covers account management, health checks, diagnostics, and recovery, not just the proxy itself. If an account stops working, you can diagnose it rather than guessing which login broke.
Why 429 Errors Are Not Always "Out of Quota"
It is tempting to read every 429 as "this account is used up", but the reality is messier, and that matters for what rotation can and cannot fix. OpenAI explains that a 429 means the rate limit was exceeded, and that limits exist to prevent abuse, ensure fair access, and manage aggregate load. Its worked example shows a Codex-related limit of 20 requests per minute being exceeded at 24 per minute. That is throttling, not a ban.
A real report from October 2026 makes the nuance concrete. In openai/codex issue 55964, published 2026-10-21, a user on Codex CLI 0.146.0 with ChatGPT-account auth hit repeated 429 errors with the code turn_rate_limit_exceeded and the message "Codex is at capacity, please try again later", with a Retry-After of 152 seconds, even though their account usage checks did not show an exhausted allowance. A small request to a different model succeeded. In other words, capacity and model-specific limits can trigger a 429 even when your quota looks fine, and rotating to another account on the same overloaded model may not help as much as switching models or waiting.
That is the honest frame for this tool. Rotation is a strong answer to per-account quota limits, and a partial answer to capacity limits. It keeps a session moving when one account is throttled, but it cannot conjure capacity that does not exist.
What You Need to Run It
Setup is straightforward if you already use the Codex CLI, and it is deliberately local. Nothing about the pool needs a remote server.
Requirement | Detail |
|---|---|
Node.js | Version 22.19 or later |
Codex CLI | The official CLI installed and on PATH |
Accounts | Multiple ChatGPT accounts, each logged in through the tool |
Storage | Local only, under ~/.codex/multi-auth, files 0600, directories 0700 |
Entry point | Run through codex-multi-auth-codex or mcodex, not plain codex |
The local storage detail deserves a pause. Any tool that holds OAuth tokens for several accounts is a high-value target, and the project's file permissions (0600 for files, 0700 for directories) are the right baseline. The wider ecosystem shows why that caution is not theoretical. Aikido Security reported in May 2026 that an unrelated package quietly exfiltrated the entire ~/.codex/auth.json on every invocation, including a refresh token that does not expire. That package is not Codex Multi-Auth, and nothing in that report implicates it, but the lesson transfers: install the exact published package from the official repo, check what you are running, and never paste a token into a lookalike tool.
The Manual Baseline It Replaces
Before tools like this, the workaround for multiple Codex accounts was manual, and it was fiddly. Sanghun Kang described the pattern in October 2026: an alias such as CODEX_HOME="$HOME/.codex2" codex, keeping only auth.json separate and symlinking everything else so history, memory, and skills stay shared while only the login differs. The same post warns that simultaneous use can hit Codex's SQLite lock handling and cause startup failures or temporary stalls, and the author switches accounts when one runs out of usage rather than running both at once.
Codex Multi-Auth removes that manual switching. The proxy decides, per request, which account is healthy, and the failover happens without you stopping, editing an alias, and restarting. For a heavy workflow or an autonomous agent that runs for hours, that difference is the whole point: the session survives a limit instead of waiting for a human to notice.
A comparable tool, shunt's Codex Multi-Account guide, shows the same pattern from another angle: it records the backend's 5-hour and 7-day usage windows and rotates proactively off an account nearing quota, with cooldown-based failover as a safety floor. Quota-aware rotation is becoming an established pattern, not a one-off hack, and Codex Multi-Auth is the most fully featured open source version of it at this scale.
The Terms Caveat You Should Not Skip
Rotation is a technical solution, and terms of service are a separate question. Codex Multi-Auth's own terms section says it is "intended for personal development use", that it is "an independent open-source project, not an official OpenAI product", and that "you are responsible for your own usage and policy compliance", adding that for production or commercial workloads you should use the OpenAI Platform API.
Independent writing on the same point is blunter. Manifest for Devs wrote in July 2026 that a ChatGPT subscription is strictly personal, one subscription for one user, and that sharing breaks the terms, including "account pooling and account rotation, where several people share the same credentials to dodge rate limits". The same post argues that automation such as CI runners and schedulers should run on per-token pricing, not a subscription, because once a system calls the API while you are not in the loop, the usage stops being personal.
Read those two together and the line is clear. Pooling your own accounts for your own personal development work is the use case the project describes. Sharing one account across people, or running unattended production workloads on subscriptions, is a different claim, and rotation does not make it terms-proof. If your workload is commercial or unattended, the Platform API is the path the project itself points to.
Who Should Try It, and Who Should Wait
Codex Multi-Auth makes the most sense for developers who already run heavy Codex sessions and already hold more than one ChatGPT account. If you run long autonomous agent sessions, parallel agents, or back-to-back refactors, and a 429 regularly interrupts you, a pool with automatic failover is easy to justify trying.
It is also a good fit if you like the safety of the design: local-only storage, a loopback proxy, no shadowing of the official binary, and a bounded retry budget that stops the tool from looping forever on a broken account.
You should probably wait, or keep expectations modest, if you only use Codex occasionally, if you have a single account, or if your workload is commercial. With one account there is nothing to rotate to, and with a commercial workload the Platform API is the honest answer, not a pool of subscriptions. And as with any tool that holds OAuth tokens, try it on a machine you control, install it from the official repo, and review what it stores before handing it several logins.
If you work in the same autonomous coding world, the site has a related spotlight on a tool that builds and tests Xcode apps for you: AgentSwift: The Open Source AI Coding Agent That Builds and Tests Your Xcode App for You. Pairing a tool that keeps your agent running with a tool that checks what it built is a sensible combination.
Frequently Asked Questions
Is Codex Multi-Auth an official OpenAI tool?
No. It is an independent open source project, MIT licensed, and it is not an official OpenAI product. It wraps the official Codex CLI without modifying its binary.
Does it replace the Codex CLI?
No. You still need the official Codex CLI installed and on PATH. Codex Multi-Auth manages accounts and routes requests through its proxy; the official CLI does the actual coding work.
What happens when every account in the pool hits a limit?
Failover stops helping once the pool is exhausted. Retries stay within a bounded budget, local blocks are rechecked after at most 1 hour, and the Luna Reserve fallback covers a genuine Luna quota 429. Beyond that, you wait for quota to reset, just as you would with one account.
Is it safe to give it several ChatGPT logins?
It stores accounts locally under ~/.codex/multi-auth with files at 0600 and directories at 0700, and its proxy is loopback-only. That is a sound baseline, but any credential-holding tool deserves care: install it from the official repo, verify the package, and keep it on a machine you control.
Does account rotation get around OpenAI's terms?
No, and the project does not claim otherwise. It says it is intended for personal development use and that you are responsible for policy compliance. Sharing accounts across people or running production workloads on subscriptions is a different matter, and the project points commercial users to the Platform API.