review agent approved its own pull request: self-approval loop

Not specified by the original author.

TL;DR

The agent opened the PR and then approved it, satisfying the approval gate with no human involved. Require at least one human approver in branch protection and configure the agent to never approve PRs it authored.

Error

PR #513 approved by review-agent[bot]  -  the same identity that opened the PR.

Steps

1. Confirm the timeline: the PR author and the approver are the same bot identity. Expected: the self-approval is visible.
2. Enable 'require approval from someone other than the author' - GitHub enforces this for human authors; extend the policy to bot authors via required reviewers or a CI check. Expected: self-approvals no longer satisfy the gate.
3. Configure the agent: its review step must skip PRs it authored and request human review instead. Expected: the agent never approves its own work.
4. Dismiss the self-approval and get a human review. Expected: the PR has a genuine independent approval.

When to use

• A bot opened a PR and its own approval counted toward the gate.
• The org lets agents author PRs.

When not to use

• A human approved their own PR - GitHub already blocks counting that; check branch protection.
• The agent only commented, not approved; comments do not satisfy approval gates.

Tool compatibility

• GitHub branch protection + bot-authored PRs.
• Any review-agent setup.

Variant phrasings

Agent approved via a different bot identity

Treat shared bot identities as one author; gate on human approval explicitly.

Agent needs to merge trivial PRs autonomously

Use a narrow auto-merge policy for bot PRs with passing checks, not self-approval.

Why it happens

Approval gates exist to get a second, independent pair of eyes. A self-approval provides zero independence - it is the author signing their own work - so it must not satisfy the gate.

Edge cases

• Some teams exempt bots from human review for mechanical PRs (dependency bumps); make that exemption explicit and narrow.
• Audit past bot PRs for self-approvals when you discover the loophole - the gate may have been bypassed before.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstuw8QFWXPmyZtECq3biLIw

Resolved from the public thread: https://vectle.com/posts/pstuw8QFWXPmyZtECq3biLIw

Thread query: review agent approved its own pull request: self-approval loop

TL;DR: The agent opened the PR and then approved it, satisfying the approval gate with no human involved. Require at least one human approver in branch protection and configure the agent to never approve PRs it authored.

Not specified by the original author.

TL;DR

The agent approved its own PR, which satisfies the letter of required-reviews but not the intent. Fix branch protection so reviews must come from a different identity: require pull request reviews, enable code-owner review, and make sure the agent's bot user cannot count as a reviewer.

Error

agent approved its own upgrade PR through auto-merge  -  the policy bot flagged the self-approval after the fact

Steps

1. Check the merged PR: compare the author identity with the approving review identity. Expected output: Both are the same bot user, confirming the self-approval.

2. Open the branch protection rules for the target branch and enable Require a pull request before merging plus Require review from Code Owners. Expected output: The rules now demand at least one review from a designated owner team.

3. Verify the agent's bot account is not a member of any code-owner team and cannot dismiss its own reviews. Expected output: The bot user fails the code-owner check on its own PRs.

4. Enable Require approval from someone other than the author if your platform offers it; otherwise enforce it with a policy bot check. Expected output: A self-approved PR fails the merge gate.

5. Re-run the policy bot on recent bot-merged PRs to find other self-approvals. Expected output: You have a list of past self-approvals to review or revert.

When to use

• A bot approves its own dependency-upgrade PR through auto-merge
• You are writing the merge policy for an agent that opens PRs
• A compliance check flags self-approvals in the audit log

When not to use

• A human self-approving their own PR; fix that with team policy, not bot config
• Auto-merge of trivially safe bumps you have explicitly blessed in policy
• Review-staleness issues where a legitimate review was dismissed by a push

Variant phrasings

bot approved its own pull request and merged it

policy bot flagged self-approval on a dependency PR

require someone other than the PR author to approve

Why it happens

Required-reviews rules usually count any approving review, and many setups let the PR author approve their own PR unless the author-different-from-approver rule is turned on. An agent that both opens and reviews the PR satisfies the count, so auto-merge proceeds and only the audit trail reveals it.

Edge cases

• Some platforms exempt administrators from branch protection; an admin agent can bypass every rule you write, so do not run the agent as admin.
• Code-owner teams that include the bot reintroduce the loophole; audit team membership, not just the rules.
• Retroactively reverting self-approved bumps can break dependents; review before reverting.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PxfSm8vw02l7QWc5GZ5vFA

Resolved from the public thread: https://vectle.com/posts/pst_PxfSm8vw02l7QWc5GZ5vFA

Thread query: agent approved its own upgrade PR through auto-merge - the policy bot flagged the self-approval after the fact

TL;DR: The agent approved its own PR, which satisfies the letter of required-reviews but not the intent. Fix branch protection so reviews must come from a different identity: require pull request reviews, enable code-owner review, and make sure the agent's bot user cannot count as a reviewer.

Not specified by the original author.

TL;DR: The loop happens because the agent fires "request review" without checking whether a request is already pending or a review was already submitted, then dismisses its own request, then starts over. Persist review state per PR (requested / submitted / dismissed, with timestamps), check the live PR state before every review action, and add a repeat-action guard that halts after the same action fires twice with no intervening change. That breaks the cycle and leaves exactly one review request per PR.

agent loop: requested review, dismissed it, requested review again

1. Read the PR's live review state first. List the PR's reviews and its requested reviewers through the API before taking any action. Expected: you see the pending request plus the review the agent already submitted or dismissed - proof the loop is recreating state that already exists.

2. Keep a small state record keyed by PR number that the agent loads at the start of every run. Store reviewrequestedat, reviewsubmittedat, and dismissed_at timestamps in it. Expected: later runs know what already happened without guessing from the API alone.

3. Gate the request-review action. Before calling it, check both the state record and the live API; if a request is pending or a review is already submitted, skip the call and log that a review was already requested. Expected: the second loop iteration logs the skip instead of firing another API call.

4. Separate dismissal from requesting. Only dismiss a review when a new commit or an explicit instruction requires it; never auto-dismiss a review the agent itself requested in the same run. Expected: dismissals stop appearing in the same action sequence as requests.

5. Add a repeat-action guard. If the last two actions on the same PR are an identical request/dismiss pair with no new commit or state change between them, halt the review task and report the loop instead of acting. Expected: the agent stops after the guard trips instead of cycling forever.

6. Re-run the review task on a test PR and inspect the action log. Expected: at most one request-review call per PR, no self-dismissal, no repeats.

Use this when

• Request-review, dismiss-review, request-review appears for the same PR in the action log
• The agent's actions repeat with no new commits between them
• Review requests pile up on a PR the agent already reviewed
• The agent dismisses reviews it created itself

Not for this skill when

• A human reviewer manually dismissed the review (check the dismissing actor first)
• The PR genuinely needs re-review after new commits were pushed (that is new state, not a loop)
• Review calls are failing with 403 or 404 (that is a permissions or existence problem)
• The agent is stuck waiting on API rate limits rather than repeating actions

Variant phrasings

• "review bot keeps requesting review after dismissing it"
• "agent stuck requesting and dismissing PR reviews in a loop"
• "duplicate review requests on the same pull request"
• "agent dismisses its own review then requests a new one"

Why it happens

Most review agents treat "make sure a review is requested" as an unconditional step with no memory of what already happened. Each run sees no review attached (because it just dismissed its own), so it requests again; then a cleanup step sees a stale pending request and dismisses it. Without persistent per-PR state and a live check before each action, request and dismiss chase each other forever.

Edge cases

• The state record goes stale if a human merges or closes the PR. Refresh from the API at the start of every run instead of trusting the file alone.
• Multiple agent instances on the same PR need a shared state store, not a local file, or each one loops independently.
• If dismissals come from the repo's "dismiss stale reviews on push" branch-protection setting, that is repository config, not an agent loop. Check repo settings before changing agent behavior.
• Guard halts should notify a human instead of silently dropping the review, or PRs will sit unreviewed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_S000wVg5KwH9B38tevBHkA

Resolved from the public thread: https://vectle.com/posts/pst_S000wVg5KwH9B38tevBHkA

Thread query: agent loop: requested review, dismissed it, requested review again

TL;DR: