GitHub has made several GitHub App changes that are useful if your integration still depends on a broad personal access token or an oversized app permission. The biggest improvement is simple: repository creation and installation management now have narrower permission paths.
The same update also makes it easier for repository administrators to use an app that their organization has already approved, adds offline_access for a gradual move to expiring user tokens, and moves GitHub App credentials into a dedicated tab. These are separate changes, but they point in the same direction: smaller permissions and easier administration.
Create repositories without repository administration
The new repository_creation:write permission lets a GitHub App or fine-grained personal access token create a repository in the account where the permission is granted. Before this, repository creation required the broader repository_administration:write permission.
That distinction matters because repository administration includes operations such as deletion and transfer. An app that only provisions repositories should not need the ability to perform all of those actions. With the narrower permission, the app or user that creates the repository is given access to it, but an app still requires an organization administrator to install it.
Review every repository creation path in your integration. The REST endpoints for creating an organization repository, creating from a template, creating for the current user, and creating with a fork can now use this narrower permission. The GraphQL repository creation mutation is included as well. Keep the permission request aligned with the path your app actually uses.
Manage which repositories an app can reach
GitHub also added installation_repositories:write. It lets an authorized GitHub App or fine-grained personal access token add or remove repositories from an installation in an organization. These APIs previously required the coarse-grained repo scope.
This is useful for an internal access broker. Instead of asking an administrator to use a broad token every time a repository joins or leaves an app installation, the broker can operate with one narrowly defined permission. If the caller is a user, GitHub still requires that user to be an organization owner or an administrator on the repository in question.
Treat add and remove as security-sensitive operations. Log the app installation, repository, actor, reason, and resulting scope at your audit boundary. Do not log access tokens, private keys, or full authorization headers. A permission that is narrow in GitHub can still be dangerous if the service exposes it without an approval step.
Approved apps are easier for repository admins to use
Repository administrators can now add repositories to an app that is already installed and approved at the organization level, without asking the organization owner to approve the same app again. The app already has the organization-level access, so adding another repository does not grant the repository administrator new organization privileges.
The boundary is worth documenting. Organization-level permissions, repository administration, and repository creation still require organization owner approval. If your organization does not want repository administrators to add approved apps to repositories, GitHub provides a setting to restrict installation to organization owners. Make this policy explicit instead of relying on a one-off approval memory.
Use offline_access to migrate token expiration gradually
GitHub Apps now support the offline_access scope for user access tokens. GitHub App user tokens are short-lived and rotating by default, but some older integrations disabled expiration because changing every existing client at once felt risky. With offline_access, the app receives a refresh token alongside the expiring access token for that authentication.
A safe migration is additive. Enable the new flow for a small test group, store the refresh token with the same care as any other long-lived credential, and verify refresh, revocation, rotation, and failure handling before expanding it. Keep the old session path available until the new flow has been observed in production-shaped conditions.
Do not treat the scope parameter as a general permission selector for GitHub Apps. GitHub says permissions are still selected statically in the app registration. The new scope only changes the token flow. The feature is available in GitHub Enterprise Server 3.23, while the other improvements are planned for GHES 3.24.
A better place for app credentials
GitHub App credentials now have a dedicated Credentials tab instead of appearing inline with the rest of the app configuration. That is a small UI change, but it makes a useful operational boundary: client secrets and key pairs are credentials with rotation and ownership rules, not just another application setting.
Use the move as a prompt to inventory keys, owners, last rotation, deployment location, and emergency replacement steps. Store private keys outside the repository, keep them out of logs and issue text, and remove old keys after the replacement has been verified. GitHub says the new tab also prepares for planned workload federation credentials.
Migration checklist
Inventory apps and PATs that create repositories. Replace repository administration with repository creation where the workflow only provisions repositories.
Inventory automation that adds or removes repositories from app installations. Test installation_repositories:write with the smallest actor and repository scope that can do the job.
Decide whether repository administrators may use already-approved apps. Record the organization policy and the owner approval boundary.
Pilot offline_access with refresh-token storage, expiry, revocation, rotation, and failure tests before changing every user session.
Move credential ownership into a runbook. Every key should have an owner, a rotation date, a replacement path, and a way to confirm the old credential is no longer used.
The useful rule
GitHub's official changelog covers the permission, installation, token, app visibility, and credential changes. The repository creation API docs and user token refresh docs are the right references when you change an integration.
Ask every GitHub App permission to justify itself. If an app creates repositories, give it repository creation rather than repository administration. If it manages installation scope, give it installation management rather than a broad repo token. If it needs user access over time, use refresh tokens and test expiry instead of disabling it forever. Smaller permissions make approval easier and reduce the damage when an integration is misconfigured.