Where you start a re-run decides which person CircleCI checks, and those two people are often not the same. A re-run from GitHub keeps the person who started the workflow. A re-run from the CircleCI workflow page runs as the person who clicked Rerun. The job records that person's GitHub login as CIRCLE_USERNAME, and a restricted context is allowed only for them. If you clicked Re-run in GitHub and you are allowed to use the context, the job can still say Unauthorized, because CircleCI checked the other person.
The pipeline page still shows whoever triggered the pipeline. The job and the context check follow the person the re-run runs as. That person changes when the re-run starts in CircleCI.
GitHub tells CircleCI which check to run again. CircleCI uses the person stored on that check, which is the person who started the workflow that created it. Re-run failed jobs and Re-run all jobs on the GitHub checks page both work this way.
Run as yourself
Open the workflow in CircleCI and use Rerun there (from the start, or from the failed job).
On the new job, confirm
CIRCLE_USERNAMEis your GitHub login.If that job is still Unauthorized, the login in
CIRCLE_USERNAMEis not in the context security group. An organization admin adds the group under Organization Settings → Contexts → the context → Security. The steps are in Restricting a context.
Refreshing GitHub App authorization, or refreshing permissions on the user settings page, does not change which person a GitHub re-run uses. Those steps matter when the login in CIRCLE_USERNAME should already have access and CircleCI has a stale copy of their teams.
The general checklist for other Unauthorized causes is Troubleshooting Builds "Unauthorized" due to contexts.