GitHub has added two narrowly scoped permissions for apps and fine‑grained personal access tokens: repository_creation:write and installation_repositories:write. These replace the older, catch‑all repository_administration:write and enable a true least‑privilege model for repository lifecycle and app installation management. The changes also bring an offline_access scope to GitHub Apps and expand visibility APIs for private and internal apps.
New repository creation and installation management permissions
The repository_creation:write scope authorises a caller to create a repository within the granted account, but nothing else—no delete, transfer, or other admin actions. When a repository is created, the creator automatically receives access to it, preserving the expected ownership model. The installation_repositories:write scope lets a caller add or remove a repository from any installation in the organization, provided the caller is an organization owner or a repository admin if the caller is a user.
Practical impact:
- Automation scripts can spin up new repos without requesting full admin rights.
- Teams can build tooling that re‑assigns repos to specific apps without relying on a broad‑scope PAT.
- Security reviews can now focus on a single permission rather than a large, over‑privileged set.
Repository administrator workflow improvements
Historically, any app that required organization‑level access was blocked from being installed on a repository by a repository admin, even if the app was already approved at the org level. GitHub now relaxes that rule: if an app is installed organization‑wide, a repository admin can add the repo to the existing installation without additional owner approval. The only remaining approvals are for the three sensitive permission sets—organization‑level permissions, repository administration, and repository creation.
Implications for operations:
- Repo owners can adopt approved apps more quickly, reducing bottlenecks.
- Admins retain the ability to block app installation entirely via the “Restricting GitHub App Installation to Organization Owners” setting.
- Audit logs will still capture the addition of a repo to an installation, preserving traceability.
Offline access and rotating tokens for GitHub Apps
GitHub Apps now support the offline_access scope, mirroring OAuth app behaviour. When requested, the app receives a refresh token alongside the short‑lived access token. This enables developers to re‑enable token expiration gradually: they can test token rotation on a subset of users before enforcing it globally.
Key considerations:
- Existing workflows that disabled token expiry can be re‑enabled without a full client migration.
- The scope parameter remains unused for permission selection; static app permissions still apply.
- Refresh token handling must be added to the app’s authentication flow.
Visibility‑aware app metadata APIs
The “Get an app” endpoint now returns details for private and internal apps when the caller shares ownership. Access rules are:
- Any public app can be queried by any other app.
- Apps in the same organization can query each other regardless of visibility.
- Internal apps within the same enterprise can query each other across org boundaries.
- An enterprise‑owned app can query apps owned by its member organizations.
This expanded visibility supports automated auditing and cross‑app coordination without exposing data to unrelated apps.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Adopt the new fine‑grained scopes wherever possible: replace repository_administration:write with repository_creation:write for repo‑creation bots, and use installation_repositories:write for automation that re‑assigns repos to apps. Review existing PATs and App configurations to eliminate unnecessary broad permissions. If you rely on long‑lived tokens, start requesting offline_access and implement refresh‑token handling to transition to rotating tokens safely. Finally, update any internal audit scripts to use the expanded “Get an app” API, ensuring they respect the new ownership‑based visibility rules.
