Debugging a stuck Claude Code session

"Stuck" is not one problem

A session that feels stuck can mean several genuinely different things, and the fix depends entirely on which one you're actually looking at: a session repeating the same failed approach in a loop, a session that's technically still working but has drifted so far from the original ask that continuing feels pointless, or a session that's simply slow because of how much context it's carrying at this point in a long conversation. Treating all three the same way — usually by just waiting longer or restating the request more forcefully — fixes none of them reliably.

The repeating-failure loop

The clearest sign of this one is Claude trying essentially the same fix, worded slightly differently, after it's already failed once or twice. This usually means the actual problem is outside what's currently visible in context — a piece of information that would resolve the ambiguity exists, but it isn't in front of the model, so each attempt is a guess dressed up as a fix. The move here isn't to keep letting it retry; it's to interrupt and supply the missing piece directly — an error message in full rather than paraphrased, a file that's relevant but wasn't read yet, a constraint that was assumed rather than stated.

Context drift on a long task

A session that's been running a long time on an evolving task can end up acting on an understanding of the goal that's several turns out of date, even though nothing was ever explicitly wrong at any single step — it just accumulated small deviations that compound. This is different from a repeating failure because there's no visible error; the session just feels like it's solving a slightly different problem than the one you actually have now. Restating the current goal plainly, rather than trusting that it's still correctly held in context from several turns back, resolves this faster than continuing to react to symptoms of the drift one at a time.

When the real problem is context volume, not the task

A long session that's read many files and run many commands is carrying all of that history, and past a certain point that volume itself becomes the problem — not because any single piece of it is wrong, but because relevant information gets harder to weight correctly against everything else competing for attention. This tends to show up as answers that feel less sharp than they did earlier in the same session, on a task that hasn't actually gotten harder. Clearing unnecessary history, or starting a fresh session with a tighter, deliberately curated context, often fixes this faster than any amount of additional prompting inside the same bloated session does.

When to just stop and restart

Not every stuck session is worth debugging in place. If you're several failed attempts into a repeating loop, or a session has drifted far enough that reconstructing what it currently believes the task to be would take real effort, restarting with a clean, precisely-stated task description is often genuinely faster than continuing to steer the existing session back on course. There's no sunk cost in a conversation's history — the time already spent doesn't make continuing the right choice if a fresh start would resolve it faster.

A habit that prevents most of this

Sessions get stuck less often when the initial task description is specific from the start — naming the actual constraint, the actual file, the actual error, rather than a general description that leaves the model to infer the missing specifics itself. Most of what looks like a session "getting stuck" traces back to an ambiguity that was there from the first message and only became visible once a few failed attempts made it obvious.