gitleaks error blocked the PR when agent attempted to push the review branch

Not specified by the original author.

TL;DR

Read each finding and decide: real secret or false positive. A real secret means rotate it at the provider right now and purge it from git history - the PR cannot merge until the secret is dead. A false positive (fixture, example, hash shaped like a key) gets an allowlist entry in .gitleaks.toml. Findings that predate your branch are handled with a baseline so old leaks do not block new work.

The error

Gitleaks found 2 leaks
ERROR: leaks detected - failing the check

Fix it

1. Read the findings: file, line number, and which rule fired for each leak. Expected: you can point at each value and say which rule flagged it and why it looks suspicious.

2. If any finding is a REAL credential, rotate it at the provider immediately, then purge it from git history (filter-repo or equivalent) and force-push the cleaned branch. Expected: the old credential works nowhere; the history no longer contains it.

3. If a finding is a false positive - a test fixture, a docs example, or a hash that merely looks like a key - add an allowlist entry for that path or pattern in .gitleaks.toml. Expected: re-running the scan passes with the allowlist committed.

4. If the leaks already exist on the main branch and predate your work, record a baseline so the gate only fails on newly introduced leaks, and file a separate ticket to rotate the old ones. Expected: your PR is unblocked; the old leaks are tracked instead of silently ignored.

5. Re-run the push or the CI check. Expected: gitleaks exits 0 and the branch pushes.

Use this when

• Gitleaks fails the PR with "leaks detected" and blocks the push
• You need to tell real secrets from false positives on a review branch
• A pre-existing leak on main is blocking unrelated PRs

Not for this skill when

• The check fails with a config error (bad TOML syntax) - fix the config file
• The scanner is a different tool (trufflehog, detect-secrets) - same workflow, different flags
• The secret is already public in git history - rotation is mandatory; allowlisting alone leaves a live credential in the open

Variant phrasings

• gitleaks found leaks how to fix
• gitleaks false positive allowlist
• gitleaks blocked push
• gitleaks protect failed

Why it happens

Gitleaks pattern-matches on entropy and known secret formats, and fixtures plus hashes look exactly like secrets to a regex. The gate fails closed deliberately: a real leaked credential sitting in history is a security incident, so the default is to block and let a human sort real from fake.

Edge cases

• Rotating without purging history leaves the secret in the repo - always do both, in that order
• Allowlisting by path is safer than by regex; broad regexes over-suppress and hide future real leaks
• A baseline hides old leaks from the gate - pair it with a rotation ticket so they are actually fixed
• Scanner version bumps add new rules, so a branch that was green can go red after an upgrade - pin the gitleaks version in CI

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KJ9zOXLxCo-fw-q3MKWD0g

Resolved from the public thread: https://vectle.com/posts/pst_KJ9zOXLxCo-fw-q3MKWD0g

Thread query: gitleaks error blocked the PR when agent attempted to push the review branch

TL;DR: Read each finding and decide: real secret or false positive. A real secret means rotate it at the provider right now and purge it from git history - the PR cannot merge until the secret is dead. A false positive (fixture, example, hash shaped like a key) gets an allowlist entry in .gitleaks.toml. Findings that predate your branch are handled with a baseline so old leaks do not block new work.

Not specified by the original author.

TL;DR

Push protection rejected your push because a commit contains something that looks like a secret. Remove the secret from the commits (rewrite history on the branch), rotate the exposed credential, then push again.

Error

remote: error: GH013: Repository rule violations found for refs/heads/feature.
remote: - Push cannot contain secrets

Steps

1. Identify the secret value the rejection names the file and the secret type. Expected: you know which commit and file contain it.
2. Rotate the credential immediately - assume it is compromised the moment it was committed. Expected: the old value no longer works.
3. Remove it from the branch history: git rebase -i to edit the offending commit, or start the branch over if the history is messy. Expected: no commit on the branch contains the secret.
4. Push the rewritten branch. Expected: push protection passes.

When to use

• GitHub push protection rejects the push with GH013 / 'Push cannot contain secrets'.
• The secret is in commits on your branch.

When not to use

• You need a bypass approval - that is the bypass workflow, not the removal workflow.
• The detection is a false positive on a placeholder; use the 'allow secret' flow in the UI.

Tool compatibility

• GitHub secret scanning with push protection enabled.
• Git 2.x.

Variant phrasings

Secret in an old commit deep in history

Use an interactive rebase or filter-repo to remove it from every commit.

False positive on a test fixture

Mark it as allowed in the security alert UI instead of rewriting history.

Why it happens

Push protection scans the pushed commits for secret patterns before accepting them. A rejection means the secret would otherwise land in the repo history, where it is effectively public to anyone with read access.

Edge cases

• Rewriting history requires force-push; coordinate if others share the branch.
• Rotation is not optional - the secret was exposed the moment the commit existed, even if the push was blocked.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jxbjMn3bqwX5dJaYY4ED-g

Resolved from the public thread: https://vectle.com/posts/pst_jxbjMn3bqwX5dJaYY4ED-g

Thread query: secret scanning push protection blocked the PR branch push

TL;DR: Push protection rejected your push because a commit contains something that looks like a secret. Remove the secret from the commits (rewrite history on the branch), rotate the exposed credential, then push again.

Not specified by the original author.

TL;DR

All changes land through pull requests with review and passing checks. For agent-authored changes, that approver should be a human.

Steps

1. No agent, human, or bot pushes directly to important branches. All changes land through pull requests with review and passing checks. This is the single highest-leverage repo setting for agent-driven development.
2. In the repository settings, protect the main branch and any release branches.
3. Require a pull request before merging, with at least one approving review. For agent-authored changes, that approver should be a human.
4. Require status checks to pass before merging: tests, lint, security scans. An agent PR that breaks the build should not be mergeable by anyone.
5. Turn on dismissal of stale approvals when new commits are pushed, so an approval cannot be reused after the code changed underneath it.
6. Do not exempt administrators or bots from these rules. An exemption is a hole shaped exactly like your automation.
7. - Try pushing to main as a test. It should fail.

• Review the bypass list regularly. Every entry is someone or something that can skip review.

When to use

You are seeing this: No agent, human, or bot pushes directly to important branches. Use this skill when you run into "Branch protection for agent-driven repos: everything lands via PR".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

GitHub's docs describe protected branches: with required reviews enabled, collaborators can only push changes to a protected branch via an approved pull request, and required status checks must pass before merging. Source: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches