Warn or prevent mentioning (@'ing) a user not involved in a project/repo

[chris]

Select Topic Area

Question

Body

I routinely get mentioned (@'ed) in pull requests for repos I have nothing to do with. This is because people apparently type and don't bother to see the auto-complete and the correct person, as I have a very common name (I'm chris on GitHub, so @chris where people don't bother to realize I'm not the Chris they think, adds me as a watcher to repos and pull requests I have nothing to do with. I often receive several of these per week, and thus have to go to the repo, and set the Watch status to be Ignore. I'd like to suggest an improvement to try to help prevent this. Ideas:

• don't even show users who don't have access to a repo, when doing the @ auto-complete list. And, if the person doesn't use the auto-complete, but types it anyway, don't actually link to that person (and of course don't add them as a watcher). This may need to be combined with...
• show a warning or prompt when someone mentions someone who isn't involved with the repo, to help them realize they are most likely @'ing the wrong person.

(p.s. note, I did search to try to find a discussion about this already, but "mention" and "@", are hard/massive search hits, so apologies if this has already been requested.)

[queenofcorgis]

Hey there @chris - appreciate the feedback and I totally understand the sentiment especially when you have a common name (my brother, father, and grandfather are all Chrises as well 😄 ) . I've updated the label on this to product feedback so it can be reviewed by the appropriate team. Thanks for coming by the GitHub Community Discussions and sharing how we can improve!

[bricefriha]

It is worth mentioning that there are many scam comments to issues and PR where the poster @'s random people. it's super annoying, and on top of that, there are no accurate ways of reporting these. This should be addressed ASAP

[gianmarcotoso]

This is becoming a problem, I'm receiving 4-5 email a day for scam comments with mentions of my name in repositories I've never seen before, and they can't even be reported. Being able to prevent mentions would help mitigate this.

[starsoccer]

It would be nice if there was a way to either block notifications from some specific projects/repos, or alternatively limit the amount of users that can be tagged in a message to prevent this

[JaneSmith]

I get this all the time. It's starting to get really annoying. :(

[DrKaoliN]

This issue should have been solved by now 😕. As a GitHub user I should be able to select who is allowed to mention me - for instance users that I'm following.
This weekend I've been mentioned four times by spammers for crypto-scams.

[tanujdamani]

This is becoming a serious problem.
I report these comments and scams but it’s escalating.

Got a flurry of 13 spam comments mentions today all at once. It’s annoying because if we turn off email and push notifications for tags, then we will miss out on the important ones.

There has to be a way to block the people not following us, and/or only allow tagging by followers and people we follow.

[ittixen]

Pretty bizarre we can't type "@something" without some random stranger who happens to have that username being tagged. Even in commit messages in a private repo. Forces to reword things in very awkward ways.

[tomquist]

Is this actually the case? If you tag someone in a private repo, will they receive these messages?

[j1m-renwick]

I accidentally mention people all the time on PRs when discussing java annotations and the like - I think part of the fix could be to change the text parsing to target something more rarely used accidentally, possibly @j1m-renwick@

[marlonbarcarol]

There are people currently using this as a phishing mechanism, they are spamming random people with scams. Just take a look at this person setting up an empty repo and opening loads of issues (500+) and tagging random folks on it, so people receive an email with the phishing. For example ➡️ kamino-fi/kamino-finance#500
At the moment, there is no way of preventing people from tagging me on repos that I don't care about, or even of blocking receiving email notifications from repos that I also don't care about. Those actions should only be allowed for repos that I care about, not a random creepy dude tagging me on random issues 🤦‍♂️
Honestly, most importantly, this is a security issue!

Update
Just saw that someone else has raised another discussion about being able to report repositories due to the spammer https://github.com/orgs/community/discussions/174223

[Visual-Studio-Coder]

Yeah its happened to me twice now. Reported and got those accts banned twice already.

[ChronSyn]

It's 2025. As a user of the site, I should have control over who can tag me. Offer the following options:

• Anyone
• Nobody
• People I follow
• People I've interacted with (e.g. comment responses to users)
• People who are part of the following organisations:
• Repositories I have contributed to in: <the past week | the past month | the past 3 months | the past 6 months | the past year | any time>
• Issues I have commented on in: <the past week | the past month | the past 3 months | the past 6 months | the past year | any time>
• Discussions I've interacted with in: <the past week | the past month | the past 3 months | the past 6 months | the past year | any time>

Selecting 'anyone' or 'nobody' would lock out the other options, but if neither of those are chosen, then the other available options are dropdowns or checkbox lists.

There may need to be some exceptions or allowances around this. For example, if I open a PR to a public repo, then people who are also contributors to the repo (or maybe just maintainers?) should be able to tag me for the purpose of getting the PR merged or addressing any issues.

Also, one caveat: commenting in a discussion or issue shouldn't automatically enable people to tag others. For example, if I've commented on something 7 years ago, and some spammer/scammer decides to also comment on it, then that shouldn't enable them to tag me in things. If I choose to reply to them, then by all means, allow the tagging. If the user is blocked or reported though, then the tagging ability should be revoked.

Perhaps the default selected options should be all options except 'nobody' and 'anyone'. Straight away, that'd stop every single spambot from tagging random people. They'd at least have to get the other party to interact with them in some meaningful way.

In terms of implementation, I would propose a pre-processing step when submitting anything which allows tagging, essentially looking up all user tags, and checking for an allow/deny relationship between the tagger and the tagged. For any tags returning as deny, remove the name from the output content. That way, the evidence of who they tried to tag isn't even present, and it may even mean that absolutely nobody gets tagged (if all users have settings that deny such interactions). This pre-processing step should happen before the submission goes 'up the chain' - i.e. before it hits any notifcation-related code.

It could even go further than this, for example, by using a database trigger that runs before 'taggable content' is inserted. If a certain percentage of attempted tags are 'deny', then refuse to insert the content into the database. Respond to the request with the content, and refill it in the page, but also send minimal error message to the sender advising that they attempted to tag too many people without prior interaction.

Give us control, Github. Let us decide who can tag us. We shouldn't be having to deal with random spammers tagging us at all hours of the day because you refuse to implement any sort of controls for us.

[dgrr]

Hello, retards are spamming github with mentions, they delete the repos and we have the notification pending forever.

[marlonbarcarol]

I just got the gitcoin one now

Hey there @chris - appreciate the feedback and I totally understand the sentiment especially when you have a common name (my brother, father, and grandfather are all Chrises as well 😄 ) . I've updated the label on this to product feedback so it can be reviewed by the appropriate team. Thanks for coming by the GitHub Community Discussions and sharing how we can improve!

@queenofcorgis You've mentioned in this discussion that a relevant team will be reviewing this matter. Do we have a timeframe for when this will be discussed, please? 🙏
By the looks of it, spam on GitHub will only intensify. I will have to disable any notifications from GitHub, as I don't see any other way around this.

[x1unix]

Same

[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. ⭐

[queenofcorgis]

@marlonbarcarol the message above explains a bit more about our product feedback process, but for now there is a way to explore reducing noise from getting @mention notifications:

Edited to provide more correct information

Thanks @x1unix for flagging that my original information was not correct.

I think the best option to explore would be custom notification filters, read our doc on how to set those up.

[x1unix]

find the section for "Participating and @mentions," and choose the option to only get notifications when a collaborator mentions you.

@queenofcorgis where this option is located? I can't find it.

[nikaro]

I've found a workaround to mark as read notifications from spammers/scammers whose repositories have been deleted in the meantime.

Using gh CLI, get your unread notifications:

gh api /notifications

You can play with jq to make the output more readable, example:

# gh api notifications | jq '{id: .[].id, title: .[].subject.title}'
{
  "id": "19088061332",
  "title": "Gitcoin | $15M Github Developer Fund 2025"
}

Then you can mark the thread as read and/or unsubscribe from it:

gh api -X PATCH /notifications/threads/19088061332                # mark as read
gh api -X DELETE /notifications/threads/19088061332/subscription  # unsubscribe 

Now your GitHub notifications icon can make sense again...

[seevee]

I tried this, but got a 404 on the PATCH/DELETE:

# gh api notifications | jq '{id: .[].id, title: .[].subject.title}'
{
  "id": "19201745078",
  "title": "Plasma Foundation | Over USD 2.4B TVL & 54.02% APY, XPL and Staking Rewards"
}

# gh api -X PATCH /notifictions/threads/19201745078
{
gh: Not Found (HTTP 404)
  "message": "Not Found",
  "documentation_url": "https://docs.github.com/rest",
  "status": "404"
}

[nikaro]

You have a typo:

gh api -X PATCH /notificAtions/threads/19201745078
                        ^

The a is missing.

[seevee]

Right you are, doh!

Thanks for the tip!

[dgrr]

Thank you bro, you are a national hero. Amazing that github has an army of engineers and none is able to help

[Stamp9]

Thanks! It really helps!

[ballidev]

I hate that this is an issue that's been alive for years

If I copy text from slack etc into github - the user names match up with github user names all the time. Then that random person gets a notiif from my private repository. Totally unacceptable and basically insane

I should be able to configure who can be @ notified or even suggested

Is there any way at all to fix this on the outbound side? To be honest - i would be willing just to turn off @ mentions for private repos completely - rather than that accidently pinging random people with potentialy sensitive info

[owurman]

There's also a user @objc who probably gets tagged accidentally all the time when someone is literally referring to the @objc Swift decorator. I know I just did it, and now I wonder if I gave him visibility into my repo or something?!

[hraftery]

Commenting to emphasise the suggestion in the OP, which may have been lost in the discussion - the onus could be on the sender rather than the receiver. In other words, if it was harder to @ "irrelevant" users, recipients would have less of a problem to solve.

I just pasted a long list of error messages into a CSS related issue. I wanted the numbered list so didn't wrap it in code tags. I nearly submitted before I realised I was about to tag some user named import a hundred times! IMHO, that shouldn't have been so easy.

[juanchristian]

It's ridiculous that GitHub has not implemented this yet. This is also being exploited in phishing campaigns, with adversaries creating fake repos and discussions to mimic security reports, embedding malicious links disguised as fixes or patches, and tagging large numbers of random users in the hopes that someone falls for it.

[truemogician]

I can't believe that this discussion has been here for more than 2 years and GitHub still hasn't taken any action. GitHub scammers these days are wild and being disturbed by random scams from GitHub from time to time really pisses me off.
GitHub's dereliction of duty is the single biggest factor that contributes to the outrageous scam campaigns.

[JaneSmith]

Can we please get a solution to this? My name seems to be a common target for this and I am so so so sick of getting notification spammed. This is so incredibly frustrating.

Examples:

• Blog Writing guideliness recodehive/recode-website#1483
• Blog Writing guideliness recodehive/recode-website#1482
• Initial landing page RasikhNatiq/launchmind-landing#21
• Agent Github Integration quantified-uncertainty/roast-my-post#23
• Build CLI tool to validate metadata compliance umarali-nagoor/Test_Repo#10
• Enable zero-touch incident response via Slack umarali-nagoor/Test_Repo#8
• Script control evidence capture for compliance umarali-nagoor/Test_Repo#7
• feat: set visibility modes, public browsing, song knowledge levels, and full name display bkramarz/singjam-connect#110

[ryderderder]

Bump.

[dbtx]

I had no idea this was a thing until today when I got 4 sudden notices of mentions. Apparently somebody named a variable dbtx, and for whatever reason in whatever files it also gets the @, so now the PR / commit / etc noise is headed to me. Great. Just fantastic. I would like to be able to block that repo or any notifications regarding that repo. That could solve my problem, though not everyone's. I can block the user who owns it, and I did, and we'll see how well that goes. But two of the four emails were from CodeRabbit, and you apparently can't block agents or bots or however the kids are inordinately glorifying them today. (Yes, I absolutely DO want that.) That's disappointing, and I will probably just have to turn off mentions. Good luck not going insane, everyone. I'm sorry.

EDIT: I had no idea about Ignore, either. OK then. It still doesn't help you, or prevent me needing to do it again and again with no way to stop it until after it happens.