Transferring a GitHub repository keeps issues, pull requests, stars and git history, and old links redirect. It also carries over webhooks, secrets and deploy keys, which is exactly what you may not want. Rotate those, check package links, and never create a new repository at the old name afterwards.
Why this is a security event
Ownership changes are a known supply chain weak spot. A package handed to a stranger, who then ships a malicious release, has happened in the real world. The new owner inherits the trust your users place in the name. Treat a transfer as a deliberate decision, not a favour.
What GitHub says moves
From GitHub's documentation, these stay with the repository:
- Issues, pull requests, wiki, stars and watchers
- Git history and commit contributions
- Webhooks, services, secrets and deploy keys
- Forks, which remain associated
- Git LFS objects, which move in the background
The original owner becomes a collaborator, and existing collaborators stay.
What changes or breaks
- Private repositories moved to a free account lose features such as protected branches and Pages.
- Packages may transfer or lose their link to the repository, depending on the registry.
- Sponsors with access through a sponsorship tier may be affected.
- Moving into an organization applies that organization's default permissions.
- GitHub Pages links are not redirected.
Checklist before you transfer
- Choose the recipient. Check their history and agree their security practices. See adding a co-maintainer for the signals worth checking.
- Remove anything you do not want them to hold. Secrets and deploy keys stay associated after transfer, so rotate or delete ones for services you keep.
- Remove yourself from external trust. After the move, revoke your tokens and check where your personal account is still a publisher.
- Check Pages and DNS. If a private repository uses a custom domain, GitHub warns to remove or update DNS records before transfer to avoid domain takeover.
- Plan the registry handover. Transfer package ownership on npm, PyPI or similar as a separate, explicit step.
After the transfer
- Update local clones with
git remote set-url origin NEW_URL. - Do not create a new repository or fork at the old location. GitHub warns that doing so permanently deletes the redirects.
- Note the name retirement rule: if the repository contains a Marketplace action, or had over 100 clones or 100 Actions uses in the prior week, GitHub permanently retires the owner and name combination, so it cannot be reused.
- Announce the change in the README and release notes, so users know who now maintains it.
If you cannot find a trustworthy owner
Consider archiving instead, which makes the project read-only and says it is unmaintained. See archive, transfer or delete.
If you are the one receiving a project, Safeguard can scan its dependencies before you take over, using the free scan at gold.safeguard.sh/scan.
Quick check
Do secrets move with a transferred repository?
Per GitHub, webhooks, services, secrets and deploy keys remain associated after the transfer. Rotate any you do not want the new owner to have.
Do old links still work?
Yes, they redirect, until a new repository is created at the old location.
Sources
Last reviewed: 19 October 2026.
