agent loop detected: review agent kept re-requesting changes on its own approved diff
Fixes a review agent that flip-flops between requesting changes and approving its own diff. Use it when an agent's reviews oscillate or it re-requests changes on code it already approved. Key trigger: the PR timeline shows the agent alternating approve and request-changes on the same diff.
TL;DR
Give the agent a memory of its last action and a rule: never change its verdict on the same diff twice. Record the diff hash and the verdict after each review; if the diff has not changed since the last review, post nothing. The loop dies the moment the agent can see it already decided.
Verbatim error
agent loop detected: review agent kept re-requesting changes on its own approved diffSteps
- Confirm the loop in the PR timeline. Look for the agent's reviews alternating between "approved" and "changes requested" with no new commits between them.
Expected: two or more agent reviews on the identical commit SHA with different verdicts.
- Add a verdict guard. After every review the agent writes a small record: commit SHA, diff hash, verdict. Before posting a new review it reads the record.
Expected: the record exists and shows the last verdict for the current diff.
- Enforce the rule: if the diff hash matches the last reviewed hash, the agent posts nothing and exits. A new verdict is only allowed when the diff actually changed.
Expected: rerunning the agent on an unchanged PR produces zero new reviews.
- Add a circuit breaker as a backstop: if the agent has posted more than 2 reviews on one PR without a new commit, stop and flag for a human instead of reviewing again.
Expected: even if the guard has a bug, the run terminates instead of spamming the timeline.
Use this when
- A review agent flip-flops between approve and request-changes.
- An agent re-reviews its own diff and contradicts itself.
- You need idempotency guards on agent review actions.
Not for this skill when
- A human keeps pushing new commits and the agent reviews each one (that is correct behavior, not a loop).
- The agent posts duplicate identical reviews (that is a retry bug, not a verdict oscillation).
- Two different agents disagree with each other (that is a coordination problem, not a self-loop).
Variant phrasings
- review agent keeps requesting changes on its own approved PR
- agent flip flopping approve and request changes
- code review agent review loop same diff
Why it happens
The agent is stateless between runs: each invocation reads the diff fresh, re-derives a verdict from slightly nondeterministic reasoning, and posts it. Without a record of what it decided last time, "request changes" today and "approve" tomorrow are both defensible to it, so it oscillates forever. The loop is not a bug in judgment; it is the absence of memory.
Edge cases
- Force-pushes rewrite the commit SHA but may keep the same diff. Hash the diff content, not just the SHA, so equivalent diffs are recognized.
- If the agent's verdict legitimately needs revisiting (say new CI failures appeared), key the guard on diff-plus-CI-state, not diff alone.
- Dismissed reviews: a human dismissing the agent's review should reset the guard so the agent can re-review fresh.
- Log every suppressed review at debug level. Silent no-ops are correct but maddening to debug without a trace.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_2rbCSldanN9TgjmF-gcWFA