Your GitHub repo-creation bot no longer needs deletion powers
Your provisioning bot holds full repository admin just to create repos. Which permission replaces it, and what breaks if you swap them in the wrong order?
- Request
repository_creation:writefor a bot whose job is creating repositories. - Template access and code pushes require their own content permissions.
- New permissions need approval; removing an existing permission takes effect immediately.
Repository creation has its own grant
A provisioning bot no longer needs broad repository administration solely to create a repo. GitHub's October 13 update introduced repository_creation:write for GitHub Apps and fine-grained personal access tokens. The app receives access to repositories it creates, while installation in an organization still requires administrator approval.
The organization repository endpoint accepts either Administration write or Repository creation write for fine-grained tokens. Creation does not require both. Existing apps do not automatically lose their broader grants.
Creating the repo is only one step
Inspect the rest of your provisioning flow before narrowing its permissions. The template creation endpoint, for example, accepts Repository creation write together with Contents read.
| Task | Permission planning |
|---|---|
| Create an empty organization repo | Repository creation write |
| Create from a template | Repository creation write plus Contents read |
| Push code over HTTP Git | Contents write and access to the target repository |
| Modify Actions workflow files | Account for the Workflows permission as well |
GitHub's Git access guidance distinguishes Contents from the Workflows permission used for files in .github/workflows. Access to a newly created repository does not, by itself, grant every operation within it.
User access tokens also remain constrained by the user's own permissions. Granting an app more access does not let it act beyond the authorizing user's access.
Approval and removal have different timing
Start by inventorying the API calls and Git operations the bot performs. A tool that creates a repository and then changes administrative settings may still need administration for the second step.
App permissions are edited under Settings → Developer settings → GitHub Apps → Edit → Permissions & events. The registration documentation says newly requested repository or organization permissions need approval from each account where the app is installed. Removed permissions take effect immediately.
That makes sequencing useful: request the creation grant, confirm approvals, validate creation and follow-up tasks in a controlled environment, then remove administration if no remaining operation needs it. Deleting the old grant before the replacement is approved can interrupt the automation.
Narrow the bot to its actual job
This is a direct improvement for provisioning tools that only needed administration to create repositories. It does not eliminate the permissions required by a tool deliberately built to delete, transfer or administer them. GitHub's permission guidance explicitly frames the replacement around that creation-only need.
The useful end state is concrete: the bot can create the repository and its required initial content, while the bot no longer holds permissions for administrative tasks outside its role.