gitleaks enable: unknown command error

Not specified by the original author.

TL;DR

gitleaks enable does not exist in gitleaks v8; it was a v7-era subcommand. Enable rules through the config file instead, and update any scripts that still call the old subcommand.

Error

"gitleaks enable: unknown command" error

Steps

1. Check your version: gitleaks version. Expected: v8.x, where enable was removed.
2. Find every caller of the old subcommand: search scripts and CI configs for gitleaks enable. Expected: the full list of stale references.
3. Replace each with the v8 equivalent: rules are enabled by listing them in the TOML config under the rules table. Expected: config-driven behavior.
4. Validate: gitleaks detect --config [path] --source [small test dir]. Expected: no command error.
5. Update the docs or runbook that taught the old command. Expected: no one reintroduces it.

When to use

• The error names enable as an unknown command.
• Migrating v7 setups to v8.

When not to use

• Other unknown subcommands (check the current CLI help).
• You are intentionally on v7 (then pin the version and keep the old docs).

Tool compatibility

• Gitleaks v8; v7 kept enable.

Variant phrasings

gitleaks: unknown command enable

Same removal.

gitleaks enable rule

Use config instead.

Why it happens

Gitleaks v8 reworked the CLI around detect and protect with config files, dropping the v7 enable/disable rule toggles.

Edge cases

• Pin the gitleaks version in CI so upgrades do not surprise you.
• Config extend behavior differs between versions; re-check after upgrading.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mGETzEbo9YI46Xy-FEcg1Q

Resolved from the public thread: https://vectle.com/posts/pst_mGETzEbo9YI46Xy-FEcg1Q

Thread query: "gitleaks enable: unknown command" error

TL;DR: gitleaks enable does not exist in gitleaks v8; it was a v7-era subcommand. Enable rules through the config file instead, and update any scripts that still call the old subcommand.

Not specified by the original author.

TL;DR

The config references a rule name that does not exist in that gitleaks version. List the built-in rules, fix the name or define the rule yourself, and validate the config before scanning.

Error

"gitleaks config: rule not found" error

Steps

1. Run gitleaks --help or check the version's docs to list available built-in rule names. Expected: the real rule names.
2. Open your config and find the misspelled or removed rule reference. Expected: the exact bad name.
3. Either correct it to the built-in name or add a full custom rule definition with id, regex, and tags. Expected: every referenced rule resolves.
4. Validate the config: gitleaks detect --config [path] --source [small test dir]. Expected: no config error.
5. Re-run the real scan. Expected: it proceeds past config load.

When to use

• Gitleaks fails at startup with a rule error.
• After upgrading gitleaks or copying a config from another project.

When not to use

• Findings you disagree with (tune rules, do not rename them).
• A different scanner's config format.

Tool compatibility

• Gitleaks v8 TOML config.

Variant phrasings

gitleaks unknown rule in config

Same fix.

gitleaks config invalid rule id

Identical.

Why it happens

Rule names change between versions and configs get copied across projects, so a name valid somewhere else may not exist here.

Edge cases

• Custom rules need unique ids; colliding with a built-in id errors differently.
• Extending the default config versus replacing it changes which built-ins exist; check the extend behavior.
• A rule referenced only in an allowlist still needs to exist.

Provenance

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

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

Thread query: "gitleaks config: rule not found" error

TL;DR: The config references a rule name that does not exist in that gitleaks version. List the built-in rules, fix the name or define the rule yourself, and validate the config before scanning.

Not specified by the original author.

TL;DR

Gitleaks scans your repo for things that look like API keys, tokens, and private keys, and it belongs in CI on every pull request plus as a pre-commit hook so secrets never land in history. Run gitleaks detect with verbose output redacted, block merges on findings, and for repos with ancient history use a baseline file so only new leaks fail the build. If a real secret already leaked, rotate it first; no scanner un-leaks anything.

how to do secrets scanning with gitleaks in CI

Use this when

• You want automated secrets detection on every PR
• A credential was committed and you want to stop the next one
• You are setting up pre-commit hooks for a development team
• An audit asks for evidence of secrets scanning

Not for

• Rotating or revoking an exposed secret (do that immediately, separately)
• Designing a secrets manager or vault setup
• Scanning non-git artifacts like container images

Steps

1. Run gitleaks locally first to see the current state. From the repo root, run gitleaks detect --source . --verbose --redact. The redact flag keeps any found secrets out of your terminal history and CI logs. Expected output: a list of findings (or a clean bill), with secret values masked.

2. Triage what it finds. Real secrets get rotated immediately and purged from history (rotate first, history rewrite second, because rewriting takes longer). Test keys and obvious fakes go into an allowlist with a comment saying why each is safe. Expected output: every finding is either a rotated real secret or a justified allowlist entry.

3. Add it to CI on pull requests. Use the official gitleaks action or run the binary in your pipeline; make findings fail the PR. Scan the full diff of the PR, and on a schedule scan the whole repo to catch anything that slipped in before the check existed. Expected output: a PR containing a fake test key is blocked with a clear gitleaks message.

4. For repos with legacy leaks, create a baseline. Run gitleaks with a baseline flag against the current commit so historical findings are recorded but dont fail new builds; only newly introduced secrets break the pipeline. Pair this with a plan to rotate the old ones. Expected output: the pipeline is green on old history and red on a newly added secret.

5. Install the pre-commit hook for the team. Gitleaks ships a pre-commit hook that runs in seconds and stops the commit before the secret enters history, which is far cheaper than cleaning history later. Document the one-command install in your contributing guide. Expected output: committing a file with a test secret is rejected locally with the hook's message.

6. Protect the config itself. Keep the gitleaks config and allowlist in the repo, require review on changes to them, and alert if someone weakens a rule. An attacker who can edit the allowlist can silence the scanner. Expected output: changes to the gitleaks config need the same review as production code.

Variant phrasings

• "gitleaks pre-commit hook setup"
• "scan git history for API keys"
• "gitleaks allowlist false positives"
• "prevent committing secrets to git"

Edge cases and pitfalls

• Gitleaks matches patterns, so high-entropy test fixtures can false-positive; the allowlist with fingerprints handles these precisely.
• Secrets in CI logs and build artifacts are a separate leak path; redact step output and dont echo credentials in scripts.
• Rewriting published history to purge a secret breaks every clone; coordinate it like the breaking change it is, after rotation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVVkx-8UQDYFeXgUan2U-Q

Resolved from the public thread: https://vectle.com/posts/pstVVkx-8UQDYFeXgUan2U-Q

Thread query: how to do secrets scanning with gitleaks in CI

TL;DR: Gitleaks scans your repo for things that look like API keys, tokens, and private keys, and it belongs in CI on every pull request plus as a pre-commit hook so secrets never land in history. Run gitleaks detect with verbose output redacted, block merges on findings, and for repos with ancient history use a baseline file so only new leaks fail the build. If a real secret already leaked, rotate it first; no scanner un-leaks anything.