[Bug]: watch_pull_request misses re-reviews from bots that edit their comment in place

[uzairansaruzi]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Open a PR on a repo whose review bot re-reviews each push by editing its existing summary comment instead of posting a new one. Greptile (greptile-apps[bot]) does this, and so does a custom review action we run.
2. Have an agent call watch_pull_request on it, handle the first review, push a fix, and end its turn.
3. The bot re-reviews the new head by editing its original comment.

Expected behavior

The watch wakes the agent with the re-review, as #15057 describes ("someone other than you or the agent comments or reviews").

Actual behavior

No wake. evaluatePullRequestWatch (apps/server/src/orchestration-v2/pullRequestWatch.ts) filters remarks on createdAt against remarksThrough, so a comment whose body changed but whose createdAt did not is never reported. The agent wakes only when the required checks pass or fail. If CI finishes before the bot's re-review, the agent finds the review still pending, ends its turn, and nothing wakes it again.

Our review bots on two recent PRs:

greptile-apps[bot] created=2026-10-02T22:22:52Z updated=2026-10-03T00:40:13Z  <!-- greptile_summary -->
hermes-uzi         created=2026-10-02T22:21:31Z updated=2026-10-03T00:38:05Z  <!-- hermes-agy-review:... -->

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Nightly) 0.0.46-nightly.20261003.2632, which includes #15057 (18b2132)

Environment

macOS 26 (Darwin 25.6.0), Claude Code and Codex agents, GitHub host

Workaround

After each push, our agents ignore the watch for re-reviews and run their own review wait, which polls for a bot comment naming the current head SHA.

Possible fix

Also treat a non-viewer comment as fresh when its updatedAt is newer than when the watch last recorded it (for example, keep id → updatedAt for the listed remarks). Edits would then count toward the existing 10-wake limit, so a bot that edits a progress comment many times still can't loop the agent.

---

Filed by Claude Opus 5.5 in Claude Code via T3 Code, on behalf of @uzairansaruzi.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @uzairansaruzi for the precise report and the timestamps from your bots. Confirmed: watch_pull_request only treats a remark as new when its createdAt is past remarksThrough (or it shares that timestamp and its id isn't in remarkIds). An in-place edit keeps the same id and createdAt, so it never wakes the agent.

// apps/server/src/orchestration-v2/pullRequestWatch.ts
const fresh = (remarks ?? []).filter((remark) => {
  const at = Date.parse(remark.createdAt);
  return (
    (at > through || (at === through && !watch.remarkIds.includes(remark.id))) &&
    remark.author?.login.toLowerCase() !== own
  );
});

What's happening

• The watch starts with remarksThrough set to when watching began, so an existing summary comment is ignored from then on. If required checks finish before the bot rewrites that comment, the agent wakes for the checks, sees no new remark, and ends its turn, and the later edit never wakes it.
• Bots that post a new comment or review on each push aren't affected. Greptile-style summaries (<!-- greptile_summary -->) and your Hermes review are invisible after their first version.
• This is a gap in the watcher from merged feat(server): agents can watch a PR and get woken when checks, reviews, or conflicts need them #15057 (18b21325c), not a duplicate of it.

Likely fix area

The data the watcher stores today can't detect edits:

• PullRequestComment only has createdAt. gh pr view --json comments,reviews doesn't request updatedAt or lastEditedAt, and REVIEW_THREADS_GRAPHQL_QUERY also selects only createdAt. GitHub does expose lastEditedAt and updatedAt on issue comments, reviews, and line comments. includesCreatedEdit isn't a substitute, since it only marks an edit made during creation.
• lastEditedAt looks like the better signal than updatedAt, which also moves on reactions and would burn a comment-only wake.
• Options include counting a non-viewer body edit as a remark using the same watermark and same-second id list (close to your id → updatedAt suggestion), and counting it toward the existing 10 comment-only wake limit so a self-rewriting progress comment can't loop the agent. Hosts without an edit time could keep today's createdAt behavior.

A maintainer will decide on the fix direction.