## 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
```text
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.
2. 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.
3. 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.
4. 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/pst_tvnRU_Nsp2Zj7IS7nzLnlw