Control private GitHub repository visibility by team
A private repository is hidden from the public, but it can still be visible to organization members through base permissions, teams, organization roles, or direct grants.
Private does not mean team-only
Repository visibility determines whether a repo is public, private, or internal. Permissions determine which people can actually access it. For a private organization repository, review every organization, team, role, and direct path before claiming that only one team can see it.
- Base permission None No default member access
- Owning team Security: Write Durable operating access
-
Direct grant
alice-dev: Read Individual exception -
Outside collaborator
vendor-reviewer: Read External exception
Are GitHub repositories private by default?
Not universally. A repository's creator selects an allowed visibility when the repository is created, subject to organization and enterprise policy. A private repository is available only to authorized people, but organization owners retain access and other members may receive access through base permissions, teams, organization roles, or direct grants.
Keep sensitive repositories behind the right team boundary
If one compromised developer account could expose more internal code than you are comfortable with, the live access model is broader than the repository's private label suggests.
repod helps when GitHub can express the right model, but base organization access, parent-team inheritance, and direct grants have drifted too wide to review safely by hand.
What usually widens private repository access
| Access path | What happens | What to review |
|---|---|---|
| Base organization permission | A minimum role can apply to every organization member. | Is broad member access intentional for sensitive private repos? |
| Parent-team inheritance | A repository attached high in the hierarchy reaches child teams below it. | Should the grant sit on a narrower ownership team? |
| Direct access | A person or outside collaborator receives an exception outside the normal team model. | Who owns the exception, and when should it be reviewed? |
| Organization or repository role | A role supplies access independently of the expected owning team. | Does the effective permission match the person's current responsibility? |
A safer operating model
- Keep base organization repository access minimal where practical.
- Grant durable repository access through teams rather than individual grants.
- Attach sensitive repos at the narrowest legitimate team layer.
- Treat direct and temporary access as explicit exceptions with an owner and review point.
- Review the full change set before removing a broad path or adding a narrower replacement.
Use GitHub Teams hierarchy and repository permissions for inherited access, GitHub Direct access vs Organization access for individual exceptions, and review blanket GitHub write access risks separately from visibility.