Claude Code not working? Work down this list
Ordered by how often each one is actually the culprit — start at the top.
Most “Claude is broken” moments are not outages. They are an expired session, a corporate proxy, or a CLI that drifted several 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 status. If it says Claude is down, stop here — nothing below will help, and you can leave your email to get pinged the moment it recovers. If it says Claude is up, carry on.
1. Your login has expired
By far the most common cause, and the one with the most misleading errors. Sessions expire and tokens rotate, and a stale credential often surfaces as a connection failure rather than an honest “please log in again”. Sign out and back in before debugging anything else.
2. You have hit a usage limit
Instant failure, every time, with wording about usage or limits? That is your account, not the service — and Claude Code consumes budget far faster than chat does. Details: Claude usage limits — why you hit them and when they reset.
3. A proxy, VPN or firewall is in the way
The giveaway: 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 and 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, check the CLI is actually configured to use it rather than silently bypassing it.
4. Your CLI is out of date
Claude Code ships very frequently. An older client can break against a changed API surface with no announcement, and the resulting errors rarely say “you are out of date”. Update first — it is cheap and resolves a surprising share of one-off breakages.
5. It works, but it is agonisingly slow
The partial-degradation case, and the most misdiagnosed one. Requests succeed, but slowly enough that a client-side timeout fires and reports failure. If our status page shows KINDA, this is what you are experiencing, and the fix is patience rather than configuration.
6. The session dies at the same point every time
Not a network problem. If a long 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
Sometimes the environment, not the service, is at fault — a huge untracked directory the agent tries to read, a permissions problem, an MCP server failing to start, or a config file with a typo. Control test: run the same command in a small scratch directory. If that works, the problem is local to your project.
8. An MCP server is hanging, not Claude
Worth its own entry because the symptom is so misleading. A misconfigured or unreachable MCP server can stall startup entirely, which looks exactly like the service being unresponsive. Disable your MCP servers and try again — if it springs to life, you have found it.
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
- Claude usage limits: why you hit them and when they reset
- Anthropic status vs Claude status: why they disagree
- Claude outage history
- Embed a live Claude status badge
Not affiliated with, endorsed by, or sponsored by Anthropic. Claude and Anthropic are trademarks of Anthropic. This is community troubleshooting, not official support — see Anthropic's help centre for that.