Delegating pull request cleanup raises a separate question from granting permission to change code. A contributor may handle spam routinely, yet still have to hand work to an administrator whenever a PR needs archiving.

GitHub’s October 8, 2026 update reduces that handoff by extending archiving to the Triage role and above. Understanding what can be delegated also means understanding what archiving stops—and what unarchiving restores.

Triage separates PR moderation from code write access

Triage is a repository role for people who manage issues, pull requests, and related discussions. The organization repository role definitions and permission table allow triagers to apply labels and close or reopen PRs, but not push code or merge PRs.

Archiving and unarchiving, previously restricted to administrators, are now available to Triage, Write, Maintain, and Admin users. Someone already assigned Triage no longer needs a higher role just to perform these operations.

For example, a triager could assess a spam PR and carry the moderation decision through to archiving. That does not make archiving the default destination for every finished PR: it changes visibility and conversation behavior as well.

Archiving stops activity beyond a normal conversation lock

An archived PR is hidden from public view while remaining visible to repository administrators. Archiving also closes the PR and makes its conversation read-only. This does more than remove work from the review queue.

A normal conversation lock still permits comments from people with write access and certain other collaborators. Previously, PR archiving used locking but still allowed administrators to comment.

The updated behavior blocks new comments, reactions, and automated comments while a PR is archived. It stops activity without giving triagers control over the ordinary conversation lock.

That matters if a bot is expected to post a result after archiving. If an explanation needs to remain on the PR, consider recording it before archiving. This is an operational recommendation derived from the comment restriction, rather than a newly documented automation procedure.

Treat unarchiving and reopening as separate decisions

Unarchiving restores commenting and reactions, but it does not reopen the PR. Restoring a conversation and accepting a change proposal for further review are separate actions.

For example, reversing an archiving decision simply to add an explanation does not necessarily call for reopening. Resuming review does require a separate decision to reopen the PR. Starting from the intended outcome avoids assuming that unarchiving puts a proposal back into the review queue.

The practical task for administrators is to define the work being delegated: when to archive, when to record the reason, and whether review should resume after unarchiving. Those decisions make it possible to hand over more moderation work while keeping code write access separate.

Source

• Title: Triage role users or higher can now archive pull requests
• URL: https://github.blog/changelog/2026-10-08-triage-role-users-or-higher-can-now-archive-pull-requests