GitHub has added a moderation-focused control for pull requests on GitHub.com: repository administrators can now archive them. Announced on July 16, 2026, the feature removes an archived pull request from public view without permanently deleting the administrator-visible record.
This is narrower than a new review or merge workflow, but it closes a real gap for public repositories. Closing a pull request can end the contribution workflow while leaving the page visible. Archiving adds a separate visibility decision for cases such as spam, abuse, or a documented policy requirement.
What happens when a pull request is archived
Archiving combines three state changes. GitHub closes the pull request, locks it, and marks it as archived. Only repository admins can then see it. A non-admin who visits its URL receives a 404 response, so the page is not merely removed from a list or marked with a banner; it is unavailable to that visitor.
GitHub says admins can archive pull requests individually or in bulk. Archived items remain discoverable to admins through the `is:archived` search filter, providing a way to review the hidden set later instead of treating the action as irreversible cleanup.
The permission boundary matters. GitHub's GraphQL documentation says only repository admins can run the `archivePullRequest` and `unarchivePullRequest` mutations. The sources do not extend this authority to contributors, triagers, or users with write access, so teams should not describe the feature as a general maintainer control.
Archiving is not the same as closing or deleting
GitHub's GraphQL schema exposes closing and archiving as separate operations. The `closePullRequest` mutation closes a pull request. The `archivePullRequest` mutation closes, locks, and adds the archived state. The practical distinction is public visibility: ordinary closure is appropriate when work has stopped, while archiving should be reserved for a deliberate decision to hide the pull request from non-admins.
Archiving is also not permanent deletion. GitHub presents it as an option for spammy or abusive pull requests, situations involving legal or policy requirements where deletion is not preferred, and cases where administrators still need historical context. Those are examples, not a guarantee that the feature satisfies an organization's legal-retention or compliance obligations.
Restoration is deliberately limited. Unarchiving removes the archived flag and makes the pull request visible again, but it does not reopen or unlock it. If a team wants to resume discussion or development, unarchiving is only the first step; the pull request remains closed and locked until separate actions change those states.
Search and automation have different scopes
The `is:archived` filter gives administrators a direct triage view for archived pull requests. A repository dealing with recurring abuse or spam could use that view for periodic review, while a one-off policy decision can still be handled individually.
GitHub's GraphQL API exposes `archivePullRequest` and `unarchivePullRequest`. Each mutation accepts the pull request's Node ID and returns the affected pull request. The input is singular: it accepts one `pullRequestId`. The changelog confirms bulk archiving in the product, but the published GraphQL reference does not describe a batch archive mutation. Automation guidance should therefore avoid calling the GraphQL operation a bulk endpoint.
The release does not announce bulk unarchiving. It also does not state a retention period, guarantee indefinite preservation, or describe archiving as a way to remove associated branches, commits, forks, or copies. This is a visibility control for the pull-request page, not a repository-sanitization feature.
A conservative policy is better than ad hoc use
Because archiving makes a pull request return 404 for non-admins, it should be treated as a content-visibility control rather than routine backlog hygiene. A small policy can make the action easier to explain and reverse.
First, define the eligible reasons. GitHub names spam, abuse, and legal or policy situations, but each organization must decide who assesses those cases. Second, record the reason, actor, and date in an appropriate internal system when governance matters. An admin-only GitHub record should not automatically be called a legal hold, evidence archive, or compliance log.
Third, test the complete path before using bulk archiving: archive a non-critical pull request, confirm non-admin and admin visibility, verify `is:archived` search, and then unarchive it to confirm that it returns as closed and locked. Finally, keep ordinary closing as the default when the goal is simply to reject or stop work rather than remove a page from public view.
What the feature changes—and what it does not
Pull-request archiving gives repository admins a reversible way to remove problematic contribution pages from public view while keeping them accessible for administrator review. It is useful precisely because its scope is clear: archive, hide, search, and restore visibility.
It does not erase the pull request, grant the action to non-admin maintainers, or return an unarchived pull request to an open and unlocked state. GitHub also does not claim in the cited sources that archiving creates a compliance-grade record. The announcement does not establish GitHub Enterprise Server availability or plan-tier coverage, so those should be verified separately rather than assumed.
Used with those limits in mind, the feature is a practical new moderation control rather than a replacement for an organization's broader governance process.
Sources
GitHub Changelog, July 16, 2026, Repository admins can archive pull requests: https://github.blog/changelog/2026-07-16-repository-admins-can-archive-pull-requests/
GitHub GraphQL reference, pull-request mutations and input objects: https://docs.github.com/en/graphql/reference/pulls
