A temporary private fork lets you develop a security fix privately, from a draft repository advisory. It has real limits: CI cannot access it, status checks do not run, branch rules are not enforced, and you merge all open pull requests together. Plan to test locally and review by hand before you merge.
What it is
GitHub describes a temporary private fork as a private copy of your public repository, created from a draft security advisory. Its name follows the pattern repo-ghsa-xxxx-xxxx-xxxx. Admins on the advisory can add collaborators, people with write permission can commit and open pull requests, and admins merge.
The limits that matter
From GitHub's documentation:
- Integrations, including CI, cannot access the fork.
- Status checks do not run on pull requests in it.
- Branch protection rules and rulesets for the target branch are not enforced.
- You cannot merge individual pull requests. You merge all open pull requests together from the advisory.
- Merge conflicts block merging.
- Only one pull request can be merged into the main branch of the fork. If more than one targets it, merging is blocked.
Put plainly, the safety net you rely on in public is missing. That is the cost of privacy.
Work around the gaps
Test locally. Run the full test suite and linters on your machine or a trusted runner before you merge. Record what you ran in the advisory discussion.
Hold your own review. Rules are not enforced, so decide who reviews. Ask a second trusted person to read the diff and write "approved" in the advisory thread. This is your two-person rule by hand. See two-person review for a solo maintainer.
One pull request to main. Combine the fix into a single pull request targeting main, or use separate branches for backports, keeping the one-main rule in mind.
Keep conflicts low. Rebase the fork onto the current default branch right before merge, because conflicts block the merge.
Check the build after merge. Once merged, the normal CI will run on the public branch. Watch it, and be ready to publish a quick follow-up if something breaks.
Be careful who joins
Everyone you add can see the vulnerability. Add only people who need to. Remember that a collaborator on the advisory can access the fork. Remove people once the work is done.
After the merge
An admin merges from the advisory page. Then you can publish the advisory to alert users. Follow the advisory checklist so the notice names affected and fixed versions.
When a private fork is the wrong tool
If your fix needs heavy CI, such as multi-platform builds or long integration tests, you may prefer a private repository that runs your pipeline, then port the patch. Weigh that against the extra copy of the code and a manual merge.
Quick check
Does CI run in a temporary private fork?
No. GitHub says integrations including CI cannot access it, and status checks do not run.
Can I merge pull requests one at a time?
No. All open pull requests are merged together from the advisory.
Sources
Last reviewed: 19 October 2026.
