gitleaks: fatal: not a git repository

Not specified by the original author.

TL;DR

gitleaks defaults to git mode, so running it from a plain directory fails with "fatal: not a git repository". Either run it from inside the checkout or add the no-git flag and point it at the files directly. The scan itself is fine; only the invocation context is wrong.

Error

gitleaks: fatal: not a git repository

Steps

1. Confirm whether the target is actually a git repo: run git rev-parse --is-inside-work-tree in the scan directory. Expected: it prints true; if it prints false or errors, the directory is not a repo.
2. If it is a repo, change into it (or fix the CI working directory) and rerun gitleaks detect --source . --verbose. Expected: the scan starts instead of erroring.
3. If the target is intentionally not a repo (a tarball, a build artifact dir), rerun with no-git mode: gitleaks detect --source /path/to/dir --no-git --verbose. Expected: gitleaks walks the files and reports findings or "no leaks found".
4. In CI, make sure the checkout step runs before the scan step and that both share the working directory. Expected: the scan step sees the .git directory and runs in git mode.
5. If you only want staged or committed content scanned, run gitleaks protect --staged --verbose from the repo root instead. Expected: pre-commit style scan of staged changes.

When to use

• gitleaks detect or gitleaks protect fails with "fatal: not a git repository"
• A CI scan step fails because it runs before checkout or in the wrong directory
• Scanning an extracted archive or artifact directory rather than a clone

When not to use

• gitleaks reports actual findings (that means it worked; rotate the leaked values)
• Errors about config files or rules (different root cause)
• You need history scanning (use git mode from inside the repo)

Tool compatibility

• gitleaks v8.x (detect, protect, --no-git, --source flags as documented)

Variant phrasings

gitleaks protect fails outside a repo

Same fix: gitleaks protect also assumes a git checkout. Run it from the repo root in pre-commit hooks, or switch to detect --no-git for plain directories.

gitleaks in Docker says not a git repository

The container working directory usually lacks the .git mount. Mount the repo (including .git) into the container or use --no-git against the mounted files.

Why it happens

gitleaks detect opens the source path as a git repository first and shells out to git log for history. When no .git directory exists it aborts before scanning anything. The --no-git flag switches the engine to a plain filesystem walk, which is what you want for archives and build outputs.

Provenance

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

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

Thread query: gitleaks: fatal: not a git repository

TL;DR: gitleaks defaults to git mode, so running it from a plain directory fails with "fatal: not a git repository". Either run it from inside the checkout or add the no-git flag and point it at the files directly. The scan itself is fine; only the invocation context is wrong.

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.

Not specified by the original author.

TL;DR

gitleaks looks for .gitleaks.toml in the current working directory, so running it from anywhere else fails. Pass the real path with --config or create the file where you run the scan. One flag or one new file fixes it.

Error

gitleaks: could not find config file at .gitleaks.toml

Steps

1. Check what actually exists: run ls -la in the scan directory and look for .gitleaks.toml or gitleaks.toml. Expected: you see whether the file is missing or just in a different directory.
2. If the file exists elsewhere, pass it explicitly: gitleaks detect --source . --config /path/to/.gitleaks.toml --verbose. Expected: the scan starts instead of complaining about the config.
3. If no config exists at all, generate a starter: gitleaks detect --source . --no-git once without a config to use built-in rules, then save your allowlist additions to a new .gitleaks.toml in the repo root. Expected: subsequent runs pick the file up automatically from the repo root.
4. In CI, either run the scan from the directory containing the config or export an absolute config path into the scan step. Expected: the same command works locally and in CI.
5. Validate the TOML after edits (a syntax error surfaces as a different failure): run gitleaks detect --config /path/to/.gitleaks.toml --source . --no-git on a small directory. Expected: it completes without a config parse error.

When to use

• gitleaks exits immediately complaining it cannot find .gitleaks.toml
• CI scan works locally but fails in the pipeline (working-directory mismatch)
• You renamed or moved the config and scans broke

When not to use

• gitleaks runs but reports findings you disagree with (allowlist tuning instead)
• "rule not found" errors (the config loaded, but a rule id is wrong)

Tool compatibility

• gitleaks v8.x (--config flag, TOML config format)

Variant phrasings

gitleaks cannot find config in CI

Pipelines often run each step in a fresh working directory. Pin the config with an absolute --config path or cd to the repo root before scanning.

gitleaks.toml vs .gitleaks.toml name confusion

gitleaks accepts both the dotted and non-dotted name in the working directory. If you pass --config, any filename works as long as the content is valid TOML.

Why it happens

gitleaks resolves a relative config path against the process working directory, not against the --source directory. Monorepos, Docker containers, and CI steps that cd elsewhere therefore miss a config that exists in the repo root.

Provenance

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

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

Thread query: gitleaks: could not find config file at .gitleaks.toml

TL;DR: gitleaks looks for .gitleaks.toml in the current working directory, so running it from anywhere else fails. Pass the real path with --config or create the file where you run the scan. One flag or one new file fixes it.