Because of this mistake, the hexojs/hexo repository in GitHub lost around 41k stars that had been collected over nearly 14 years. The repository also lost around 5k forks and 800 watchers.
The repository was changed back to public about 3 hours later, but the stars, forks, and watchers won’t be restored.
On May 14, the stars and watchers of the repository have been restored successfully with the help of Github support.
A heartfelt thank you to everyone! Thank everyone who offered help and encouragement in the discussions, everyone who has continued to support Hexo, and the GitHub Support team for their assistance.
About Hexo
Hexo is a static site generator written in JavaScript / TypeScript. It runs on Node.js.
@tommy351 started the first commit in 2012 and released the first version in the same year.
By April 2026, the main repository hexojs/hexo had gained around:
- 41k stars
- 5k forks
- 800 watchers
Hexo is loved by many people around the world. Many users use Hexo to build their own blogs and websites. Over the years, many contributors helped improve Hexo and build its community.
What happened
On May 8, 2026, one owner of the hexojs organization was programming on his personal computer. He was doing local development inside a clone of the hexojs/hexo repository. At the same time, he was also using one of his own personal repositories for testing. After finishing his work, he wanted to temporarily hide his personal repository. He used the interactive gh repo edit command from GitHub CLI to change his own personal repository’s visibility to private.
This is where the problem happened.
He switching between multiple shell windows, he forgot to carefully confirm the current working directory before running the dangerous command.
As a result, he accidentally ran the GitHub CLI command inside the local directory of hexojs/hexo. The visibility of hexojs/hexo was changed from public to private unexpectedly.
At that moment, around 41k stars, 5k forks and 800 watchers disappeared.
About three hours later, he noticed something unusual on the GitHub website. There was a lock icon trailing to the hexojs/hexo repository name, and it was obviously not the HTTPS lock icon. At first, he thought that another member might have changed the repository to private, either for some reason or by accident. So he checked the audit log and realized that the person was himself.
However, after changing the repository back to public, it did not restore the lost stars, forks, or watchers.
Impact
For Hexo users
For users who build websites with Hexo, this should not cause any significant problems. Your website build process should continue to work normally. Most users install Hexo packages from npmjs, so the package distribution itself was not affected.
For people sho starred or watched hexojs/hexo
If you starred hexojs/hexo repository during the past many years, you may notice that the repository disappeared from your star list unless you star the repository again.
The same is true for watchers. You may no longer receive hexojs/hexo updates in your GitHub feed page unless you watch the repository again.
For people who forked hexojs/hexo
If you forked the hexojs/hexo repository before, you may notice strange changes in your fork relationship. For example, GitHub may show that fork relationship disappeared or your repository was forked from another user’s hexo repository instead of from hexojs/hexo repository.
In most cases, this should not be a serious problem. If necessary, you can simply fork a new one again.
For contributors
For everyone who contributed to Hexo, this may be very sad news. Today’s Hexo exists because many community members worked together for many years. Stars are not only numbers. They also represent effort of contributors and recognition from users. We truly feel deeply sorry and upset about what happened. We sincerely apologize to every contributor of Hexo community.
If possible, We truly hope these data could be recovered.
Additional findings
A deleted Github repository could be restored
I noticed that there is a tab called “Deleted repositories” in the GitHub account settings page, where deleted repositories can be restored. So I did a small experiment:
- I created a repository with account A, and then starred the repository with account B.
- After that, I deleted the repository and then restored it.
- I found that the repository stars did not being erased after the restoration.
This means that, according to GitHub’s current behavior, changing a repository’s visibility to private may actually be more dangerous than deleting the repository!
Advice
Don’t change GitHub repository to private.
As Qovery once said , we should never change a public GitHub repository to private. As shown by the experiences of HTTPie, Qovery, and now Hexo, changing repository visibility from public to private may cause permanent loss of community data. GitHub documentation also warns about this problems.Declare target repository explicitly.
When using GitHub CLI, we should clearly specify the target repository via command line arguments instead of relying on the default remote repository which is set by yourself or GitHub CLI. This is especially important when performing risky operations.Keep your software updated.
As discussion in hexojs#5775, I was using an old version of GitHub CLI at that time. This may have caused me to miss some GitHub reminders and warnings, which may have partly contributed to this Hexo incident.Restrict permissions to reduces the risk of accidental changes.
There is a setting in Github organization’s settings which called “Repository visibility change”. If disabled, only organization owners can change repository visibilities. Although it did not help in this Hexo incident (the person involved is one of owners), it may help others reduce the risk of accidental changes.Hope GitHub can improve this issue.
As mentioned earlier, this is not the first time something like this has happened. If there is no way to improve this issue, then similar incidents are very likely not going to be the last. As mentioned before, deleted repositories can be restored. So why can’t repositories with changed visibility be restored as well? I hope GitHub can improve such issue by providing a recovery feature.
In general, before doing any dangerous operation, we should always check carefully again and again. A small mistake may cause irreversible results.
]]>