Bug: Ghost Notifications

[runxel]

Select Topic Area

Bug

Body

There seems to be a growing scam where people open up repos and then spam issues where they @ as many folks as possible to draw attention.
However, when this happens and the repo gets deleted for being spam, the associated notifications are not cleared, and also can not be cleared by the user either.
I now live with these ghost notifications, where I get the lil' bubble next to the icon etc. but clicking on it will give me an empty page with nothing to act on.

Here is one recent example:

Clicking on this direct filter does obviously nothing as well – as it doesn't exist (anymore)!

Very infuriating.

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

[bamjun]

https://github.com/orgs/community/discussions/174283#discussioncomment-14527039

you can use this

uvx fown auth login

uvx fown noti delete -r

[shibe2]

I see blue circle indicator on notifications button. On unread notifications page, I see empty list and "1-0 of 2" at the bottom near "Prev" and "Next" buttons.

[crowne]

I don't see this as a category

Use the "Account" → "Notification problems" category

I see "Account or Billing issues" then a dropdown of sub-options nont of which look like "Notifications",
the last option is "Other"

[queenofcorgis]

@Omprakash3104

We’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.  You can read our updated Code of Conduct and the announcement for more details. Thank you for helping us maintain an authentic and beneficial space for everyone.

[sigoden]

Fixed by https://github.com/orgs/community/discussions/174246#discussioncomment-14471133

gh api notifications -X PUT -F last_read_at=2025-09-28T00:00:00Z

[runxel]

1. It only works when installed the GitHub command line tool. Not everybody has it installed or wants to install it.
2. This is still a product issue that should not need this kind of workarounds but must be fixed by GH.
3. Using curl is a nicer workaround.

[rushiiMachine]

Using curl requires creating a GitHub PAT, which will require verifying with 2FA.... I think the GitHub cli is much easier if you already have it set up

[Nandarathana]

Fixed by https://github.com/orgs/community/discussions/174246#discussioncomment-14471133

gh api notifications -X PUT -F last_read_at=2025-09-28T00:00:00Z

YES

[Alhadis]

Using curl requires creating a GitHub PAT, which will require verifying with 2FA

The solution I detailed earlier in this discussion doesn't require 2FA, only that a (classic) personal token be created with sufficient read privileges.

I think the GitHub CLI is much easier if you already have it set up

Yes, if and only if you have that thing installed and configured in the first place. That's a non-starter for those of us who prefer not to install the CLI.

[csvn]

Amazing. Was reported almost 4 years ago, but still an issue now:
https://github.com/orgs/community/discussions/6874

When spam projects are banned, is it really that hard to also get rid of notification spam at the same time..?

[csvn]

I created a Gist to address this with Deno: https://gist.github.com/csvn/ecf6ff88524eb3a604c1d9817a8d3991

But I found this thread with a much simpler solution, which is to just run a couple of console commands: https://github.com/orgs/community/discussions/6874#discussioncomment-14507162

[superherointj]

I was affected by this ghost notification too. Someone opened a scam repo and added me to it.

gh api notifications -X PUT -F last_read_at=2025-09-28T00:00:00Z

This worked.

[Alhadis]

I finally cracked the shits with this bug and wrote a shell-script function to mark all notifications as read (which implies that the ones that aren't trapped in the Ethereal Plane have been read/dismissed):

fuck_your_gitcoin(){
	curl -L -X PUT \
		-H "Accept: application/vnd.github+json" \
		-H "Authorization: Bearer $GITHUB_TOKEN" \
		-H "X-GitHub-Api-Version: 2022-11-28" \
		https://api.github.com/notifications \
		-d '{"read":true}'
}

For this to work, a (classic) personal token needs to be registered and set in your environment (i.e., export GITHUB_TOKEN=something_cryptic_and_hard_to_pronounce). More about that can be found in GitHub's docs.

I'm aware this isn't a real solution, as this needs to be fixed on GitHub's end. However, I don't have gh installed (and prefer not to, either), so using GitHub's REST APIs via good ol' curl(1) felt like a less invasive stopgap.

[runxel]

Yes, that's what I ended up doing in the end, too!
Thanks for sharing that workflow here again for everybody – it's just mind boggling it effects soo many people and GH doesn't bat an eye.

[JulianAnthes]

I was harassed by plasma.to crypto bros, too. Running fuck_your_gitcoin fixed it, thanks for sharing.

[nousantx]

@dschu-lab same here

[rushiiMachine]

I've seen solutions to mark notifications as read, but it doesn't change the fact that they're still not deleted, and appear in the repositories sidebar. Does anyone have a similar API workaround to find and delete these (already marked read) notifications?

[rushiiMachine]

The devtools solution didn't work for me, I ended up deleting each notification with an API call:

# Dump all notifications to find the ids of scam notifs
$ gh api notifications > notifications.json

# For each scam notification
$ gh api -X DELETE notifications/threads/<id>

[ffgan]

The devtools solution didn't work for me, I ended up deleting each notification with an API call:

# Dump all notifications to find the ids of scam notifs
$ gh api notifications > notifications.json

# For each scam notification
$ gh api -X DELETE notifications/threads/<id>

This works for me

[Alhadis]

# For each scam notification
$ gh api -X DELETE notifications/threads/<id>

@rushiiMachine Does this technique still work with ghost notifications that've previously been marked "read"? I attempted to do the RESTful equivalent of that second gh command (targeting notification sources marked as read using this), but to no avail:

Click to show (failed) curl(1)-based approach

curl -L \
	-H "Accept: application/vnd.github+json" \
	-H "Authorization: Bearer $GITHUB_TOKEN" \
	-H "X-GitHub-Api-Version: 2022-11-28" \
	'https://api.github.com/notifications?all=true&participating=true' \
| jq -r '
	map(select(.repository.owner.login |
	IN("gitcoin-member", "club-paradigm"))) |
	map(.id + ":" + .repository.full_name)[]
' | while IFS=: read -r id name; do
	if curl -L -X PUT \
		-H "Accept: application/vnd.github+json" \
		-H "Authorization: Bearer $GITHUB_TOKEN" \
		-H "X-GitHub-Api-Version: 2022-11-28" \
		-d '{"ignored": true}' \
		"https://api.github.com/notifications/threads/$id/subscription"; \
	then printf '\nDeleted subscription #%s (%s)\n' "$id" "$name"
	else printf '\nFailed to delete subscription #%s (%s)\n' "$id" "$name"
	fi
done

In fact, not only did my curl(1)-based approach fail, it managed to do something worse: push the offending scammers to the top of the Notifications page's "Repositories" section:

[rushiiMachine]

Does this technique still work with ghost notifications that've previously been marked "read"?

It worked for me, yes. I don't recommend automating this or you might end up deleting all your notifications instead.

[Alhadis]

It worked for me, yes.

Alright, thanks. That means there's some discrepancy between what APIs gh is consulting, and GitHub's RESTful API for deleting subscriptions to notification threads. Interestingly, ghost notifications are still returned by https://api.github.com/notifications?all=true (even returning the title of the now-inaccessible issue used to spam mentions), but they can't seem to be deleted by their reported notification IDs…

[crowne]

Thanks @ffgan
whack-a-ghost.ps1

[shibe2]

False notification indicator disappeared without me taking any action to fix it.