x-access-token not found: review action fails in GitHub Actions

TL;DR

The step expects a token secret and got nothing - find the secret the step references, make sure it exists and is spelled exactly right (including case), then re-run. x-access-token is just the conventional dummy git username; the real problem is the empty token behind it.

The error

x-access-token not found: review action fails in GitHub Actions

Steps to fix

1. Open the failing step and find which secret it reads for the token value.

• Expected: a secret reference in the step's env or with block.

1. Check the repo's secrets list (and org or environment secrets if the workflow uses those): confirm that secret exists and the name matches exactly, including case.

• Expected: either the secret is missing or its name differs by a character from what the step references.

1. If the token comes from a previous step's output (e.g. a token-minting action), check that step succeeded and that the output name matches what the failing step reads.

• Expected: the producer step is green and the output name lines up.

1. Fix the name or add the missing secret, then re-run the workflow.

• Expected: the step authenticates cleanly.

Use this when

• A GitHub Actions step fails with "x-access-token not found".
• A review bot step clones or pushes via HTTPS with a token secret.
• The workflow was just edited or moved between repos.

Not for this skill when

• The token exists but is expired or revoked (mint a fresh one; the name is fine).
• The failure is a 403 with a valid token (that's scopes or permissions, not a missing secret).
• The step uses SSH rather than HTTPS (different auth path entirely).

Variant phrasings

• github actions x-access-token not found
• review workflow auth failed x-access-token
• x-access-token secret missing github actions
• git clone x-access-token authentication failed CI

Why it happens

Git-over-HTTPS URLs pair the dummy username x-access-token with the real token after a colon, and tools report the username they attempted when auth fails. When the token secret resolves empty - misspelled name, secret never created, or a producer step that failed silently - the error reads like the username is the problem. It never is; the username is constant, the token is what's missing.

Edge cases

• Secrets defined at org level need the repo granted access; a secret can exist and still be invisible to the workflow.
• Environment-scoped secrets require the job to target that environment, or they resolve empty.
• Fork PRs can't read base-repo secrets by design - a review step that needs a secret won't work on the pull_request event for forks.
• A token-minting step that fails leaves downstream steps with empty outputs; always check the producer step first.

Provenance

Resolved from the public thread: https://vectle.com/posts/psttvnRUNsp2Zj7IS7nzLnlw