GitHub Issues Gets Label Archiving and Smarter Suggestions

GitHub has shipped two label management improvements for Issues, now generally available. Repositories with long label lists can archive labels they no longer use, removing them from the picker without deleting their history on existing issues. A new suggestions feature also surfaces labels based on recent repository activity and the individual user's own labeling habits, reducing the need to scroll through the full list every time.

What happened

GitHub rolled out two updates to label management in Issues on August 27, 2026, marking them as generally available for all repositories.

What the two features actually do

Suggested Labels

When you open the label picker on an issue, GitHub now shows two suggestion types. The first is based on labels the repository has used recently. The second is based on your own personal labeling history, surfacing the labels you reach for most often. Neither requires any configuration.

Label Archiving

You can now archive a label instead of deleting it. Archived labels are hidden from the label picker, so they stop cluttering searches in large repositories. Critically, any issue that already carries the label keeps it. The label’s history is preserved. If you need the label again, you can restore it from the repository Labels page at any time.

Why does this matter for teams managing large repos?

The problem this solves is real. Repositories that have been active for years tend to accumulate dozens of labels, many of them outdated or one-off experiments. Previously, the only clean-up option was deletion, which stripped the label from issue history and made past triaging harder to audit. Archiving threads that needle: the picker stays clean, the history stays intact.

Suggested labels reduce the low-level friction of issue triage, particularly for contributors who are not deep in a project’s labeling conventions and would otherwise skip labeling altogether.

Our take

This is a small but practical improvement. Label debt in GitHub repos is a genuine nuisance, and the previous all-or-nothing choice between keeping a messy list and deleting history was a poor trade-off. Archiving is the right call and it is surprising it took this long to arrive.

The suggestions feature is useful, though its value will depend heavily on whether the underlying recency signals are tuned well. If it surfaces stale labels because a repo had a labeling spike six months ago, it will train people to ignore it quickly. Worth testing on a busy repository before trusting it in a triage workflow.

Teams using GitHub for client project tracking, alongside other web development workflows, will find archiving the more immediately useful of the two. Suggested labels will matter most to open-source maintainers handling high volumes of new contributor issues.

For context on how GitHub has been iterating its developer tools, see our coverage of the GitHub Rule Insights Dashboard, another recent generally-available release.

What to do about it

1. Open your repository’s Labels page and audit labels you have not used in the past six months.
2. Archive any that are inactive but might be referenced again, rather than deleting them outright.
3. Delete only labels you are certain will never be needed again.
4. Open a few issues and test the suggested labels feature to see whether the suggestions match your team’s actual habits.

Archive first, delete only when certain. That is the practical rule here.

Source: GitHub Changelog