GitHub PR archiving expands: stop comment automation when cleaning the queue

Dev
Views 4

A triager can now handle PR archiving that previously needed an administrator. The useful engineering question is what happens to work that still expects to comment on that PR. Review reminders, build summaries, and agent progress reports often use the conversation as their delivery channel. If those jobs keep running after a moderator archives the target, a tidier queue can still leave noisy failures behind. Treat the transition as a workflow event and decide where the unfinished job records its outcome.

Check PR state, preserve review evidence, stop comments after archiving. An editorial workflow diagram, not a product screenshot.
Check PR state, preserve review evidence, stop comments after archiving. An editorial workflow diagram, not a product screenshot.

The confirmed behavior and its boundaries

GitHub announced the change on October 8, 2026: users with triage or higher repository roles can archive and unarchive PRs. Archiving closes the PR and makes its conversation read-only, blocking comments, reactions, and automated comments. An October 9 clarification says archived PRs are hidden from public view but remain visible to triage, write, maintain, and admin users. Unarchiving restores comments and reactions; it does not reopen the PR. These are distinct outcomes that a cleanup checklist should describe explicitly.

Check the target before posting another comment

A failed delivery should not automatically trigger endless comment retries. As an operational policy, inspect the PR’s current state and end jobs whose target is confirmed archived, recording the reason in an appropriate internal work record. This is a recommendation, not a claim that GitHub added a particular API field or that every integration already handles it. Verify the states and responses your integration actually exposes. Distinguish an archived target from missing permissions and a temporary network failure; each calls for a different next action.

Preserve review evidence before cleanup

Removing spam or a duplicate is different from archiving an implementation that still needs a decision. Record the reason, last verification result, linked issue, and canonical PR when there is a duplicate. If public review evidence matters, consider that an outside reader may no longer see the archived PR. Move needed public context to a suitable issue or release record before archiving. Do not use evidence preservation as a reason to publish private details. The goal is to keep an understandable decision trail for the audience that is supposed to have it.

Delegating triage is separate from granting code access

Teams have more room to delegate routine cleanup without giving everyone write permission. They still need a policy for selecting targets. A PR under active review, the final evidence for another task, or an unresolved contributor question may need a human decision. If unarchiving is meant to resume development, assign someone to check whether reopening is also required. A restored ability to comment does not mean the original review workflow has resumed or that the code is ready to ship.

Start by checking your repository’s real roles and testing the bot’s termination path on one appropriate archived target. Do not create a replacement PR or resubmit work just because a comment failed. The product behavior above is confirmed; the evidence and termination rules are this article’s operational suggestions. The linked community discussion is a feedback venue, not evidence of adoption or measured productivity gains.

Official source and discussion

GitHub Changelog

GitHub Community

Review your team’s archiving criteria and automated-comment termination policy together before using the expanded permission.