GitHub Direct access vs Organization access

Review GitHub's Direct access and Organization access tabs separately. They represent different permission sources, owners, and removal paths.

Short answer

Use organization access for the operating model

Put durable access in a GitHub Team or organization role. Keep Direct access for narrow exceptions such as temporary work or an outside collaborator, with a named owner and a review date.

What GitHub's access tabs mean

In a repository's Collaborators & teams settings, GitHub uses Direct access for people explicitly added to the repository. Organization access shows access received through a team or organization role. Base organization permissions can also give members a minimum level of access across repositories.

Access route	Best use	Main review question
Organization access through a team	Long-lived access tied to ownership, role, onboarding, and offboarding.	Does the team still represent the people who should operate this repo?
Organization role or base permission	Deliberately broad access that should apply across the organization.	Is this level safe for every member it reaches?
Direct access	Temporary, external, or unusually narrow exceptions.	Who owns the exception, why is it still needed, and when is it reviewed?

When GitHub Team access is the better default

Team-based access is easier to explain because membership, repository ownership, onboarding, and offboarding share the same structure. When somebody moves teams, their access can change with membership rather than through repo-by-repo edits.

• Use a team when access should survive personnel changes.
• Attach the repository at the narrowest team layer that matches real ownership.
• Keep parent-team grants safe for every child that inherits them.
• Use repository roles such as Read, Triage, Write, Maintain, and Admin deliberately.

For inheritance and parent-team design, use the GitHub Teams hierarchy and repository permissions guide.

When Direct access is reasonable

A direct grant is not automatically a problem. It becomes a problem when an exception quietly turns into the permanent access model.

• short-lived access during an incident, migration, or handover
• an outside collaborator who cannot join an organization team
• temporary administrative coverage for a sensitive repository
• a genuinely one-person requirement that does not justify a lasting team

Record an owner, reason, and review date. If the same exception recurs, replace it with a clearer team or role.

Five questions for a repository access review

1. Which people appear under Direct access, and why does each grant exist?
2. Which teams or organization roles provide Organization access?
3. Does the effective permission match the person's current role?
4. Would removing a direct grant break legitimate access, or reveal a missing team?
5. Which exceptions need an owner, expiry date, or replacement team?

Broad write access is a separate decision

Moving access into teams does not make every permission appropriate. A team that gives the whole organization Write access can still widen the impact of compromised accounts, workflow changes, packages, or deployment credentials. Review blanket GitHub write access risks separately from the team-versus-direct decision.

Find the access paths that need a decision

repod shows repo-team mappings, direct grants, private repositories without clear team coverage, and high-privilege access in one reviewable report.

Run Free Audit See what the audit checks

Common questions

Sources

• Managing teams and people with access to your repository
• Setting base permissions for an organization
• Repository roles for an organization