Replace an old GitHub personal access token with a narrow one

A personal access token often starts as a quick way to run Git or an API call, then remains in a laptop or CI setting for years. Classic tokens may have broad scopes. GitHub recommends fine-grained tokens when they support the task, because they can be limited to one resource owner, selected repositories, explicit permissions and an expiration. Some workflows still require classic tokens or a GitHub App; choose based on the actual operation rather than the shortest setup screen.

Before you start​

Inventory where the current token is used without printing it in logs. Know the repository owner, required operation and workflow maintainer. If the token is in a team system, coordinate a small change window so revoking it does not break releases. Never store a fresh token in a repository file.

Do it step by step​

1. In GitHub Settings, Developer settings, Personal access tokens, inspect the old token's type, scope, expiration and last use if shown. Record the purpose and affected system, not the secret value.
2. Create a fine-grained token for the correct resource owner and only the repositories required. Grant the minimum repository permissions the task actually needs. Set a realistic expiration and note whether an organization must approve the token.
3. Put the new token in the destination's protected secret store or credential manager. Test one read and one write operation only if the workflow requires write access. A failed test is a reason to inspect the exact missing permission, not to grant every scope.
4. Update scheduled jobs and developer machines that used the old token. Avoid placing it in command-line arguments captured in shell history or CI logs. Confirm that the changed workflow completes with the new credential.
5. Revoke the old token, then verify it no longer works and remove copies from the old secret store. Review the account's security log for unexpected token use or another token you did not create.
6. Document the token's owner, purpose, repository list, permission set and next rotation date in a location that does not contain the token itself. If a long-lived shared automation is involved, consider a GitHub App instead of one employee's personal token.

Check the result​

The job works with the new restricted credential, the old token is revoked, and a reviewer can identify why each granted permission exists without seeing the secret.

If something goes wrong​

If a fine-grained token cannot perform the operation, check GitHub's current limitations and organization policy. Use a classic token only for a documented gap, restrict it as far as possible and schedule replacement. If revocation breaks an unknown job, restore it using a new scoped credential after identifying its owner.

Know the limit​

A narrow token reduces blast radius; it does not make unsafe storage acceptable. Revoking one token does not revoke OAuth apps, SSH keys or other tokens. GitHub may automatically expire or revoke tokens, so monitoring must treat authentication failure as a maintenance event, not a reason to disable security checks. GitHub personal access tokens Token expiration and revocation