Gitleaks

What it is

Gitleaks is a command-line tool that reads through your code, and your project's whole git history, looking for "secrets": API keys, passwords, database URLs and access tokens that should never be saved in code. Its default config has over 200 detection rules for services like OpenAI, Stripe, AWS and GitHub.

This matters more when an agent writes your code. Agents happily paste a key into a config file or an example .env to get something working. GitGuardian, which sells a competing scanner, reported that public commits co-written with Claude Code leaked secrets at about twice the average rate in 2025.

It's free, MIT-licensed, and has been around since 2018. But since May 2026 the README says it's "feature complete": security patches only. Its creator, Zach Rice, now works full time on Betterleaks, a successor sponsored by the security company Aikido. In his words: "I don't have full control over the Gitleaks repo and name anymore."

What actually happens when you use it

1. Scan what you have. Run gitleaks git -v inside a project and it checks every past commit. gitleaks dir scans plain folders instead.
2. Read the report. Each finding shows the file, line, commit and which rule matched, such as stripe-access-token.
3. Fix real leaks properly. Deleting the line isn't enough once it's in history: you rotate the key (make a new one and cancel the old one) at the provider.
4. Mark false alarms. Add an inline gitleaks:allow comment, a .gitleaksignore file, or an allowlist in a .gitleaks.toml config.
5. Block future leaks. As a pre-commit hook, a check that runs automatically every time you or your agent commits, it stops the commit if it finds a secret.

What people like

• It's the standard, trusted choice. Asked in July how people stop secrets reaching GitHub now that agents do the building, one reply was simply that Gitleaks is a fine tool and they'd recommend it.
• It catches leaks before they're public. Running as a pre-commit hook, it fails the commit on the spot, so the key never reaches GitHub. That's far cheaper than cleaning git history later.
• It looks inside encoded text. It now decodes hidden secrets by default, a change the maintainer said was made after a worm hid keys inside triple-encoded strings.
• False alarms are fixable. When it misread Swift code as a leaked key, a user solved it with a short allowlist rule in the config file.
• There's a clear path forward. Betterleaks is built to accept existing Gitleaks options and configs, so a setup you make today isn't wasted.

What people run into

• No new detection rules are coming. When users asked for a rule for passwords inside database URLs like postgres://user:pass@host, the maintainer said he's not adding any more rules and pointed to Betterleaks. A false-positive fix was turned away the same way.
• It misses some ordinary passwords. Its generic rule skips passwords containing characters like @#!%* to limit false alarms, so a real password went undetected. A plain login and password in JSON also passes.
• Release housekeeping has slipped. The latest version's tag isn't on the main branch, so the standard pre-commit update command quietly downgrades you. That issue has been open since April.
• Big repos can eat memory. One team saw scans use up to 24GB on a large repo after the decoding default changed. The README still lists the old default.
• The GitHub Action has strings attached. It needs a free licence key for organization accounts, and the sign-up form stopped working for weeks earlier this year.
• Local hooks can be skipped. Anyone can bypass a pre-commit hook. One r/devops commenter argued scanning only really works on the server side, where it can't be switched off.

Before you install

• Use it as one layer. Pair it with GitHub's own push protection, which blocks known key formats on GitHub's side, as suggested in the same Ask HN thread.
• Scan your history once. Before you make a repo public, run a full gitleaks git scan. If it finds a real key, rotate it at the provider first, then clean up.
• Pin the version in pre-commit by hand. Don't rely on pre-commit autoupdate until issue #2086 is fixed, and ignore the old version number in the README example.
• Look at Betterleaks for new setups. It's by the same author and adds features like checking whether a found key still works. Its v2 is still a release candidate, so it's newer and less proven.
• Tell your agent about it. Ask it to keep secrets in .env files that are listed in .gitignore, and to never use SKIP=gitleaks to get a commit through.

The short version

Gitleaks does one important job well: it stops your agent's commits from publishing your API keys. It's mature, free and widely trusted. But it won't learn new tricks, a few common password formats slip past it, and its author's attention has moved to Betterleaks. Install it today if you have nothing, and keep an eye on its successor.