Codex CLI not working? Work down this list
Ordered by how often each one is actually the culprit — start at the top.
Most “Codex is broken” moments are not outages. They are an expired token, a corporate proxy, or a version that drifted three releases behind. This checklist is ordered by how often each cause turns out to be the real one, so working top to bottom is genuinely the fastest route.
0. Rule out an actual outage (5 seconds)
Check the live Codex status. If it says Codex is down, stop here — nothing below will help, and you can leave your email to get pinged when it recovers. If it says Codex is up, carry on.
1. Your login has expired
By far the most common cause, and the one with the most misleading error messages. Sessions expire, tokens get rotated, and a stale credential often surfaces as a connection failure rather than an honest “please log in again”. Sign out and sign back in before you debug anything else.
2. You have hit a usage limit
Instant failure, every time, with wording about quota or limits? That is your account, not the service. This is common enough that it has its own page: Codex rate limits — why you hit them and when they reset.
3. A proxy, VPN or firewall is in the way
The giveaway is that your phone on mobile data works fine while your work laptop does not. Corporate TLS inspection is especially good at breaking streaming connections specifically — so the CLI starts, then hangs the moment output should begin.
- Try the same command with the VPN off.
- Tether to your phone as a control test.
- If your organisation requires a proxy, make sure the CLI is actually configured to use it rather than silently bypassing it.
4. Your CLI is out of date
Codex ships fast. An older client can break against a changed API surface without any announcement, and the resulting errors rarely say “you are out of date”. Update before you investigate further — it is cheap, and it resolves a surprising share of one-off breakages.
5. It works, but it is agonisingly slow
This is the partial-degradation case, and it is the one people misdiagnose most. Requests succeed, but slowly enough that a client-side timeout fires and reports a failure. If our status page shows KINDA, this is exactly what you are experiencing, and the fix is patience rather than configuration.
6. The run dies at the same point every time
Not a network problem. If a long agent run consistently fails at roughly the same stage, you are running out of context rather than connectivity. Narrow the task, point the agent at specific files instead of letting it explore, and start a fresh session.
7. Something in the repository is the problem
Occasionally the environment, not the service, is at fault — a huge untracked directory the agent tries to read, a permissions problem, or a config file with a typo. A quick control test: run the same command in a small scratch directory. If that works, the problem is local to your project.
Still stuck?
If you have worked through all of the above and it still fails on two different machines and two different networks, it is reasonable to conclude something is genuinely wrong upstream even if the status feed has not caught up — status pages lag real incidents, often by many minutes. The outage history is useful here: if an incident has just been opened, you will see it there.
Related
- Codex rate limits: why you hit them and when they reset
- OpenAI status vs Codex status: why they disagree
- Codex outage history
- Embed a live Codex status badge
Not affiliated with, endorsed by, or sponsored by OpenAI. OpenAI and Codex are trademarks of OpenAI. This is community troubleshooting, not official support — see OpenAI's help centre for that.