GitHub improved how maintainers manage blocked users on 21 August, and the change is small enough to miss and specific enough to matter if you have ever tried to moderate a project with more than a handful of blocks.
The previous interface made blocking a new user and reviewing existing blocks feel like the same action, and once a list grew past a dozen entries, finding a specific one meant scrolling and guessing. That is what got fixed.
What changed
Five specific improvements, all aimed at the same problem — a list that grows and nobody could search:
- Search by username, full name or email
- Sort and paginate rather than scroll one long list
- Filter by block reason — spam, misconduct or harassment among the categories named
- Add a private note to preserve the context of why someone was blocked
- See who created an organization-level block and when it expires
The interface separation is the real fix
GitHub's own framing names the actual bug being fixed: the interface now clearly separates searching the blocked-user list from blocking a new user, which helps you find cases faster and avoid accidental blocks.
Two different actions sharing one interface is a design mistake that gets worse with scale. A maintainer checking whether someone is already blocked and a maintainer blocking someone new were doing visibly similar things in the old flow, and the failure mode — accidentally blocking the wrong person while trying to look something up — is exactly the kind of mistake that erodes trust in moderation decisions when it happens in public.
Private notes are the part worth adopting deliberately
A block without a note is a decision nobody but the person who made it can defend six months later. The new private-note field is where that context now lives, and it is worth treating as mandatory in your own moderation practice rather than optional.
Write down what happened and why, at the time you block, not from memory when someone eventually asks. The value of a note is entirely in how contemporaneous it is.
Where this fits
This lands in the same month as organization-level pull request limits, which cap how many open PRs a user without write access can have at once. Both are responses to the same underlying pressure: contribution volume that used to be small enough to manage by memory is no longer small, and the tooling that assumed a short list is catching up.
Available for both personal accounts, under Settings → Moderation → Blocked users, and organizations, under Organization settings → Moderation → Blocked users.