Can an Enterprise-Installed GitHub App Read Every Organization’s Repositories?
Your GitHub App installed at the enterprise level changes policies across every organization. Does it read their repositories too, and can it replace your PATs yet?
- GitHub announced general availability of enterprise app installations on October 23, with broader administrative API support.
- An enterprise installation grants enterprise permissions; organization and repository access still requires separate organization installations.
- Check API support before replacing PATs. The new coverage is also planned for GHES 3.24.
More governance work can move to an app identity
The October 23 release expands support for enterprise repository policies and rulesets, two-factor requirements, domain verification, IP allowlists and access restrictions.
Those additions let more administrative jobs replace classic personal access tokens with GitHub Apps. A policy can affect the enterprise's organizations without granting the app access to their repository contents.
GitHub Enterprise Server has a separate delivery target: the announcement says these updates will be available in GHES 3.24.
An enterprise installation is not a blanket organization installation
Enterprise owners install enterprise apps; being an app manager is insufficient. Even when an app requests other permission types, the enterprise installation grants only its enterprise permissions.
| Task | Required scope |
|---|---|
| Enterprise administration | An enterprise installation with the relevant enterprise permissions. |
| Organization or repository resources | A separate installation on the relevant organization, with appropriate permissions. |
| Installation-token access across accounts | Separate account-scoped tokens; one installation token cannot cross that boundary. |
The GraphQL guide makes the same distinction. An app installed on one enterprise and two organizations needs tokens for each installation. Central ownership does not merge those scopes.
Map the operation before replacing the credential
GitHub recommends app authentication for enterprise GraphQL operations that support it. Some queries and mutations still require a PAT, so a migration starts with endpoint coverage rather than a global secret replacement.
Also distinguish installation access tokens from user access tokens. Installation tokens are bound to an enterprise or organization account. A user token operates within the permissions and resources available to both the app and the user; it does not bypass missing app access.
A practical migration inventory should therefore connect each API operation to its permissions, installation target and authentication method. Sharing a PAT today does not mean all jobs can share one installation token tomorrow.
Automated installation preserves the account boundary
GitHub's organization rollout example uses two apps. An enterprise-installed app installs an automation app into an organization. The automation app then obtains an organization-scoped token to perform its job, such as creating a repository.
The installer token and the working token have different responsibilities. Two apps are the tutorial's design, not a universal requirement, but the example shows how centralized deployment can retain specific account and permission scopes.
Start with administrative operations newly supported by the release. Keep organization and repository jobs in the migration plan with their own installation requirements.
Frequently asked questions
Can one enterprise installation read every private repository?
No. Install the app on the relevant organizations and grant the repository access it needs.
Can every classic PAT now be removed?
No. Check each operation: not every enterprise API supports app authentication.
Is this the GitHub CLI refreshable-token feature?
No. This release concerns enterprise-installed GitHub Apps and their supported permissions and APIs.