GitHub Lets Admins Archive Pull Requests Without Deleting Them

GitHub has given repository admins a new tool: the ability to archive pull requests. Archived PRs are closed, locked, and invisible to non-admin visitors (who get a 404). Admins can still find them using the is:archived filter. The feature supports bulk or individual archiving and is aimed at handling spam, meeting legal retention requirements, and keeping historical context without exposing problematic PRs to the public.

What happened

Detail	Value
Feature	Archive pull requests
Who can use it	Repository admins only
Visibility to non-admins	404 response (hidden)
State after archiving	Closed and locked
Search filter	is:archived
Scope	Individual or bulk

GitHub shipped a new moderation control for repository admins on July 16, 2026. Admins can now archive pull requests, a permanent deletion alternative that keeps the PR data intact but removes it from public view. Anyone without admin access who tries to visit an archived PR URL gets a 404, as if the PR never existed.

The archived state is distinct from simply closing a PR. The PR is both closed and locked, so no further comments or changes are possible. If an admin later unarchives it, the PR becomes publicly visible again but stays closed and locked.

Why does this matter for repository maintainers?

Before this feature, maintainers faced a binary choice: leave a spammy or abusive PR visible, or lose it permanently by deleting it. Archiving fills the gap between those two options.

GitHub outlines three main use cases:

• Spam and abuse moderation: Remove harmful or low-quality PRs from public view without giving them any further attention.
• Legal and policy requirements: Some organisations need to retain records even when content cannot remain visible. Archiving preserves the data for admins while hiding it from the public.
• Historical context for admins: Teams can keep a full internal record of all PR activity, including the messy parts, without cluttering the contributor-facing view.

The is:archived filter also means admins can build triage workflows around archived content, searching and reviewing it without restoring public access.

Why it matters

Open-source project maintainers and teams running large internal repositories both deal with unwanted PR noise. A dedicated archive state is a more defensible moderation action than deleting, particularly when legal or compliance teams need an audit trail. It also signals a broader trend: GitHub is adding granular admin controls that close the gap between what large organisations need and what a general-purpose git host traditionally provides.

For teams already investing in web development workflows, tighter repository hygiene tools like this reduce the overhead of managing contributor activity at scale.

Our take

This is a small but genuinely useful addition. The gap between “visible and open” and “permanently deleted” has always been awkward on GitHub, and archiving is the obvious fix. The 404 response for non-admins is the right call: it avoids signposting that content was removed while still protecting the repository’s public face.

The is:archived filter is the detail worth noting. It means this is not just a hiding feature; it is a searchable, manageable state. Teams can audit what was archived and why, which matters if you are ever asked to justify a moderation decision. If you manage public repos or client repositories, test the bulk archive flow with a few old spam PRs and see whether it fits into your current triage process. Given GitHub’s recent pattern of expanding admin tooling (as seen with secret scanning additions in July 2026), more moderation controls are likely coming.

What to do about it

1. Check your existing spam or abusive PRs and use bulk archive to clean them from public view in one action.
2. Test the is:archived filter in your PR search to confirm archived items are retrievable before relying on it for compliance purposes.
3. Update your repository contribution guidelines to note that off-topic or abusive PRs may be archived rather than simply closed.
4. If your team has legal or compliance requirements, document the archive state as part of your data retention policy.

If archiving does not cover your needs, GitHub’s Community discussion is the place to leave feedback directly with the team.

Source: GitHub Changelog