When Codex suddenly stops, slows down, or feels unresponsive, it is easy to suspect everything at once.
That usually makes troubleshooting slower.
The simplest way to make progress is to split the problem into three buckets: usage limits, authentication or network issues, and prompt design.
That order is usually the fastest path.
The three main reasons Codex gets stuck
In practice, most Codex failures fit into one of these categories.
- Usage or limit problems
- Authentication or network problems
- Prompt or task design problems
The important point is not to collapse them into one vague idea like "Codex is broken."
The cause is usually easier to find when you separate them.
Check usage and limits first
This is the most common starting point.
What feels like a product issue is often just a usage or limit problem.
Open the usage page first
If you always start from the same place, troubleshooting becomes much faster.
Use the Codex settings usage page first.
If you need the step-by-step order, read How to Check Codex Usage.
Check whether you are close to a limit
Heavy tasks, long threads, and repeated retries can push usage higher than expected.
If Codex suddenly becomes unavailable, this is the first thing to confirm.
Check whether the task flow became too heavy
Sometimes the issue is not one single request.
It is the accumulated weight of a long session.
Authentication and network problems can look like Codex failure
Usage is not the only cause.
External services, APIs, and publishing workflows often fail because of network or permission issues instead.
`ENOTFOUND` means the host is not reachable
If you see ENOTFOUND, the problem is usually connectivity or the host name itself.
In that case, rewriting the prompt will not help much.
`401` and `403` usually point to auth or permission problems
When a workflow touches external APIs or publishing systems, permission problems are common.
That is a different category from Codex quality or usage.
Check basic reachability before running the full workflow
It is safer to confirm that the target can be reached before you run a large task.
The more complex the workflow, the more important this order becomes.
Vague prompts can make Codex look stuck
Codex can appear slow even when it is technically still working.
That often happens when the task is too vague or too wide.
The goal is unclear
Requests like "improve this" or "check what seems necessary" create a large search space.
Codex has to decide too many things before it can act.
The scope is too broad
Even a short prompt becomes heavy if it does not define the files, folders, or decision surface.
Short does not always mean efficient.
There is no clear finish line
If the completion condition is missing, the task tends to expand.
That is why prompt structure matters more than raw prompt length.
If you want to reduce this kind of waste, read Does Shorter Prompting Reduce Codex Consumption?.
A practical troubleshooting order
When you are unsure, fix the order instead of guessing.
- Check the usage page and confirm limits
- Look for network or auth errors like
ENOTFOUND,401, or403 - Review the goal, scope, constraints, and completion condition of the prompt
- Split the task if it is too broad
- Move repeated rules into
AGENTS.md
This order prevents you from overdiagnosing the wrong layer.
Why AGENTS.md reduces repeated failures
If you repeat the same rules in every request, prompts become long and still miss details.
That is why shared rules work better in AGENTS.md.
Typical examples are:
- test commands
- protected paths
- code style expectations
- review priorities
When those rules live in AGENTS.md, each task prompt can stay shorter without losing necessary context.
FAQ
What should I check first when Codex stops working?
What does `ENOTFOUND` mean?
Does a long prompt always make Codex heavier?
Where should repeated team rules live?
Related Articles
- How to Check Codex Usage
- Does Shorter Prompting Reduce Codex Consumption?
- Codex App vs CLI: Which Workflow Fits Better?
Summary
When Codex gets stuck, do not treat every symptom as the same problem.
Split the cause into usage limits, authentication or network issues, and prompt design.
That simple order makes troubleshooting faster, makes prompts easier to fix, and reduces the number of false guesses.