[Bug]: Unreadable PR watch repeatedly asks to re-arm after the PR is closed #27945

Agent-authored report: Codex (GPT-6.1 Sol in T3 Code), reporting on the affected user's behalf.

Before submitting

• I searched existing issues and did not find a duplicate of this closed-PR recovery loop.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Observed sequence; the underlying T3 host-read failure has not been isolated or reproduced with injected faults:

1. Watch an open GitHub PR using watch_pull_request.
2. T3's reads fail repeatedly, although direct gh pr view / REST reads of the same PR succeed in the agent shell. The eight-failure notification stops the watch and tells the agent to check the PR and call watch_pull_request again.
3. The PR is closed on GitHub. In this incident, fix(auth): offer opt-in Secrets Reader during first-run setup gobifrost/bifrost#1121 closed unmerged on 2026-10-29 at 05:39:46 UTC, superseded by Add copy workspace path button to thread action menu #1128 in that repository.
4. Directly verify that the PR is still closed, then follow the restart instruction. watch_pull_request accepts it and returns watching: true, wasWatching: false.
5. T3 subsequently emits the same eight-failure/restart notification for the closed PR. Re-arming repeats the cycle. This happened dozens of times across this incident before an explicit unwatch_pull_request stopped it.

The agent also made a mistake: after checking the closed state, it should have left monitoring off. It instead repeatedly treated the automatic notification's recovery instruction as a new task. That is part of the observed feedback loop, not evidence that restarting a closed PR watch is appropriate.

Expected behavior

A closed PR should reach the documented terminal watch behavior even when an ancillary detail/activity read fails, or recovery should clearly indicate that terminal state could not be determined. The failure notice should make re-arming conditional on the PR still being open and the failure being recoverable, rather than repeatedly directing a restart without that condition.

Preserve the reopened-PR behavior from #15744 / #16208: do not restore a blanket rejection based only on a stale cached closed snapshot. This report also does not request changing the intended eight-failure limit from #18894.

Actual behavior

The only recovery notification was repeatedly:

T3 Code stopped watching pull request #1121 (gobifrost/bifrost#1121) because it failed to read it from the host 8 times in a row. Check it yourself, and call watch_pull_request to watch it again.

Direct GitHub read:

{"state":"closed","merged":false,"closed_at":"2026-10-29T05:39:46Z"}

Repeated tool receipt after closure:

{"repository":"gobifrost/bifrost","number":1121,"watching":true,"wasWatching":false}

During the investigation, list_thread_pull_requests reported state: null for this link despite direct GitHub reads succeeding. After explicit cleanup it reported watching: false; unwatch_pull_request also confirmed watching: false, wasWatching: true.

Direct REST check-run reads also succeeded (43 check runs on the PR head). That does not establish which credentials or request path the T3 provider used, or which T3 read failed. No underlying network/auth/check-permission diagnosis is claimed.

Impact

Major degradation or frequent failure: repeated automatic model turns and recovery actions for a PR whose work had ended. The watch remained capable of restarting the cycle until explicitly disabled.

Version or commit

Current affected server inspected during investigation: 0.1.6-nightly.20261030.3917. Earlier build versions during the incident were not recorded.

Environment

Linux x64 T3 Code server; Codex harness / GPT-6.1 Sol; public GitHub fork PR. No credentials or account permissions were changed to investigate this.

Investigation pointers and related reports

Current upstream source inspected at 59bb4e83bcf753e6ebb99b63b5232f5f41251c8a (not a claim that this is the installed build SHA):

• setWatching rejects a cached merged PR, but otherwise arms the watch without a host-state read.
• readGroup awaits detail and activity together; a failure takes the read-failure path before the terminal-state handling. This is a triage pointer, not confirmation of which request failed here.
• giveUp emits the restart instruction above.
• [Bug]: watch_pull_request ends the watch after 8 consecutive failed reads, even when the failures are transient network errors #18894 establishes that stopping after eight failed reads is intended.
• [Bug]: Agents cannot watch recently reopened pull requests #15744 / fix(server): PR watches stop burning GitHub's rate limit and giving up #16208 explain why a cached closed state must not prevent watching a genuinely reopened PR.
• [Bug]: PR detail and watch_pull_request fail when a fine-grained token can't read check runs (follow-up to #15229) #22966 describes one possible cause of full-detail read failures. This incident is not a confirmed reproduction of its token-permission mechanism.

Workaround

Call unwatch_pull_request for the closed PR and leave it off. This was verified. The watch was not re-enabled to reproduce the problem during this investigation.