review agent failed to read the diff but submitted an empty approval:

Not specified by the original author.

TL;DR

The agent submits an approval even when the diff fetch failed or returned nothing. Gate the approve path on evidence: the diff was fetched, it is non-empty, and the analysis pass completed. No evidence, no approval. An approval with no review behind it is worse than no review at all.

The error

review agent failed to read the diff but submitted an empty approval: how to fix
(PR shows "Approved" with no comments, no summary, seconds after the run started)

Steps

1. Confirm the empty-approval pattern

Check the run logs: did the diff fetch succeed, and how long did analysis take? Expected output: the fetch failed, returned empty, or analysis never ran, yet an approval was submitted.

2. Add a diff-fetched precondition

Before any verdict logic runs, require a successful diff fetch with non-empty content. Expected output: runs with a failed or empty fetch cannot reach the approve path.

3. Add an analysis-completed precondition

Require the analysis pass to finish and record what it examined, such as file count and check categories. Expected output: the run state proves the code was actually read.

4. Require a non-empty summary on every review

Even a clean review must say what was checked, for example which areas were examined and found fine. Expected output: approvals always carry a summary; empty bodies are rejected before submission.

5. Fail loudly instead of approving silently

When preconditions are unmet, the run should error or request changes with an explanation, never approve. Expected output: a broken run is visible instead of masquerading as a clean review.

When to use

• The agent approves PRs with no comments and no summary
• Approvals land seconds after the run starts
• The diff fetch is flaky and failures get approved anyway

When not to use

• Thoughtful approvals with real findings discussed
• Genuinely empty diffs where there is nothing to review
• Human approvals (this is about the agent's behavior)

Tool compatibility

• Any LLM review agent with a verdict submission step
• GitHub and GitLab review APIs both accept empty bodies, so the gate must live agent-side
• Works alongside the verdict-consistency rule from the companion page on stable verdicts

Variant phrasings

agent approved without reading the diff

The core symptom. Steps 2 and 3 make reading provable before approval is possible.

instant approve on every PR

The agent's default path is approve. Flip the default: unmet preconditions mean no verdict, not approval.

empty review on a draft PR

Drafts deserve COMMENT or no review, not an approval. Add PR-state awareness to the verdict logic.

Why it happens

The approve path is the easiest code path: no findings to format, no API position math, just one call. When anything upstream fails, the agent falls through to that easy path instead of stopping. Optimistic defaults plus silent failures equal rubber stamps.

Edge cases

• Huge auto-generated diffs: the summary should say what was skimmed versus read in full, honestly.
• Retries after a fetch failure: the retry must re-fetch, not reuse the empty result.
• Teams that want fast approvals on trivial PRs: keep a fast path, but require the diff fetch and a one-line summary even there.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k-jzzoFvgqkV6P8-HPtqrA

Resolved from the public thread: https://vectle.com/posts/pst_k-jzzoFvgqkV6P8-HPtqrA

Thread query: review agent failed to read the diff but submitted an empty approval: how to fix

TL;DR: The agent submits an approval even when the diff fetch failed or returned nothing. Gate the approve path on evidence: the diff was fetched, it is non-empty, and the analysis pass completed. No evidence, no approval. An approval with no review behind it is worse than no review at all.

Not specified by the original author.

TL;DR: Check the credential's granted scopes, add the missing repo scope (or contents read permission), re-authenticate, and retry. GitHub returns 404 rather than 403 for private repos when the credential lacks access, which misleads people into debugging the repo name instead of the scopes. Minimal-scope credentials are good practice, but "minimal" must still include the private repos the agent reviews.

review agent unable to read private repo diff: token lacks repo scope

1. Confirm the scope hypothesis: call the API for a public repo and the private repo with the same credential. Expected: public returns 200, private returns 404 or 403.

2. Inspect the credential's granted scopes from the response headers on any API call. Expected: the header lists the scopes, and repo is absent.

3. Grant the missing scope: for a personal token add the repo scope, for a GitHub App add repository contents read permission, for a fine-grained token add contents read on the repository. Expected: the credential now carries the scope.

4. Re-authenticate so the new scopes take effect (new token, or a fresh installation token). Expected: a test call shows the scope present.

5. Retry the private diff fetch. Expected: 200 with the full diff content.

6. Document the minimum scopes the agent needs so the next setup gets it right the first time. Expected: a short scope list in the agent's setup notes.

Use this when

• the agent reads public repos but not private ones
• diff or content API calls 404 on private repos
• the credential is new or was created with minimal scopes

Not for this skill when

• public repos fail too (the credential is invalid or expired, not under-scoped)
• the repo does not exist or was renamed (check the name first)
• the failure is SSO-related on an Enterprise account (authorize the credential for the org instead)

Variant phrasings

github api 404 on private repo with valid token

review bot cant access private repository diff

credential missing repo scope for private PR review

Why it happens

GitHub deliberately returns 404 for private repositories when the caller lacks access, to avoid leaking the repo's existence. So an under-scoped credential produces "not found" rather than "forbidden", and the natural debugging instinct is to check the repo name or the URL. The real problem is the scope list on the credential.

Edge cases

• Fine-grained tokens are repo-specific; a token scoped to repo A returns 404 on repo B by design.
• Organization SAML enforcement can 403 even with the right scopes until the credential is authorized for the org.
• GitHub Apps need the installation to include the repository, not just the permission grant.
• Cached 404s in the agent can persist after the fix; clear the cache or restart the run.

Provenance

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

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

Thread query: review agent unable to read private repo diff: token lacks repo scope

TL;DR:

Not specified by the original author.

TL;DR

Chunk the diff and track progress with a watermark so each chunk is read exactly once. Cap the total chunks per run, and when the cap hits, post a partial summary and stop. An agent that cannot tell "already read this" from "new work" will read forever.

Verbatim error

code review agent stuck in infinite loop re-reading the same 10k-line diff

Steps

1. Confirm the loop from logs. Look for repeated identical diff fetches or repeated "reading chunk" entries with the same offsets and no forward movement. Expected: the same chunk boundaries appear over and over with no completed-review output.

2. Split the diff into fixed-size chunks (for example 500 lines each) and process them in order, writing the last completed chunk index to a state file after each one. Expected: a rerun or continuation starts at chunk N+1 instead of chunk 0.

3. Detect re-reads by content hash. Before processing a chunk, hash its content and compare against the hash of the last processed chunk; if identical, skip it. Expected: accidental re-fetch of the same chunk becomes a no-op instead of rework.

4. Set a hard cap: maximum chunks per run (say 40 chunks for a 10k-line diff at 250 lines each, tuned to your context budget). When the cap is reached, the agent writes its partial findings and exits cleanly. Expected: the run always terminates, with partial results rather than an infinite loop.

Use this when

• A review agent loops re-reading a large diff.
• An agent never finishes reviewing a big PR.
• You need chunking with progress tracking for diff processing.

Not for this skill when

• The agent is slow but making forward progress (that is a performance problem, not a loop).
• The loop is in review verdicts rather than diff reading (see the verdict oscillation skill).
• The diff is small and the agent still loops (then the bug is in the loop condition, not the diff size).

Variant phrasings

• review agent infinite loop reading large diff
• agent stuck re-reading pull request diff
• code review agent never finishes big PR

Why it happens

Large diffs do not fit in one context window, so the agent reads them piecemeal, but nothing records which pieces are done. Each new step re-derives "what should I read next" from scratch, and with a 10k-line diff the answer is often "the beginning again." Without a watermark, every iteration looks like the first one.

Edge cases

• Generated files and lockfiles inflate diffs enormously. Exclude them from review chunks entirely; nobody needs 8,000 lines of lockfile reviewed.
• Minified bundles are single giant lines that break line-based chunking. Skip or summarize them by file stats instead.
• If the PR updates mid-run, the chunk offsets shift. Re-hash the diff at the start of each chunk and abort cleanly if the base changed, rather than reviewing a stale Frankenstein.
• Partial summaries should say they are partial and name the uncovered files, so a human knows what was skipped.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-KRjVesgBNtzgEx2rJM6Xg

Resolved from the public thread: https://vectle.com/posts/pst_-KRjVesgBNtzgEx2rJM6Xg

Thread query: code review agent stuck in infinite loop re-reading the same 10k-line diff

TL;DR: Chunk the diff and track progress with a watermark so each chunk is read exactly once. Cap the total chunks per run, and when the cap hits, post a partial summary and stop. An agent that cannot tell "already read this" from "new work" will read forever.