When the host refuses to show a watched pull request, the watch retries it as if the failure were transient. This happens when GitHub answers 404 because the selected gh account cannot see a private repository, or when the host has no working credential. watch_pull_request returns watching: true, every pass then fails at warning level, and the agent hears nothing until the 8th failure, about 20 minutes later. Even then the message only says "failed to read it". No retry can fix these failures.
Observed on a server where gh's active github.com account could not see the private repository. Over ten minutes of traces, 376 of 384 GitHub requests failed with GitHubApiNotFoundError, and every PullRequestWatchReactor.readGroup failed. After 17 minutes the agent called unwatch_pull_request and got wakes: 0, reads: 0. It was never told why.
PullRequestWatchReactor now treats a lasting refusal as final: PullRequestUnavailableError (CLI missing or unauthenticated, or provider unsupported) or PullRequestOperationError with reason: "not-found". The watch ends on the first such read, and the wake gives the host's reason and points to Settings → Source Control. Other failures still get 8 tries in a row, and a rate limit still only pauses the watch. The watch_pull_request description and docs/user/source-control.md now describe this rule.
This doesn't fix #19549. A field-level FORBIDDEN on a requested reviewer is classified as a plain response error, not not-found (isNotFoundOnly requires every GraphQL error to be NOT_FOUND), so it keeps the 8-try budget. The new test checks this.
This is a focused fix for an obvious bug: the server keeps a watch silent for 8 passes even though it knows the read can never succeed. It adds no new setting, contract, or client change.
runtimeLayer.test.ts case, "ends a watch the host refuses to show on the first pass, and says why". A read with a field-level forbidden error leaves the watch on after one pass. A not-found read then ends it, and one failed wake carries the host's reason. The test fails on main and passes with this change. As a mutation check, classifying every operation error as lasting makes it fail.vp test run src/orchestration-v2/runtimeLayer.test.ts src/mcp/toolkits/pullRequests/handlers.test.ts src/orchestration-v2/pullRequestWatch.test.ts: 126 passed. This includes the existing 8-failure and rate-limit tests.vp lint and vp fmt --check on the changed files are clean. tsc-rs --noEmit in apps/server exits 2: 59 diagnostics in unchanged root scripts/lib, starting with missing module declarations for @effect/vitest, effect/*, @t3tools/shared/HostProcess and typescript-legacy, followed by dependent type errors. It reports no errors under apps/server/src/. This is a validation gap; a clean baseline typecheck was not established.Not addressed here: #19183, #16924, #15924.
Written by Claude Opus 5.5 (Claude Agent SDK harness in T3 Code); reviewed by a GPT-6.1-Sol (Codex) parent agent.
🤖 Generated with Claude Code
Added 1 commit
Verdict: Approved at e546e98
Macroscope's review found this PR approvable — This is a contained server bug fix that distinguishes permanent pull-request access failures from transient read errors, with targeted runtime coverage and documentation updates. Existing retry and rate-limit behavior remains unchanged for recoverable failures.
You can add or adjust custom eligibility rules. Learn more.
Warning
Only developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing.
Next included review available in 1 minute.
Limit details: You’ve used all 10 included reviews currently available.
Review configuration:
a37242e5-47d0-4f92-8142-7e787690c9f3Reviewing files that changed from the base of the PR and between cc93cc564b052a9dcf73323783e7b60506cda5e0 and c165d36660dd672c8fe147da212fd86fb8d9d37b.
apps/server/src/orchestration-v2/PullRequestWatchReactor.tsapps/server/src/orchestration-v2/runtimeLayer.test.tsdocs/user/source-control.mdpackages/source-control-github/src/server/GitHubPullRequestApi.test.tspackages/source-control-github/src/server/GitHubPullRequestApi.tsComment @coderabbitai help to get the list of available commands.
Added 4 commits
Note
Written by gpt-6.1-sol on behalf of Maria
updated the original branch at c165d36660dd672c8fe147da212fd86fb8d9d37b, keeping @shredderts2000's commit and merging main. the original permanent-error classification and recovery message are retained.
NOT_FOUND and null pull-request responses. a readable sibling in the same batch still succeeds.verification passed: 245 focused tests; blacksmith vp run check:changed against main cc93cc564b including formatting, lint, both knip passes, graphql checks and typechecks for ten packages. regressions failed before their fixes. all six reported head checks pass; git.cafe reports mergeable.
live github verification: main left an inaccessible repository's watch active and silent. the final build ended a fresh watch on its first fingerprint refusal, recorded one wake, and the real codex provider explained recovery in the web client. screenshots use the same initial thread; the recording shows a fresh watch ending.
both independent reviews identified the fingerprint gap; it is corrected with github-boundary and reactor regressions. the final boundary correction was not independently re-reviewed after the requested round limit. coderabbit skipped substantive review because of its quota. live missing-cli/unauthenticated/unsupported-host flows, native clients, full suites and builds remain unverified.
before: main keeps watching the inaccessible pull request without a message
after: the watch ends and the provider explains credential recovery
Note
Written by gpt-6.1-sol on behalf of Maria
verified the exact head c165d36660dd672c8fe147da212fd86fb8d9d37b as-is on this linux boat vm. no source changes or pushes.
github/main (570d4b03eef879bd60be3d74444046858c94dacd) in ../main with vp i, then installed the exact contributor head with vp i. ran real background vp run dev servers with isolated state. drove chrome at /usr/bin/google-chrome using the repo's playwright dependency.gpt-6.1-sol through the local provider proxy. asked the agent to call watch_pull_request for an inaccessible/nonexistent github repository. main logged GitHubApiNotFoundError on its sweep but kept the watch active and silent.reason: unreadable, wakes: 1, reads: 0. the real codex provider received the wake and explained missing access, settings → source control, and calling watch_pull_request again.main: github refusal leaves the watch active without a failure message
pr: the same thread receives the failure wake and codex explains recovery
native ios/android, electron, macos/windows, missing-cli/unauthenticated/unsupported-host cases, field-level forbidden responses, transient eight-read exhaustion, rate limiting, and later readable-watch check/comment notifications were not exercised live. the real github refusal cannot distinguish a nonexistent repository from a private repository hidden from the credential; both use the same not-found path.
interaction recording was attempted, but vm overload caused long stalls and the inspected exported clip contained loading frames. no usable recording or latency claim is supplied. screenshots and server/provider observations above were inspected directly. no new automated checks were run in this verification-only pass; git.cafe reported six successful head contexts, which are not a substitute for this runtime verification.