GitHub Lets Triage Users Archive Pull Requests: Permissions, Read-Only Rules and Workflow Risks

What changed​

GitHub's October 8, 2026 changelog covers two things:

• Wider eligibility. Users with the triage, write, maintain, or admin role can archive and unarchive pull requests. Before this, archiving was limited to repository administrators, so triagers had to pass routine moderation work to someone with higher permissions.
• Stricter read-only behavior. Archiving used to lock the pull request, but admins could still comment on it. Now no new activity is allowed once a PR is archived.

GitHub explains the second change as a way to keep archived PRs read-only without giving triagers control over a conversation's locked state. Locking requires write access.

How archiving works now​

According to the changelog:

• Archiving automatically closes the pull request and makes its conversation read-only.
• New comments, reactions, and automated comments are blocked while the PR is archived.
• Archived pull requests are hidden from public view. Repository administrators can still see them.
• Unarchiving restores the ability to comment and react, but it does not reopen the PR. Someone has to reopen it separately.

This is about individual pull requests only. Archiving a whole repository is a separate action. In GitHub's repository-role permissions table, archiving repositories is still an admin-only action.

Why triagers​

GitHub's role documentation describes Triage as the role for contributors who manage issues, discussions, and pull requests without write access. In the permissions table, triagers can apply and dismiss labels, close and reopen issues and PRs, mark duplicates, and request reviews. They cannot merge, push code, or lock conversations.

Archiving fits that scope. GitHub's changelog says archiving is often used for spam, duplicate, or abandoned PRs. A GitHub roadmap entry for this change gives similar reasoning: it says the change lets teams reduce their reliance on write-level collaborators for routine housekeeping like closing spam or stale pull requests.

The read-only change is what makes the permission safe to hand out. If archiving still left a PR open to admin comments, triagers could not be given the power without also getting something close to lock control. Making the archived state block all activity avoids that.

Background​

GitHub introduced PR archiving on July 16, 2026, for repository admins. Archived PRs were closed and locked, and non-admin visitors to the URL got a 404. Admins could find archived PRs with the is:archived filter.

A GitHub Community thread shows how the October change came about. A GitHub staff member said on July 21 that they had received a handful of requests for archiving to be available to triage-role users or higher, and that they were looking into it. On August 6, the same thread said PR archiving was being temporarily disabled while GitHub investigated a performance issue. It added that the feature might be enabled and disabled intermittently while a stable fix was developed. That thread is the only source for those details, and I have not confirmed the feature's current stability. Teams that depend on archiving should test it in their own repositories.

Documentation is behind​

The GitHub Docs page on archiving pull requests still reflects the older behavior. It lists "Repository administrators" as the users who can use the feature and describes archived PRs as closed and locked. Its unarchiving section says the PR stays closed and locked. Treat the October 8 changelog as the authority on the new behavior, and expect the docs to catch up.

The GraphQL reference already shows the new permissions. It says users with the triage role or higher can archive pull requests through the archivePullRequest mutation. It also says users with the triage role or higher can unarchive through unarchivePullRequest, and that unarchiving does not automatically reopen or unlock the PR. So API users and automation get the same permission change as the UI.

The GraphQL page says unarchiving "does not automatically reopen or unlock" the PR. Together with the changelog, that suggests the lock state may differ from the older description of archived PRs. I would not rely on lock-state details until GitHub updates the docs.

The steps​

The current Docs page gives these UI steps. They were written for the admin-only version, but they should apply to triagers now:

1. Open the repository and go to Pull requests.
2. Open the pull request you want to archive.
3. Scroll to the bottom of the right sidebar and click Archive pull request.
4. Read the information shown, then confirm.

To undo it:

1. Find the PR with the is:archived search qualifier.
2. Open it and click Unarchive pull request in the right sidebar.
3. Confirm. The PR becomes visible again, but you must reopen it yourself if you want it open.

The docs say visitors without admin access get a 404 for an archived PR. A triager who archives a PR may therefore be unable to find it afterward unless they can still see archived items. GitHub's sources do not say how visibility works for non-admin archivers, so check this before you build a workflow around it.

What teams should do​

• Review your triage list. Anyone with triage access can now hide PRs from public view. Make sure that group is people you trust with that.
• Set expectations. Archiving is not deletion, and it is not a substitute for a closing comment explaining why. Comments are blocked once the PR is archived, so write the explanation first.
• Plan for reopening. Because unarchiving leaves a PR closed, decide who reopens PRs that were archived by mistake.
• Watch for stability. The community thread mentions earlier interruptions to the feature, so keep a fallback for spam handling.

GitHub's changelog gives no adoption data or time-saved figures, so the benefit to maintainers is a reasonable inference, not a measured result. The change is plausible and narrow, and it follows the least-privilege logic of the triage role.