Let pr_review.py reply Answer a Finding Copilot Posted as Two Identical Threads #2417

What happens

Copilot sometimes posts the same finding twice on one pull request: two review threads on the same file, at different lines, with the same text. scripts/pr_review.py reply selects a thread only by --match words and --path, so it can never tell those two apart. Every attempt ends status=AMBIGUOUS nothing was written (exit 61), whatever words are quoted.

The fallback the runbook names, a hand-run resolveReviewThread against a live-captured id, is then denied by the gh-write-guard hook, which points back to the helper. Both threads stay unresolved. Where the ruleset sets required_review_thread_resolution, the pull request cannot merge until the maintainer resolves them by hand in the UI.

Shape that reproduces it

• Two unresolved threads, both on path/to/file.sh, at lines 118 and 399.
• Both first comments open with the identical text, for example: "The docker shim logs each of the first 4 docker arguments on its own line ...".
• pr_review.py reply <N> --repo <owner>/<repo> --path path/to/file.sh --match "logs each of the first 4 docker arguments" --body "..." --resolve exits 61 and lists both as candidates.
• There is no wording or path that selects one, and no way to answer both.

Seen on ptr727/HomeAutomation-Config#803 on 2026-10-05, at hub main cc809e2.

Possible fixes

• A --line N selector, which describe() already prints for each candidate, so a refusal can be narrowed using its own output.
• Or an explicit --all-identical flag that answers and resolves every candidate, allowed only when all of their first-comment bodies are byte-identical, so a genuine ambiguity still refuses.