An agent stores a GitHub App installation token in its working memory at the start of a long-running workflow. GitHub App installation tokens expire after 1 hour. The workflow is expected to run for 2 hours. At the 70-minute mark, the agent attempts a GitHub API call and receives a 401 Unauthorized response. What is the CORRECT recovery pattern for this scenario?

The correct recovery pattern is to detect the unauthorized response as a token expiration signal, request a new installation token using the GitHub App credentials, update the token in working memory, and retry the failed API call. GitHub App installation tokens are intentionally short-lived, expiring after one hour, as a security feature because they limit the blast radius if a token is compromised. For agents running workflows longer than one hour, the correct design is to treat token expiration as an expected operational event, not a failure. The recovery pattern is: first, detect the unauthorized status code and check whether it indicates token expiration, since GitHub returns a specific error body; second, use the GitHub App's private key to generate a new JWT and exchange it for a fresh installation token; third, update the token value in working memory; and fourth, retry the API call that originally failed. The workflow continues without user involvement.

Treating the unauthorized response as a fatal error, terminating the workflow, and prompting the user to restart the job with fresh credentials is wrong because terminating after seventy minutes wastes the completed work and provides a poor user experience for a predictable, recoverable condition. Token expiration in a two-hour workflow is not an unexpected failure; it was foreseeable at design time and should be handled automatically.

Switching from the expired installation token to a personal access token stored in a secret for the remainder of the workflow is wrong because it is a security downgrade. GitHub App installation tokens are scoped to the specific repositories and permissions of the installation, providing fine-grained least-privilege access. A personal access token typically carries broader permissions tied to a user account, violating least-privilege principles. Additionally, using a secret-stored personal access token as a fallback conflates two separate authentication mechanisms and complicates the security model.

Implementing exponential backoff and retrying the API call up to three times before surfacing the error to the user is wrong because exponential backoff is the correct pattern for transient failures such as network blips, rate limits, and temporary server errors, not for authentication failures. Retrying an unauthorized response without refreshing the token will always return another unauthorized response because the token does not become valid again with time. Backoff retries on an authentication error waste time and API quota.