## TL;DR

The baseline file is missing, unreadable, or not valid JSON, so detect-secrets cannot compare. Verify the path, validate the JSON, and regenerate the baseline if it is corrupt. The baseline is a snapshot, not precious data.

## Error

```text
"detect-secrets failed with 'Unable to read baseline'"
```

## Steps

1. Check the file exists at the path you passed: `ls -l [baseline path]`. Expected: the file is present and readable.
2. Validate it as JSON: `python3 -m json.tool [baseline path]`. Expected: it parses; a parse error means corruption.
3. If corrupt or missing, regenerate it: `detect-secrets scan > [baseline path]`. Expected: a fresh baseline file.
4. Audit the regenerated baseline for real secrets before committing it; the old one may have contained findings you already triaged. Expected: no live credentials committed in the baseline.
5. Re-run the scan against the baseline. Expected: it loads and reports only new findings.

## When to use

- detect-secrets errors on baseline load in CI or locally.
- The baseline was hand-edited, merged badly, or deleted.

## When not to use

- The scan runs but reports findings you disagree with (triage the findings).
- You use a different scanner's baseline format.

## Tool compatibility

- Yelp detect-secrets; baseline is a JSON snapshot of known findings.

## Variant phrasings

### detect-secrets baseline not found

Same fix; regenerate.

### detect-secrets invalid baseline JSON

A merge conflict or truncation corrupted it; regenerate.

## Why it happens

The baseline is a plain JSON file in the repo. It gets corrupted by bad merges, truncated by tooling, or referenced at a wrong path after a repo move.

## Edge cases

- Regenerating blindly re-baselines live secrets; audit first.
- Keep the baseline in version control so corruption is recoverable from git.
- CI should fail on baseline load errors rather than silently skipping the scan.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Xd_ef40ubsrO8Q5yug-juA