How to export, review, and apply GitHub repo-team access changes in repod

This is the core repod workflow for cleaning up GitHub repo-team access without hand-editing everything in the GitHub UI.

Use it when you need to review current access, edit target permissions in bulk, and apply changes with a visible diff instead of a series of ad hoc clicks.

TL;DR

Problem: GitHub repo-team access cleanup gets slow and risky when you have to inspect and edit permissions one repo at a time.
Who this is for: GitHub org admins, maintainers, and operators handling access cleanup or delegated access operations.
What this helps you fix: bulk review, repo-team access cleanup, and safer apply workflows with a before/after diff.

1. Prerequisites

Your GitHub org is connected to repod.
Your PAT has the right scopes for the workflow you want to run.
You have the repod role needed to run assignment workflows for the account.

If PAT setup is not complete yet, start with GitHub fine-grained PAT guidance for repod.

2. Export the current state

Go to the access planning workflow and export the current repo-team access state. This gives you a spreadsheet view of how repositories and teams are currently mapped.

The export is useful for two reasons:

It gives you a review surface that is easier to scan than clicking through individual repos.
It gives you a controlled way to edit target access before anything is applied back to GitHub.

3. Review and edit target permissions

In the spreadsheet, review the current assignments and set the target state you actually want. This is the right time to:

remove stale team access
standardize permission levels
move repositories under the right teams
prepare access cleanup before an audit or org restructure

Keep this workflow focused on repo-team access. If your structure itself is wrong, fix the team model as well rather than encoding long-term exceptions into the spreadsheet.

4. Import the workbook

Import the edited workbook back into repod. The import step is not the apply step. It is the point where repod validates the edited target state and prepares the change set for review.

5. Review the diff before apply

Review the diff carefully. The point of the workflow is that access cleanup should be reviewable and auditable before it changes GitHub.

Check which team-repo links will be added.
Check which team-repo links will be removed.
Check which permission levels will change.
Pause if the change set includes more access than expected or removes something safety-critical.

6. Apply changes

Once the diff looks right, apply the changes. repod will enact the reviewed repo-team permission changes against GitHub using the stored PAT.

This is the point where repod is operationally different from “just use the GitHub UI”: you have one review surface, one diff, and one apply path for a whole change set.

7. Use cases where this workflow is strongest

cleaning up stale team access after org changes
standardizing permissions ahead of an audit
moving repositories under clearer team ownership
delegating day-to-day repo-team access work without broad GitHub org admin