Managing pull requests becomes more complicated as a repository attracts more contributors. Open-source maintainers may spend as much time dealing with spam, duplicate submissions, abandoned changes, and inappropriate contributions as they do reviewing code. Many projects delegate this work to trusted community members, but a permissions restriction has historically created an unnecessary bottleneck: only repository administrators could archive pull requests.
GitHub addressed this limitation on October 8, 2026, by allowing users with the triage role and higher repository permissions to archive and unarchive pull requests. The change gives maintainers more flexibility when delegating moderation without granting every moderator permission to modify repository code. GitHub has also tightened the behavior of archived pull requests so that new comments, reactions, and automated comments are blocked while an archived conversation remains inactive.
Although this is a relatively small change to repository permissions, it has practical implications for open-source project maintenance, community moderation, and pull request lifecycle management.
What Changed in GitHub Pull Request Archiving?
Previously, repository administrators were responsible for archiving pull requests. A contributor with triage permissions could help organize the pull request queue and manage routine moderation tasks, but archiving a problematic submission required assistance from someone with administrator access.
The updated permission model removes that dependency. Users with the following repository roles can now archive and unarchive pull requests:
Triage: Manage issues and pull requests without receiving code-writing permissions.
Write: Contribute code and perform repository actions available to the write role.
Maintain: Manage repository operations without full administrator privileges.
Admin: Access repository administration capabilities.
The most significant change is the addition of the triage role. This role is intended for people who need to manage repository discussions and incoming contributions without requiring permission to push code. Giving these users access to pull request archiving helps separate community moderation from code maintenance.
For projects with active contributor communities, that separation can reduce the number of routine administrative requests sent to repository owners.
How Pull Request Archiving Works
Archiving is more than closing a pull request. It changes the visibility and interaction behavior of the conversation while preserving its history for moderation purposes.
When a pull request is archived, GitHub automatically closes it and makes its conversation read-only. The pull request is removed from public view, while repository administrators retain access to its history. Visitors without administrator access who attempt to open the archived pull request receive a 404 response.
The updated read-only behavior also prevents new activity. Comments, reactions, and automated comments are blocked while the pull request remains archived. This matters because a locked conversation previously still allowed administrators to add comments. The revised behavior makes archiving a clearer boundary for conversations that should no longer accept activity.
Consider a repository that receives a pull request containing unrelated changes and repeated spam comments. A maintainer might previously have needed to contact an administrator to archive it. With the new permissions, an authorized triager can perform the moderation action directly. The pull request is closed, removed from public view, and prevented from accumulating further conversation activity.
The original history is not permanently deleted. That distinction is useful when a project needs to preserve administrative context rather than erase a submission altogether.
Archiving vs. Closing and Locking a Pull Request
GitHub offers several ways to manage pull requests that should no longer receive normal review activity. Choosing the right action depends on whether the goal is to stop work, prevent discussion, or remove a submission from public view.
Action | Main purpose | Visibility and activity |
|---|
Close a pull request | Stop the current review or contribution workflow | The pull request generally remains visible, and its conversation may still accept comments. |
Lock a conversation | Prevent further discussion | The pull request remains visible, but conversation activity is restricted. |
Archive a pull request | Remove a problematic submission from public view and preserve its history | The pull request is closed, hidden from public view, and made read-only. |
These actions are not interchangeable. Closing a pull request is appropriate when a proposed change is no longer needed, has been superseded, or will not be merged. Locking is useful when an otherwise relevant discussion has become unproductive and needs to stop.
Archiving is better suited to moderation cases where public visibility itself is part of the problem, such as spam, abusive submissions, or content that a project needs to remove from public view without permanently deleting its history.
A useful operational rule is to close ordinary abandoned work, lock conversations that need to stop, and archive submissions that should no longer remain publicly accessible.
How to Archive a Pull Request on GitHub
The workflow is straightforward for users who have the required repository permissions.
Open the repository containing the pull request.
Select Pull requests and open the submission that needs moderation.
Locate the Archive pull request action in the pull request's sidebar.
Review the confirmation message and confirm that you want to archive the pull request.
Once archived, the pull request is automatically closed and made read-only. Its public visibility changes as well, so this action should be treated as a moderation decision rather than a routine way to clean up an ordinary review queue.
To locate archived pull requests, GitHub provides the is:archived search qualifier. Authorized users can use this filter as part of their moderation workflow.
Unarchiving reverses the archived state and restores the ability to comment and react. However, it does not reopen the pull request automatically. If the contribution should return to active review, an authorized user must reopen it separately.
That distinction is easy to overlook. Restoring visibility or conversation activity does not mean the original contribution is automatically ready for review or eligible for merging.
Why the Triage Permission Change Matters
Moderation no longer depends entirely on administrators
In a large open-source project, administrators may be responsible for repository settings, access management, security policies, and other sensitive tasks. Requiring their involvement for every routine moderation action adds overhead without necessarily improving the decision.
Allowing triagers to archive pull requests lets maintainers distribute responsibility to trusted community moderators. Administrators can focus on decisions that genuinely require elevated access, while triagers handle the incoming queue.
Least-privilege access remains possible
Repository permissions should be granted according to the work a person needs to perform. A community moderator may need to identify duplicates, organize discussions, and remove problematic submissions from public view. That does not automatically mean the person should be able to push code or modify repository settings.
The expanded triage permission makes this division more practical. Teams can delegate a specific moderation responsibility without promoting every trusted moderator to a write or administrator role.
This is particularly useful when projects rely on volunteer contributors or maintainers across different time zones.
Archived conversations have a clearer boundary
Blocking new comments, reactions, and automated comments gives archived pull requests a more consistent read-only state. Without this restriction, an archived conversation could still receive activity from people or integrations with sufficient access, undermining the purpose of archiving.
The new behavior is especially relevant for repositories that use bots to add status messages, notifications, or other comments to pull requests. Automation should not assume that every closed pull request remains available for interaction.
Practical Considerations for Repository Maintainers
The new permission is useful, but archiving should still be governed by a clear moderation policy. Hiding a pull request from public view is a stronger action than closing it, and moderators should understand when the distinction matters.
For example, a stale pull request with a reasonable implementation does not necessarily need to be archived. Closing it with an explanation may be sufficient, particularly when the author could return with an updated contribution. Archiving is more appropriate when the submission itself presents a moderation concern or public visibility must be restricted.
Projects should also clarify who is allowed to archive contributions and what evidence or reasoning should guide that decision. A short internal policy can prevent inconsistent treatment of contributors and reduce the risk of legitimate submissions being hidden unnecessarily.
Another consideration is automation. Teams that interact with GitHub pull requests programmatically should account for the new archive state. GitHub's GraphQL API exposes archivePullRequest and unarchivePullRequest mutations, and the updated permission model permits users with triage access or higher to perform these operations. Automated workflows should handle authorization errors, confirm the intended pull request before archiving it, and avoid treating a successful close operation as equivalent to archiving.
Before introducing automatic archival rules, test how the workflow behaves for duplicate submissions, legitimate but inactive contributions, and pull requests that need to be restored later. An automated rule based only on age or inactivity could hide a valid contribution that simply has not received a review.
Common Mistakes to Avoid
One common mistake is treating archive and close as equivalent actions. Closing communicates that work has stopped, while archiving also changes visibility and prevents further conversation activity. Use the less restrictive action when it satisfies the project's requirements.
Another mistake is assuming that unarchiving reopens a pull request. It does not. Review the pull request's state after unarchiving and reopen it separately when renewed review is appropriate.
Teams should also avoid giving everyone write or administrator access merely to enable moderation. The triage role exists for precisely the kind of repository management work that does not require code-writing access.
Finally, do not assume that bots can continue commenting after a pull request has been archived. GitHub now blocks new automated comments while the archived state is active, so integrations must account for this behavior rather than retrying the same operation indefinitely.
Advantages and Disadvantages
Advantages
More flexible moderation: Trusted triagers can archive and unarchive pull requests without waiting for an administrator to perform routine work.
Better permission separation: Projects can delegate moderation without granting code-writing permissions solely to support archiving.
Clearer read-only behavior: Blocking new comments, reactions, and automated comments prevents archived conversations from accumulating further activity.
History preservation: Archiving removes a pull request from public view without permanently deleting its history, giving administrators a way to retain context for moderation decisions.
Disadvantages
Archiving requires judgment: Because the action removes public visibility, using it for ordinary stale or incomplete contributions can be unnecessarily restrictive.
Unarchiving requires an additional decision: Restoring a pull request does not reopen it, so the review workflow may require another explicit action.
Integrations need to account for archived state: Bots and automation that expect to comment on every pull request may fail to perform those actions after archival.
Summary
GitHub's October 8 update allows repository triagers to archive and unarchive pull requests without requiring administrator-level permissions. The change improves moderation workflows while preserving the distinction between repository management and code-writing access.
Archiving now closes a pull request, removes it from public view, and prevents new comments, reactions, and automated comments while preserving its history for administrators. Unarchiving restores interaction but does not reopen the pull request, so maintainers must handle its review state separately.
For repository owners, the practical lesson is to delegate moderation deliberately, reserve archiving for cases that justify removing public visibility, and update any pull request automation that assumes closed conversations can still receive comments. Used appropriately, the new permission helps teams manage contributions with less administrative overhead and a clearer separation of responsibilities.
Join the conversation! Your thoughts help the community grow.