Watch GitHub issues and discussions for replies, like the PR watcher

[Lenoridev]

Problem

After an agent files a bug report or opens an Ideas discussion, the next step often depends on a maintainer replying. I want to ask “watch this issue/discussion and bring it back when someone responds,” then leave the thread waiting with its investigation and context intact.

T3 Code already provides that experience for pull requests through watch_pull_request. I could not find an equivalent built-in watcher for issues or discussions on current main.

Scheduled tasks can check a URL periodically, but they start an agent turn on every interval, including when nothing changed. Webhook-triggered tasks are another option when I can configure the repository, but that does not cover following a discussion in someone else's repository.

Proposed behavior

Let an agent attach a watch to a specific GitHub issue or discussion URL in its current thread. The environment server checks for changes and wakes the agent only when a relevant update arrives. For example:

Watch this Ideas discussion for replies. When a maintainer responds, summarize what they said and draft any follow-up here for my review.

The first version could support:

• New comments from other accounts, including replies to discussion comments. Record a baseline when watching begins so existing comments do not trigger a wake.
• Issue closure/reopening and discussion closure/reopening or an answer being selected, with the event identified in the wake message.
• A link and enough new content in each wake for the agent to understand what changed. Avoid duplicate wakes and notifications caused by its own account's comments.
• Visible watch state and a way to stop watching across web, desktop, and mobile. Stop, settle, and archive should end the watch consistently with PR watches. Make expiry and failure stops explicit.

Watching should authorize reading and notifying. Posting replies or starting implementation should follow the user's existing instructions; enabling a watch alone should not authorize either.

The watch should run on the owning environment while its server is available, even with clients closed. Quiet checks should not invoke a model. Reuse the PR watcher's approach to shared checks, rate limits, and bounded wake behavior where appropriate.

Existing discussions and scope

• #19879: Wake a thread when a command prints something already describes this discussion-reply use case through a proposed general watch_command tool. That could satisfy this request; a separate GitHub-specific system is not essential.
• #12257: Scheduled follow-ups for issue monitoring was closed as a duplicate of #6748: Scheduled Prompts. Recurring scheduling now exists. The remaining request here is detecting changes before starting an agent turn and owning the watch's waiting/stop lifecycle.

The smallest useful scope is watching one explicit URL, starting with GitHub. Repository-wide triage and automatic replies can stay outside it. Would maintainers prefer this use case consolidated into #19879, handled by a change gate on scheduled tasks, or supported alongside the PR watcher?

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed write-up. This is the same use case as #19879, which proposes a general watch_command tool and uses waiting on an Ideas discussion reply as its main example (baseline, quiet checks with no model turn, Waiting state, stop on settle/archive, 7-day expiry). Closing this as a duplicate so the conversation stays in one place; please add the GitHub-specific details (answer selected, close/reopen events, ignoring your own account's comments) as a comment there.