Contributors sidebar lists a user with no commits — survives history rewrite, rename, archive, block and visibility flip

[JoshPola96]

🏷️ Discussion Type

Bug

Body

29 of my repositories show a second contributor in the sidebar Contributors panel. That account has never authored a commit, opened an issue or PR, forked, starred, watched, or been a collaborator on any of them.

I've spent a while narrowing this down and I'm out of things to try, so I'm hoping someone knows what actually invalidates this index.

Every other surface says the repo is clean

Taking one repository as representative:

Surface	Result
GET /repos/{owner}/{repo}/contributors	owner only
GET /repos/{owner}/{repo}/stats/contributors	owner only
GET /{owner}/{repo}/graphs/contributors-data	owner only
collaborators, subscribers, stargazers, assignees	owner only
Issues and PRs, all states	0
GET /repos/{owner}/{repo}/git/refs	refs/heads/main only
All commits, fully paginated — author, committer, linked account, message body	no occurrence

But GraphQL disagrees:

repository(owner: "...", name: "...") {
  mentionableUsers(first: 30) { nodes { login } }
}

returns two logins. The sidebar count matches mentionableUsers exactly — not any of the contributors endpoints.

How it started

In August a batch of commits briefly carried Co-Authored-By trailers naming that account. I rewrote history to remove every one and force-pushed. The commits have been clean for two months. The index has not rebuilt.

Control case

A repository I created in September, after the cleanup, is unaffected. New repos don't inherit it — so this is stale per-repository state, not something attached to my account.

What does not clear it

All tested on a throwaway repo, polling mentionableUsers throughout and checking stars, forks, topics, licence, description and HEAD sha were unchanged after each:

Attempt	Polls	Result
History rewrite + force-push	—	no effect in two months
Rename away and back	14	present throughout
Archive and unarchive	10	present throughout
Blocking the account	6	present throughout
Private, then public again	3 + 6	cleared while private, returned the instant it went public

That last one is the interesting part: going private appears to fix it, but it only serves a restricted view. The entry is still underneath and comes straight back.

The question

Is there any supported way to force mentionableUsers to rebuild from current commit history?

Deleting and recreating isn't viable — four of these repositories carry stars and forks I'd lose.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[JoshPola96]

Solved. The fix is to rename the default branch away and back — not the repository.

Credit to #197389, where @Diptish-De, @cconsta1, @IAsDoubleYou and @scooper4711 reported this working. I'd missed it because I read "rename it and rename it back" as the repository-level operation, which does nothing.

The fix

gh api -X POST repos/OWNER/REPO/branches/main/rename -f new_name=main-reindex
# wait ~60s
gh api -X POST repos/OWNER/REPO/branches/main-reindex/rename -f new_name=main

Or via the web UI: Settings → Branches → rename the default branch, wait, rename it back.

Measured timing on my repo, polling mentionableUsers every 15s:

22:48:39  claude,JoshPola96
22:48:54  JoshPola96          <- cleared, ~60s after the rename
rename back
22:48:57 .. 22:50:17  JoshPola96   (held across 6 polls)

/stats/contributors returned empty (202, recomputing) during the window. That's the tell that a rebuild was actually triggered — none of the other five methods ever produced it.

Unchanged afterwards: stars, forks, subscribers, topics, licence, description, social preview, HEAD sha, and refs back to refs/heads/main.

@scooper4711's note matters: wait before renaming back. Renaming back immediately doesn't give the rebuild time to run.

What does not work

Tested on a throwaway repo first, polling throughout:

Attempt	Polls	Result
History rewrite + force-push	—	no effect in two months
Repository rename away and back	14	present throughout
Archive and unarchive	10	present throughout
Blocking the account	6	present throughout
Private, then public again	3 + 6	cleared while private, returned the instant it went public

Two of these are worth flagging for anyone else debugging this:

Repository rename ≠ default-branch rename. The repo rename is the more natural reading and it does nothing. It has to be the branch, because that rewrites the ref — a force-push changes the objects without firing whatever event the index subscribes to.

The private/public flip is a trap. Going private appears to fix it: the entry genuinely disappears from both mentionableUsers and the sidebar. It returns the moment the repo goes public again. Private serves a filtered view rather than rebuilding, so anyone who tests this and stops while the repo is still private will conclude they've fixed it. It also costs stars and forks permanently, so it's the worst available option.

Context for anyone landing here

This is a known, logged bug — a GitHub maintainer confirmed on 1 Oct 2026 in #207782 that the team is investigating, with no timeline. It isn't specific to one tool: #207341 is the same symptom with Cursor Agent, and that author is stuck in a Support → Community → Support loop. Related: #189812, #202123, #191565.

Until it's fixed properly, the branch rename is a working, non-destructive workaround.