Coding Agent Stuck in a Loop? When to Start a Fresh Chat

TLDR

Repeated failures call for a new diagnosis, not simply another request to continue.
Recent agent research preserves useful artifacts while discarding accumulated search history.
Compacting a conversation, starting a fresh chat and reverting files solve different problems.

Separate a stuck approach from a broken environment

Keep the useful files and try a fresh conversation when an agent keeps returning to the same failed explanation. First establish whether the explanation is the problem. A missing dependency or expired credential needs an environment fix; removing chat history cannot supply it.

Consider an agent that keeps changing package versions when the real defect is an incompatible API response. That is a reason to revisit its diagnosis. An agent that correctly identifies a missing package but cannot install it faces a different obstacle. Sending “try again” does not tell either agent what should change.

VS Code’s recovery guide recommends obtaining the failed command, the first error and the evidence behind the diagnosis. It also distinguishes repeated failures from a pending question or a terminal command that is still running.

More runtime can mean more refinement of the same idea

In his October 24 discussion of context engineering, Drew Breunig calls persistent fixation on a hypothesis or subtask “context inertia.” His argument extends beyond context length: keeping an agent focused can also make it persist after an approach should have been abandoned.

The Fork-and-Flush paper investigates a structured response. Parallel branches inherit accumulated workspaces but begin with fresh conversational context; the system then continues from the highest-scoring branch. Its evaluation covers 13 research and engineering tasks. The intervention combines branching, context removal and selection, so its results should not be described as the benefit of pressing a reset button alone.

A separate paper, Scaling Discovery Requires Forgetting, reports increasingly small edits as agents accumulate history. Its intervention discards sessions and candidate history, then restarts from the best candidate. Across four tasks, that approach pushed exploration beyond the observed plateaus. Useful output survives even though the search history does not.

Choose between compaction, a fresh chat and file recovery

These actions preserve different things. The practical choice depends on whether the problem lives in the history, the diagnosis or the files.

Situation	Useful action
The approach works, but old output dominates the conversation	Compact while specifying the facts to retain.
Repeated corrections keep returning to a failed theory	Start a fresh chat with the current artifacts and evidence.
The code changes themselves are unwanted	Review and recover the affected files.

In supported VS Code sessions, a new chat shares the folder and code changes without inheriting the other chat’s history. Saved instructions and persistent memory remain. A fresh conversation therefore does not fix a bad requirement that is loaded again from a project instruction file.

Give the next conversation a testable starting point

A compact handoff should distinguish evidence from a theory that happened to dominate the previous run. For example:

Goal: Fix pagination without changing the public response format.
Current state: Changed files and test output remain in the workspace.
Observed: The existing pagination test fails on the same input.
Unproven: The dependency-version explanation has not been established.
Next step: Read the current implementation and diagnose the failure afresh.
Done means: The complete API test suite passes and the change is explained.

This is a handoff example, not a research protocol. The decision to restart should follow the evidence of stalled progress, rather than a universal token threshold. Preserve valid work, separate assumptions from observations, and repair environmental failures directly.