Cursor Agent Stuck in a Loop Fix

A loop almost always means the agent cannot verify its own work. It made a change, it has no way to confirm the change worked, so it tries the same fix again. Cursor's agent reads each tool result before it picks its next step, and that read-then-decide cycle is what turns one bad signal into a repeating one. Take away whatever separates a working change from a broken one, and every read comes back with the same non-answer, so every next step looks a lot like the last.

The four causes below all come back to that hole. Only the first is a loop in the strict sense. There is nothing to check against, so it retries forever. The other three hand the agent a wrong picture of the task instead of a blank one, and from outside the thread the two are hard to tell apart.

• No way to verify success. Without a test or command it cannot tell it is done.
• Unclear task. The goal or constraint is ambiguous.
• Noisy or overflowing context. The correction got buried.
• A genuinely blocked step (failing command, missing dependency) it keeps re-trying.

The blocked step is worth separating from the first three, because it is not really the agent's fault. A missing dependency fails the same way on the fifth attempt as on the first, and nothing in that output tells a wrong edit apart from a machine that never had the package. So it edits again. And again.

That one you have to clear yourself.

Stop the run before you type anything else. Order matters here more than the individual steps do. Every failed attempt is still sitting in that thread, so a correction sent into it arrives alongside several worked demonstrations of the wrong approach. Starting clean costs you one re-typed prompt and clears the lot.

A checkpoint restore reaches the same clean state without leaving the thread, and the clip below runs that flow.

1. 1Stop the agent and start a fresh chat.
2. 2Give it a concrete success check ("run these tests; stop when they pass").
3. 3Narrow the task to one clear step.
4. 4Fix the underlying blocker (install the dep, correct the command) yourself, then resume.

Skipping the success check is what turns this into a repeat visit. Narrow the task without one and you get a smaller loop, probably a more convincing one, because there is less room left for the agent to be visibly wrong. A check with no narrowing is still worth having, though you will watch the agent range across files hunting for anything that turns it green.

The order I just gave holds right up until the loop is a failing install. Then step four outranks the three above it, and stopping the run is the only part that still comes first. Nothing else on the list helps when the package was never there. You get a clean thread, a clear success check and the same red output. Run the command yourself before you re-prompt. If it fails for you too, that failure is the task.

A good success check is a command the agent can run on its own, with an outcome it can read without asking you. "Run the auth tests and stop when they pass" qualifies. "Make sure it works" does not. Neither does a careful description of the correct behaviour, because none of them give the agent a moment where it gets to observe that it has arrived.

Watch for the version of this where the agent writes the check as well as the code. You are then grading the work with a marker the same model made, and AI-written tests have a habit of logging a failure instead of calling the framework's fail(), or wrapping the assertion in a try-catch that swallows it.

A test like that passes for the wrong reason, the agent stops, and you find out a few commits later.

Write the check yourself where you can. Though on a small team with nothing that deserves to be called a test suite, that advice runs out fast. Any command whose output you recognise will do the job. The build compiling. A route that returns 200 instead of a stack trace. The check does not have to be a test, it has to be observable, and the agent has to be told to run it.

A second loop on a clean thread usually means the task is harder than the prompt made it sound. It is only usually, though. A fresh chat throws away context as well as noise, and if the part you dropped was the constraint that mattered, the second loop is telling you about the reset.

Which escalation you reach for depends on what the agent is missing. Plan Mode suits an under-specified task, where it needs to research before it edits. Debug Mode suits the task where it cannot see what happens at runtime.

Plan Mode returns an explicit list of steps and files before any code is written, and it farms context aggressively up front, so a wrong approach shows up in a plan you can read in seconds, before it becomes a multi-file diff you have to unwind. Prune the to-do list it hands back. That pruning step is easy to skip. Maybe because a returned plan looks finished, and reading it line by line feels like the slow option.

Guessing wrong twice in the same chat is one of the four cases Debug Mode is documented for, and it is the case you are in. Debug Mode generates four or five hypotheses from your description, instruments the code with log lines that POST JSON to a local server, waits for you to reproduce the bug, then works from what the run actually recorded. ⇧+⇥ cycles the modes, and the instrumentation comes back out once the fix is confirmed.

Neither one is a guarantee. When a loop survives a plan and a real repro, I stop blaming the prompt, do the first step by hand and give back the smaller remainder.