GitHub Apps Can Now Create Repos Without Admin Rights

Most repo-scaffolding bots run on a classic personal access token for one reason: creating a repository and wiring it into an app installation needed permissions that GitHub Apps either couldn't hold narrowly or couldn't hold at all. That reason is mostly gone.

GitHub's 13 October changelog bundles five changes under least privilege and app management. Two of them matter for anyone running internal platform automation, and the rest are worth a line in your migration plan.

repository_creation:write: create without the power to delete

Until now, an app that created repositories needed repository_administration:write. That permission also covers deleting and transferring repositories, which is a lot of blast radius for a bot whose job is stamping out templates.

The new repository_creation:write permission, per the changelog, "allows the caller to create a repository in the account where it's granted." GitHub frames it as supporting a least-privilege approach by granting only the ability to create repositories. It works with the existing create-an-organization-repository endpoint. The changelog adds that the creator gets access to the new repository, and an organisation administrator must still install the app.

The practical upshot: a leaked scaffolding-bot credential can now create junk repositories, which is annoying, instead of deleting or transferring real ones, which is an incident.

installation_repositories:write: manage installs without a classic PAT

The second permission covers a quieter pain point. The installation endpoints that add a repository to an app installation or remove it previously supported only the coarse-grained repo scope, meaning a classic PAT. They now accept GitHub Apps and fine-grained PATs holding installation_repositories:write.

There is a guard rail: when the caller is a user, they must also be an organisation owner or an administrator on the repository. So a fine-grained PAT doesn't let a regular member attach repositories to apps they couldn't otherwise manage.

Repo admins can now add approved apps themselves

The third change is about people, not tokens. Repository administrators can now add their repositories to an app that is already installed at the organisation level without waiting for an owner. GitHub notes this doesn't increase the app's access, since the app was already approved for the organisation.

Three permission sets still require owner approval: organisation-level permissions, repository administration, and repository creation. If you want the old behaviour, owners can switch on restricting GitHub App installation to organisation owners. Decide deliberately; the default now favours speed for repo admins.

Refresh tokens and app discovery

GitHub Apps now accept the offline_access scope, as OAuth apps do. Request it and the app receives a refresh token alongside an expiring user access token, which lets developers turn on token expiration gradually. The changelog notes the scope parameter is otherwise still unused for GitHub Apps, and lists this as coming to GitHub Enterprise Server 3.23.

The Get an app API can now return details about private and internal apps when the caller shares ownership: apps in the same organisation can read each other's details regardless of visibility, internal apps can do so across organisations in the same enterprise, and enterprise-owned apps can read apps owned by their organisations. Useful for inventory tooling that previously saw only public apps.

Finally, app credentials move to a dedicated Credentials tab with client secrets and key pairs, which GitHub says sets up space for upcoming workload federation credentials (roadmap issue). That lands in GHES 3.24.

Worked example: a template bot

Take a common internal tool: a bot that creates a service repository from a template, then attaches it to the organisation's CI app so builds start immediately. On a classic PAT it holds the repo scope, which reaches every repository the token's owner can reach, plus whatever else that person can do. On an app with repository_administration:write, it can delete any repository in its installation.

After this change the same bot can run as a GitHub App holding repository_creation:write to create the repository and installation_repositories:write to add it to the CI app's installation. Neither permission lets it delete, transfer or change settings on existing repositories.

Two things to verify in a staging organisation before you switch. First, confirm the owner-approval rule: an app requesting repository creation is one of the three permission sets that still needs an organisation owner to approve it, so plan for that sign-off. Second, check your audit tooling. Events from an app look different from events attributed to the human behind a classic PAT, which is usually an improvement for incident response but can break dashboards keyed on a username.

Keep the classic PAT around, disabled rather than deleted, for one release cycle so you can roll back quickly if an endpoint you forgot about still needs the repo scope.

A migration checklist for classic-PAT automation

If you run internal tooling that still uses a classic PAT, this is a good week to audit it:

• List what each token actually does. Scaffolding bots typically create repos, push an initial commit, set branch protection, and attach the repo to a CI or deploy app. Only the first and last steps were blocking a move to an app; both now have narrow permissions.
• Swap administration for creation wherever the bot never deletes or transfers. If it does need branch protection or settings changes, keep administration but scope the installation to the repositories it manages.
• Move installation management onto installation_repositories:write and drop the repo scope.
• Request offline_access if the app acts on behalf of users and you've been avoiding token expiration.
• Decide on repo-admin installs and set the owner-only restriction if your org needs a single approval point.

When you debug the switch, decode the app's JWT with our JWT decoder to confirm its issuer and expiry claims, and turn the API examples into code with cURL to fetch. Tokens also changed shape recently; if you validate them with regexes, read our note on GitHub App tokens growing to 520 characters and test patterns in the regex tester.

The broader direction is consistent with what package registries are doing, such as npm trusted publishing without long-lived tokens: narrow, short-lived, auditable credentials instead of one token that can do everything.

FAQ

What does the repository_creation permission allow?

It allows the caller to create a repository in the account where it's granted, without the broader repository_administration:write permission that also covers deleting and transferring repositories.

Can fine-grained PATs use the new permissions?

Yes. Both repository_creation:write and installation_repositories:write are available to fine-grained personal access tokens and to GitHub Apps.

Do I still need a classic PAT to add a repository to an app installation?

No. The add and remove installation repository APIs now support GitHub Apps and fine-grained PATs with installation_repositories:write. User callers must also be an organisation owner or a repository administrator.

Can repository admins install GitHub Apps now?

They can add their repositories to an app already installed at the organisation level without owner approval. Apps needing organisation permissions, repository administration or repository creation still need owner approval, and owners can restrict installs to themselves.

Do GitHub Apps support refresh tokens?

Yes. GitHub Apps now accept the offline_access scope, which returns a refresh token alongside the expiring user access token. GitHub lists this for GitHub Enterprise Server 3.23.

If a bot only needs to create, stop letting it delete; that's the whole upgrade.