On 13 October 2026 GitHub shipped a set of GitHub App changes aimed at one goal: removing the last reasons teams keep classic personal access tokens (PATs) around. Two new fine-grained permissions let automation create repositories and manage App installations without broad admin scopes. GitHub Apps also gain the offline_access scope, so developers can phase in expiring user tokens instead of switching every user at once.
There is a trade-off in the same release. Repository administrators can now add their repos to an already-approved App installation without an organization owner signing off.
What's affected
Any organization that uses GitHub Apps or fine-grained PATs, and especially those still running automation on classic PATs with the repo or admin:org scope.
New fine-grained permissions (for GitHub Apps and fine-grained PATs):
repository_creation:writelets the caller create a repository in the account where it's granted. Before this, creating a repo neededrepository_administration:write, which also covers deletion and transfer. The creator gets access to the new repo. An org admin must still install the App.installation_repositories:writelets the caller add or remove repositories from an organization installation. The user must also be an org owner or a repo admin.- The Add and Remove repository-from-installation APIs now accept GitHub Apps and fine-grained PATs. Previously they required the classic
reposcope.
Repo admins can add approved apps. A repository admin can now add their repo to an existing installation of an App that already has organization-level access, without owner approval. GitHub says this doesn't expand the App's access. Three permission sets still need owner approval: organization-level permissions, repository administration and repository creation. Owners can block the new behavior by restricting App installation to organization owners.
offline_access for GitHub Apps. When requested, the App receives a refresh token alongside an expiring user access token, as OAuth apps do. It affects only that authentication, so you can move users to expiring tokens gradually. Available in GHES 3.23.
Other changes: the Get an app API can now return details of private and internal apps within the same org or enterprise, and App credentials move to a dedicated Credentials tab with Client secrets and Key pairs sub-tabs, which GitHub says prepares for upcoming workload federation credentials. These arrive in GHES 3.24.
How to check if you're exposed
The real question is how much broad-scope automation you still have. Under Organization settings, Personal access tokens, owners can review fine-grained tokens with access to the org and set a policy on classic PAT access. For an API view of approved fine-grained tokens, GitHub's docs say only GitHub Apps can call the endpoint, so run this with an installation token from an internal App:
curl -s -H "Authorization: Bearer $APP_INSTALLATION_TOKEN" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/orgs/YOUR_ORG/personal-access-tokens \
| jq -r '.[] | [.owner.login, .token_name, .token_expires_at, .token_last_used_at] | @tsv'
Then find automation that creates repos or manages installations. These are the jobs that needed admin scope until now:
grep -rnE "POST /orgs/.*/repos|/user/installations/.*/repositories|repos create" \
.github/ scripts/ terraform/ 2>/dev/null
Check your App installation policy. Under Organization settings, GitHub Apps, see whether installation is restricted to owners. If it isn't, repo admins can now attach repos to approved Apps on their own.
Finally, list installed Apps and the permissions each holds:
gh api /orgs/YOUR_ORG/installations --jq '.installations[] | [.app_slug, (.permissions|tostring)] | @tsv'
What to do now
- Move repo-creation automation to
repository_creation:write. Any App or token holdingrepository_administration:writeonly to create repos is over-privileged. That permission also covers delete and transfer. - Move installation management to
installation_repositories:writeand retire the classicrepotokens that were doing it. - Decide on the repo admin change. If App sprawl worries you more than owner workload, restrict App installation to organization owners.
- Pilot
offline_accesson one internal App that uses user tokens, so you can test expiring tokens with a subset of users before enabling expiry for everyone. - Set a classic PAT retirement date. With these gaps closed, fewer workflows have a legitimate reason to need one.
Why it matters
Classic PATs are the long-lived, broad-scope credentials that show up again and again in supply chain incidents. They often belong to a single person, outlive that person's role, and grant access to every repo the person can see. Teams kept them for tasks that fine-grained tokens and Apps couldn't do with narrow permissions. Creating repositories and managing installations were two of those tasks.
The repo admin change cuts the other way. It reduces friction, and GitHub notes it doesn't expand the App's org-level access. But it moves a decision from org owners to repo admins, and that's worth a deliberate choice rather than a default.
Try it yourself
Pick one automation job that uses a classic PAT. Write down what it actually does, then map each action to the narrowest fine-grained permission. If every action now has one, replace the PAT this sprint. The demo below shows how a pull request gate can block changes that add broad-scope tokens back into workflows.
Click through it at your own pace, or open it full screen.
Quick check
Does repository_creation:write allow deleting repositories?
No. That's the point. Deletion and transfer sit under repository_administration:write, which creation no longer requires.
Can a repo admin now give an App more access than the org approved?
GitHub says adding repositories doesn't expand the App's access. Organization-level permissions, repository administration and repository creation still need owner approval.
What does offline_access change for GitHub Apps?
When requested, the App gets a refresh token alongside an expiring user access token. It lets you move users to expiring tokens gradually. Permissions are still set on the App registration.
