Why is your AI stuck fixing the same bug over and over?

The short answer

Every new prompt lands in a conversation that’s grown more crowded with wrong guesses rather than a fresh read of the bug, and that’s why saying “still broken, try again” stops helping around the third attempt. Every failed attempt, every half-fix, every “that should do it” stays in the same context window, and the model tends to anchor on its own last guess as if it were established fact, even when that guess was wrong from the first prompt. Add a fix scoped to “the whole feature” instead of one function, and each attempt has more surface area to quietly break something else while it’s at it. The loop ends when you stop adding to the same crowded conversation and start over with less for the model to misread.

Why the loop happens

Three things stack on each other, and usually all three are present by the time you notice you’re stuck.

The first is context pollution. Your agent reads the entire conversation before writing anything new, including its own earlier wrong turns. Ask for another fix and it reads a thread where it already committed to a theory about the cause, rather than looking at your code with fresh eyes, and that theory keeps shaping every next attempt even after it’s been proven wrong twice. If the session has already gone through an automatic compacting pass, the pileup of wrong guesses survives that too, just compressed into a shorter summary rather than cleared out.

The second is an unconfirmed diagnosis repeated on a loop. Most agents reach for a plausible fix on the first try without asking to see the full error, the exact reproduction steps, or whether it happens every time or only sometimes. If that first guess is wrong, every attempt after it usually patches the same wrong theory a little differently instead of stepping back to re-examine the actual output.

The third is over-correction from too wide a scope. Asking to “fix the login bug” instead of “fix the null check on line 40 of auth.ts” gives the agent room to touch three files that were never the problem. Now every fix carries a real chance of solving your bug and introducing a new one, which is exactly the pattern behind the 70% wall and a close cousin of prompt fatigue: you’ve stopped circling the bug and started circling your own last five attempts at it.

What the loop actually looks like

A few tells, so you can name it before it eats an afternoon:

• The agent says some version of “this should fix it” three times in a row, for the same error.
• The error message shifts shape slightly each time, a different line, a similar wording, without the underlying problem going away.
• You’ve lost track of what the original bug even looked like. You only remember the last patch.
• The fix works exactly along the path you tested and breaks the moment someone clicks in a different order.
• You undo the most recent change to compare, and the bug from three prompts ago reappears, which means it was never fixed, just buried under the next one.

None of these mean the model got worse mid-conversation. The conversation itself has become the obstacle.

The protocol that actually breaks it

1. Stop sending more prompts into the same conversation. Past four or five attempts on the same bug with no real progress, sending prompt six is exactly the instinct you need to resist.
2. Start a fresh session instead of continuing. In Claude Code, /clear wipes the conversation, including the pile of wrong guesses, while keeping your project files and CLAUDE.md intact. If you’d rather keep the good parts of the session and just undo the recent patches, /rewind restores the conversation and code to an earlier checkpoint instead.
3. Ask for a diagnosis before you allow another fix. Say something close to: don’t change any code yet, explain what’s actually causing this and why. Plan mode exists for close to this exact case, Claude reads and proposes an approach before touching a single file, so a wrong theory gets caught before it becomes another failed edit.
4. Shrink the scope to one file or one function. Smaller scope means less code the agent can plausibly blame, and less code it can accidentally break while it’s in there.
5. Read the actual error output yourself, at least the shape of it. You don’t need to understand every line, just whether attempt six points at the same file and line as attempt one. If it does, the diagnosis hasn’t moved in five tries, and that’s worth saying out loud before you allow a sixth.

Claude Code’s own guidance for fixing bugs efficiently points at the same habits from the other direction: share the actual error, mention the exact command that reproduces it, and say whether it happens every time or only sometimes. All three exist to stop an agent from guessing at a cause it never confirmed.

When it’s not just a stuck loop

Sometimes narrowing the scope and starting fresh still doesn’t close it, because a different problem is wearing the same symptom. If the agent keeps referencing a method, a config key, or a library behavior that turns out not to exist, that’s an AI hallucination: the fix is checking the real documentation, since clearing the session won’t touch it. And if you’re several hours into a first build and every fix ripples into something else you didn’t touch, the real problem may be a codebase that’s grown past what one prompt can safely change at a time. Both are real, and neither one gets solved by sending prompt seven into the same tired conversation.

What Glim would tell you

This is the exact moment Glimfly built Glim for. Glim sits next to your agent and narrates what it’s doing in real time, including the parts that explain a loop before you’ve burned ten prompts on it: which file it’s rereading for the fourth time, whether it’s proposing something new or repeating its last guess with different words. If you want the rest of the vocabulary this guide leans on, the dictionary is the place to keep digging.