## 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

```text
"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