Kilo Code repeating a failed action? Stop and compare the diff.

A repeated tool action can obscure what changed between attempts. Stop before another write, preserve the exact output and diff, and verify the environment before narrowing the cause.

Do this first: Cancel the loop as soon as the same failure repeats, copy the actual error into the next prompt, and narrow the request before retrying.

What the failure looks like.

The agent makes a mistake, removes the file, recreates it, and repeats the same sequence until a timeout or a generic Having trouble message appears. Waiting does not add new information to the loop.

Why it happens.

The retry context is not carrying forward why the previous attempt failed, so the model receives no new constraint and repeats the same approach. Large requests make the resulting diff and hidden logs harder to audit.

Fix it without losing the task.

Capture the repeated action and its exact output. Note the Kilo version, selected model/provider, editor, operating system, and whether MCP or extensions are involved.

Stop the run after the action repeats without a changed result. Save the diff and compare file contents before and after each repeated edit.

Reduce the next task to one file and one observable acceptance check. Change one variable, such as model or MCP involvement, only if you are testing a specific hypothesis.

If the issue matches the reported Kilo configuration, add a reproducible note to the upstream report. Do not present that single report as proof of prevalence.

What the next AI should receive.

Kilo version, model/provider, OS and editor, exact repeated action and output, MCP or extension involvement, before/after file contents, and one bounded acceptance check.

Check before restarting

Stop when the same tool action repeats without a new result. Save the actual error and current diff, then compare the file before and after the loop before asking Kilo to continue.

Boundary of the evidence

Kilo issue #12772 is one open user report for Kilo 7.4.17 and kilo-auto/balanced, across the reporter's MacOS and Nobara Linux setup; it does not establish a 60-70% product-wide rate.

Diagnostic checkpoint

Issue #12772 is one report for a named model and version, not a general Kilo retry-loop diagnosis.

How ShardStitch helps.

ShardStitch can package the local diff, known failed attempt, and next bounded check for a fresh Kilo session or another target. It does not detect or terminate Kilo retries automatically.

Research basis.

Kilo Code issue #12772 (user report, opened August 2, 2026). It reports kilo-auto/balanced on Kilo 7.4.17; the reported frequency is the author's estimate, not a measured product-wide rate.

FAQ.

Does Kilo issue #12772 show that most Kilo sessions enter a retry loop?

No. It is one user report with a stated configuration and an estimated frequency from that reporter. It cannot establish prevalence across Kilo users or models.

What should I preserve before stopping a repeated Kilo action?

Keep the exact error, Kilo version and model, task prompt if shareable, changed files, and the diff across attempts. Redact secrets and mark unverified explanations as hypotheses.

Scope note: Evidence boundary: this guide is grounded in one user-submitted Kilo Code issue opened August 2, 2026. The report names kilo-auto/balanced and version 7.4.17; other models and versions may behave differently.