Team policy file

.paranoid.toml at the repo root is the only other file paranoid reads besides command-line flags. It is optional, and it has exactly four keys.

The four keys

fail-under = 80
strict = true

[[disable]]
rule = "TI012"
reason = "flaky under load, tracked in issue #142"
expires = "2026-12-01"

[sandbox]
image-go = "golang:1.26"
image-python = "python:3.12-slim"
image-node = "node:22-slim"

[[disable]] is an array of tables: repeat the block to disable more than one rule. [sandbox] may appear at most once. Both are optional; a file with only fail-under and strict is valid, and so is an empty file.

Precedence

Flag beats file beats default, for both fail-under and strict:

1. The command-line flag wins whenever it is given on the command line, even to a value that happens to match the built-in default.
2. Otherwise, .paranoid.toml's value wins, when the file sets that key.
3. Otherwise, paranoid's own default applies: fail-under 50, strict off.

--sandbox-image always wins over a [sandbox] pin, the same rule. A pin only applies to the language DetectSuite already chose (a Python pin does nothing on a Go repository); it never changes which suite is detected.

Every command that runs the verify pipeline (verify, baseline, fix-prompt) honors an auto-detected policy file the same way. Only verify exposes --no-policy today; the other two commands cannot opt out of it individually yet.

How a disabled rule appears in the report

A [[disable]] match is reported exactly the way a baseline match is (see Baseline & suppressions): the finding leaves findings and the score, and appears in the report's suppressed section with the entry's reason. The one difference is the source field on each suppression entry, "policy" instead of "baseline"; text and markdown output label it suppressed-by-policy rather than suppressed-by-baseline, so the two are never confused. An entry whose expires date has passed stops suppressing: its finding comes back into the report and the score, and the report still lists the expired match.

Matching is by rule ID alone, not by file or evidence text the way a baseline entry matches: a [[disable]] entry disables that rule everywhere in the diff, not one specific finding of it. Disabling a rule this way is broader than baselining one finding; use the baseline file instead when you want to carry forward one specific, already-reviewed finding.

See Report & schema for the exact JSON shape.

Loading

.paranoid.toml loads from the repo root only, the same rule the baseline file follows: no path-override flag, no walking up parent directories, no global file outside the repo. A missing file is not an error, there is simply nothing to load. A file that exists but fails to parse is always a hard error (exit 3), naming the key or table that broke it.

Using this in CI

Commit .paranoid.toml at the repo root; the GitHub Action needs no new input for it, since the file is read from the checked-out repository itself, the same way .paranoid-baseline.json already is. [[disable]] and [sandbox] apply exactly as they do outside CI. fail-under does not: the action always passes --fail-under explicitly (that input's own default is 50), so a repo's fail-under key never takes effect through the action; strict is unaffected, since the action only adds --strict when its own strict input is true. See Exit codes & CI.