Fail-open or fail-closed: audit a gate before you approve it

Safety auditClaudeupdated 2026-06-21sha 3bec85d60cbd

A vendor blog gives you a polite “review my error handling” prompt; this one bans the word “fine,” forces a per-branch OPEN/CLOSED table, makes you name the exact input that triggers the wrong action, and flags load-bearing safety try/catch that refactors love to delete.

You are reviewing a gate / validation / notification path. The worst wrong action here is: {{worst_wrong_action}}. Review only: {{path_or_files}}.

First, write one sentence: for this path, is a false alarm (firing when it should not) or a false silence (staying quiet when it should fire) the worse outcome? That answer sets which direction is CLOSED below.

Do not summarize what the code does. Do not praise it. Your job is to find where it fails OPEN when it should fail CLOSED.

Definitions, use them literally - relative to the worst action, NOT to "staying silent":
- FAIL CLOSED = on missing, ambiguous, stale, or error-state input, the code defaults to whatever AVOIDS {{worst_wrong_action}}. Depending on the path that may mean refusing and staying silent, or it may mean firing the alarm/brake - whichever avoids the worst action.
- FAIL OPEN = on that same bad input, the code does {{worst_wrong_action}} or a proxy of it: it proceeds, fires when it should not, OR stays silent when it should fire.

Walk every branch that can decide "act vs do-not-act" and produce a table with one row per branch:
| location (file:line) | trigger condition | on bad/missing/error input it currently... | OPEN or CLOSED | worst outcome if wrong | should be |

Specifically hunt for these fail-open smells and list each one you find, with the exact line:
1. try/except (or try/catch) where the except branch returns a value that lets the caller proceed, swallows the error, or logs-and-continues instead of refusing.
2. early `return True` / `return ok` / `return []` / `return None` that a caller reads as "all clear" rather than "could not determine".
3. a default parameter, env var, or config fallback that is the PERMISSIVE value (e.g. enabled, allow, send) when the real value is absent.
4. a check that is skipped entirely when an input is None/empty/unparseable, so absence of a signal reads as absence of risk.
5. a timeout, network, or parse failure path that ends in the action firing rather than being suppressed.

Rules for your verdict:
- You may not write "looks fine" or approve until you have named at least ONE concrete branch and stated, in one sentence, the exact input that makes it do the wrong thing.
- If after a genuine line-by-line pass you find zero fail-open branches, say so explicitly and then name the single branch you were LEAST sure about and why you ultimately cleared it. Silence is not a pass.
- For every fail-open row, give the one-line fix that makes it fail closed (what to return / refuse / suppress instead), and call out if that fix is load-bearing safety logic that a future "cleanup" refactor must never delete.
- Distinguish a guard that is INTENTIONALLY fail-open (documented, with a reason) from one that is so by accident. Flag undocumented ones as the higher risk.

End with: the single highest-risk fail-open branch, and whether you would block the change on it.

Fill in: path_or_files worst_wrong_action

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.