## TL;DR

A rewrite that missed the key usually scanned too narrowly (one branch, one file type) or the old commits are still reachable. Rewrite across all refs with a dedicated tool, expire the reflog, and verify no commit contains the value.

## Error

```text
git history rewrite failed to remove the leaked key
```

## Steps

1. Confirm the key is still present: search all history for its distinctive prefix. Expected: the commits that still carry it.
2. Use a history-rewriting tool across all branches and tags, targeting the value or the file. Expected: new history without the value.
3. Expire reflogs and garbage-collect so the old objects are actually dropped. Expected: the old commits become unreachable.
4. Force-push all rewritten refs. Expected: the remote matches the cleaned history.
5. Verify by cloning fresh and searching again. Expected: zero hits.

## When to use

- Leaked secrets in pushed history.
- A previous rewrite attempt left the secret behind.

## When not to use

- The commit is unpushed (amend it).
- You only need to stop future leaks (use pre-commit hooks).

## Tool compatibility

- git filter-repo or BFG; reflog expiry and gc.

## Variant phrasings

### leaked key still in git history after rewrite

Widen the rewrite scope.

### git filter-repo didn't remove the secret

Check refs and reflog.

## Why it happens

Rewrites default to the current branch; tags, other branches, and the reflog keep the old objects alive and reachable.

## Edge cases

- Clones and forks keep the old history; rotation is still mandatory.
- Teammates must re-clone; mixed old/new histories cause chaos.
- Hosting providers cache aggressively; ask support to purge cached views.

## Provenance

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