What to do when your AI coding agent gets stuck in a loop

The agent's fourth attempt looks a lot like its first.

Same file, same three lines, a slightly different arrangement of the same idea. Between each attempt it announces it has found the real problem this time. The test still fails. Twelve minutes of confident progress, ending exactly where it started.

Every agent does this. It isn't stubbornness and it usually isn't a bad model: it's a feedback problem. Once you can see the shape of it, you can break one in about thirty seconds.

Why agents circle

An agent chooses its next move from what came back last. When the signal doesn't change, neither does the plan, so it tries another variant of the same fix, because nothing it can see has ruled that fix out.

Three things flatten the signal:

• The error it can see isn't the error that matters. It's reading one assertion out of a suite, or a wrapped exception three layers from the cause.
• Its own failed attempts are now the context. Twenty tool calls in, most of what the agent can read is its own wrong reasoning, and every pass re-weights it as evidence.
• The tree is a pile of half-fixes. Attempt two landed on top of attempt one; by attempt four it's debugging a codebase nobody wrote on purpose.

The three loops you'll actually meet

The whack-a-mole loop. Fixing A breaks B, fixing B breaks A. The agent is patching symptoms around a cause it never located, the failure mode behind most debugging sessions that go nowhere.

The false-signal loop. A stale build, the wrong test command, a cached fixture. The code changes, the output doesn't, and the agent concludes its fix was wrong. The fix was fine. The feedback was broken.

The amnesia loop. In a long session it fixes something, drifts, and quietly undoes it forty tool calls later, then rediscovers the original bug and fixes it again. That's a context problem, not a reasoning one.

Spot it in two attempts, not ten

The tell is simple: if the second attempt doesn't change the error, the third won't either.

Watch for identical error text between runs, the same file edited a third time, and language that gets more certain as results stay the same. "Ah, now I see the actual issue" gets less true every time you read it.

So set the budget before you start: two failed attempts at the same error, and you intervene. Not because the agent can't get there: from here it's rehearsing, and you're paying per rehearsal.

Break it by changing the information

"Try again" and "think harder" add nothing; the agent already believes it's trying. To break a loop you have to change what it can see.

• Hand it the output it's missing. The full stack trace, the raw command output, the actual log lines, not your summary. A lot of loops end the second the agent sees the layer it was guessing about.
• Reset the tree first. git checkout . before the next attempt. One clean fix against known code beats a fifth patch stacked on four bad ones.
• Make it reproduce before it edits. A failing case it can run turns "does this help?" into a yes or no.
• Restart the session. The one people skip, because it feels like throwing work away. A fresh session with two sentences of what you learned (including which fixes are dead ends) beats the poisoned one nearly every time. And restart means restart: resuming the session just reloads the poison.
• Shrink the task. A loop is often a task that was too big telling you so.
• Change models. Some walls are reasoning walls. Route the brief to a stronger model rather than asking this one a sixth time.

Sometimes the loop is telling you something

Worth saying plainly: not every loop is the agent's fault.

If your brief holds two constraints that can't both be true (keep the signature stable and add a required argument), there is no fix, and a competent agent will thrash forever looking for one. Loops make a decent contradiction detector: when one starts, re-read the task before you blame the model.

And sometimes the code is the problem: if every fix breaks something else, the abstraction may not support what you asked for. That's a design conversation, not a retry.

Make restarting cost nothing

People let loops run because killing a session feels like losing work. The brief lives in the scrollback, so starting over means retyping the paragraph you wrote twenty minutes ago, and you give it one more go instead. And one more.

SanuDesk is a desktop app that takes that cost away. Your tasks live on a Kanban board next to the agents, so the brief isn't buried in a terminal, it's on the card. Killing a stuck session and deploying the card again is one click, and the new Claude Code, Codex or Gemini session starts clean: the task, and none of the failed reasoning.

Because sessions tile side by side in one grid, you catch a loop with peripheral vision: the pane still editing the same file is obvious from across the screen, long before you'd notice in a tab you weren't looking at. It's bring-your-own-model, so rerouting a stuck task to a different model is a choice, not a migration. And Loops (the good kind) run recurring jobs on a schedule, so chores never become sessions you babysit.

The free tier gets you the board and the grid.

Next time, pick the number first

Before you hand over your next task, decide how many failed attempts you'll watch. Two, three, whatever suits the job. When you hit it, stop the session instead of encouraging it. The fastest fix for a stuck agent is usually a fresh one.

Download SanuDesk free and put your next task on a board, or see how the grid, cards and Loops fit together on the features page.