Why a temporary shutdown can leave access behind
When you need to pause an integration quickly, the obvious move is to suspend or uninstall it. That handles the installation side. It does not automatically handle the authorization side, which is a different grant with a different owner.
Suspending an installed GitHub App temporarily blocks access to resources owned by that installation account. Source
That distinction matters because a GitHub App can hold two kinds of access at once: installation access to an account’s resources, and user authorization to act on a person’s behalf. Pausing one does not pause the other.
Suspension does not remove the separate authorization for an app to act on a user’s behalf. Source
Installation access versus user authorization
Use this table to decide which surface you actually need to change.
| What you want to stop | Surface to check | What suspension does | What it does not do |
|---|---|---|---|
| The app reaching resources owned by the installing account | The installation on that account | Temporarily blocks that installation’s access | Remove the user authorization |
| The app acting on a person’s behalf | Authorized GitHub Apps for that user | Nothing by itself | Stop the user-level authorization |
| Both, for one account | Both surfaces | Covers only the installation side | Leaves the other grant in place |
A GitHub App is not an active browser session you can simply log out of. Suspending an installation is an account-level control over resources; de-authorization is a user-level control over delegated action. They are managed separately and should be verified separately.
A practical checklist for a temporary shutdown
- Name the goal first. Decide whether you are pausing the app’s reach into an account’s resources, stopping it from acting on a user’s behalf, or both. The answer determines which surface you touch.
- Handle the installation. Suspend the installation on the account that owns the resources you want protected. Treat this as temporary and reversible.
- Check the user side separately. If the app was authorized to act on your behalf and you want that to stop, go to Authorized GitHub Apps and de-authorize it there. Do not assume the suspension covered this.
- Record what you changed and where. Note which account’s installation you suspended and which user authorization, if any, you removed. This prevents a later cleanup from missing one of the two.
- Reverse deliberately. If the pause was temporary, re-enable the installation only after you have confirmed whether the user authorization should also be restored.
Uninstalling is stronger than suspending, but still scoped
If a temporary pause is not enough and you want the installation gone, uninstalling is the stronger installation-side action. It still does not reach the user authorization by itself.
Uninstalling removes that account’s installation access; de-authorization in Authorized GitHub Apps is a separate action when the owner wants to stop it acting on their behalf. Source
The practical consequence: after uninstalling, check Authorized GitHub Apps if the owner also wants the app to stop acting on their behalf. Removing one connection is not proof that the other is gone, and an app that no longer appears in one place may still hold the other grant.
Common failure paths
- Assuming suspension is a full revoke. It blocks the installation’s resource access only. The user authorization survives until you address it.
- Treating de-authorization as uninstallation. De-authorizing stops the app acting on your behalf, but the installation on an account can remain. Decide which one your shutdown actually requires.
- Cleaning up one account and forgetting the other. Installations belong to accounts; authorizations belong to users. A shutdown plan that names only one surface will usually leave the other untouched.
- Re-enabling too early. If you suspended rather than uninstalled, restoring the installation can restore resource access before you have reviewed the user side.
Verifying both surfaces before you call it done
A shutdown is complete only when each surface you intended to change has been checked on its own terms. Confirm the installation state on the owning account, then confirm the authorization state under Authorized GitHub Apps for the relevant user. Do not infer one from the other, and do not describe the app as logged out — it was never a browser session.
If your next task is removing an older OAuth grant and you want to keep that separate from login sessions, the related guide on revoking an old GitHub OAuth app without confusing it with a login session covers that different cleanup step.