Sign up
View stargazersSign up

Delegated children are told never to watch their PR, so nobody follows CI on a child's fix PR#25764

opened14d agobyJJulius Marminge

What happened

T3 injects this into every provider's system prompt (<pull_request_linking>):

Delegated children never watch, even if the brief says babysit. After PR work, a child's last line is: PR , head , checks and reviews .

So a delegated child that opens a fix PR always ends its turn without watch_pull_request, even when its task explicitly says to watch the PR, fix CI and report when it's green. Nobody follows up on CI for that PR unless the parent builds its own polling.

In the fleet (Issue Triager and PR Takeovers dispatchers on nucbox-1, leads on 40 linked VMs), leads' briefs say to watch the fix PR, fix CI and add bugfix when it's green. The dispatchers resolved the conflict in favour of this rule. Since 2026-10-24, about 1,200 lead dispatches carried "do not watch", and 184 fix PRs from issue leads have no CI follow-up record.

Expected

Julius has decided that the lead that opens a fix PR owns its CI follow-up through a PR watch. So:

  1. A delegated child may call watch_pull_request on its own PR when its task asks for it. The injected instructions should say "watch only when your task asks for it" instead of "never".
  2. The parent is told the child is watching, e.g. the delegated task result or task_status says the child holds a PR watch on , so the parent doesn't treat the child's interim result as final.
  3. The child's later result, written in a PR-watch wake turn, still reaches the parent. This is the delivery gap in https://git.cafe/pingdotgg/t3code/issues/24326 (closed 2026-10-26) and https://git.cafe/pingdotgg/t3code/issues/24297. Both need to hold for children that watch.

Where

  • packages/provider-core/src/server/runtimeInstructions.ts:1-3 (PULL_REQUEST_LINKING_INSTRUCTIONS, origin/main fe507c5a1e). The rule exists only in this prompt text; watch_pull_request itself (apps/server/src/mcp/toolkits/pullRequests/tools.ts:309) doesn't restrict children.

Related: https://git.cafe/pingdotgg/t3code/issues/24326, https://git.cafe/pingdotgg/t3code/issues/24297, https://git.cafe/pingdotgg/t3code/issues/22183 (watch ends silently).

Re-filed from discussion 25650, originally #25635. An automated triage lead converted it to an Ideas discussion as a "policy enhancement"; it is a bug: delegated children are instructed never to watch their own fix PR, so CI follow-up on child-opened PRs has no owner.

Dderek-eliza11d ago
Synced from GitHub

Additional triage evidence from 0.1.6-nightly.20261030.3904, commit 36dac688a17c6de1c6398e62d01546fb787c185b:

A coordinator delegated PR work to child threads. Two PRs initially became linked to their child threads without watches. One link came from an explicit link_pull_request call (source: "agent"); the other came from automatic shell-command detection (source: "created"). The coordinator subsequently linked and watched both after the user raised the missing handoff.

The watch restriction is enforced in code in this build, in addition to the injected prompt:

  • apps/server/src/mcp/toolkits/pullRequests/handlers.ts:274 rejects subagent watch requests with PullRequestWatchFromSubagentError.
  • apps/server/src/mcp/toolkits/pullRequests/tools.ts:157 says the parent owns the PR and the child must report back.
  • apps/server/src/orchestration-v2/PullRequestWatchReactor.ts:402 also ends subagent watches.

PullRequestSyncReactor.ts:625–650 automatically links PRs detected in completed shell commands to the executing thread. Consequently, instructing delegates not to call link_pull_request does not reliably prevent child-thread links. The child link result requests a final PR status line, but linking itself does not establish a parent watch.

This supports the CI-ownership handoff problem described here, while correcting the report's statement that the watch restriction exists only in prompt text. The inspected prompt, automatic-linking implementation, and subagent watch restrictions are unchanged in nightly 0.1.6-nightly.20261030.3917 and current main at the time of triage.

Workaround observed: the coordinator explicitly links and watches child-created PRs. Removing child links alone does not establish monitoring. No source patch or database write was made during this investigation.

Produced by GPT-6.1 Sol through the Codex harness in T3 Code.

Dderek-eliza5d ago
Synced from GitHub

Another case of the same gap, from a coordinator thread that runs several sibling coordinator threads, each with its own delegated children.

Setup. A top-level coordinator reconciles every open PR authored by one account on a schedule. Several sibling coordinator threads under the same account each delegate implementation children. Each child opens a PR, arms auto-merge, reports PR <url>, head <sha>, checks pending and stops, per the injected <pull_request_linking> rule. Only the thread that calls watch_pull_request gets woken.

What happened. Over one afternoon, PRs opened by the sibling coordinators' children sat with failing checks: lint, a database check, a container build, and a repo-wide static check that failed for reasons unrelated to the PR's diff. None of them woke anyone:

  • the child had ended its turn and is barred from watching;
  • the sibling coordinator never linked or watched the child's PR;
  • the top-level coordinator saw the PRs in a scheduled sweep but treated them as owned by the sibling thread, because a thread existed for them, even though no running child was fixing the failure.

The person running the threads noticed before any agent did.

What would have prevented it. Either of the "Expected" items above would have:

  1. allow the child to keep a PR watch when its task asks for one, or
  2. make the PR's watch follow ownership, so the coordinator that delegated the child is told the child's PR has no watcher and gets woken on its check failures.

It would also help if list_thread_pull_requests or task_status showed, for each PR a child created, whether any thread currently watches it. A coordinator could then tell "owned and followed" from "owned but orphaned".

Related: #30530 and #25497. Even a watched PR can stop waking after an early check failure, which makes an orphaned PR even easier to miss.