Wake a watched PR's thread when it merges or closes, and when a review bot reacts

[BenWortley]

Before submitting

• I searched existing issues, PRs and discussions. Add durable local GitHub waitpoints for agent threads #7034 asked for a wake on "pull request merged or closed". It was closed as resolved by feat(server): agents can watch a PR and get woken when checks, reviews, or conflicts need them #15057, but the watch stops on merge without waking the thread.
• I am describing a concrete problem.

Area

apps/server (the watch_pull_request reactor).

Problem

Two waits come up on almost every PR an agent merges, and watch_pull_request covers neither:

1. Merge after auto-merge. The agent runs gh pr merge --squash --auto and needs to confirm the merge before it reports or starts the next step. The watch ends silently when the PR merges, so the agent writes its own until gh pr view --json state …; sleep loop.
2. A review bot that signals with a reaction. The Codex GitHub reviewer reacts 👀 while it reviews. With findings, it posts a review, which the watch wakes for. With no findings, it only reacts 👍, which wakes nothing. The agent polls /issues/<n>/reactions until 👍 shows up or it gives up.

On T3 Code 0.0.46-nightly.20261007.2761, across 196 watch wakes from 3 to 7 Oct, I saw none for a merge or a reaction. From 5 to 7 Oct, my agents wrote 23 polling loops for these two waits (16 merge, 7 Codex), 18 of them in threads that had already called watch_pull_request. The T3 instructions also tell agents not to run their own watcher, so they get mixed signals.

Proposed solution

• Before the watch stops on merge or close, send one wake: "PR merged as <sha>" or "PR closed without merging".
• Wake once when a bot adds or changes a reaction on the PR, naming the bot and the reaction. Limiting this to bots, or to logins the user lists, would keep human emoji from waking threads.

I'm happy to test a build.

[chhoumann]

+1, and a few more cases from an audit of ~300 PR-watch runs across my agents (Claude Code, Codex, Grok, Cursor, Feb-Oct).

Merge/close and bot reactions are the two biggest gaps for me too. These also force agents back into their own polling loops:

1. Edited comments. Some review bots post a placeholder and then edit it with the actual review. An edit doesn't wake the watch, so in one case a PR sat green for about 85 minutes until I asked for status.
2. Optional checks finishing after the required ones. The watch wakes once required checks pass. If a slow optional check is still pending at that point, nothing wakes the thread when it finishes.
3. Mergeability becoming known, and falling behind base. While GitHub reports mergeability as UNKNOWN, nothing wakes when it resolves, and a branch going BEHIND doesn't wake either.
4. Noise in the other direction. One watch woke the agent 5 times for cancelled checks on superseded commits. Each wake was a no-op turn.
5. Delegated children can't watch. A delegate_task child that opens a PR has to hand it back to the parent or poll.

A generic shape that would cover most of this: wake on any change to the PR's head, checks, reviews/comments (created or edited), reactions, mergeability or state, and include the change kinds in the wake. The thread can then ignore what it doesn't care about. Adding an opt-in wakeOn filter, defaulting to today's set, would keep existing behavior unchanged.

In my history, PR babysitting logic got reinvented about 47 times and wasted roughly $150 at API prices, mostly working around these gaps. Happy to test a build.