Configure

Protected Paths

Tell PRMergeSafe which files are extra-sensitive. Changes to these paths always trigger the most thorough analysis with verification.

Paid feature. Available on Starter, Team, and Scale plans. Free tier ignores protected-paths config.

What protected paths do

Some files are riskier than others. A change to a CSS file is rarely dangerous. A change to auth middleware, payment logic, or a database migration could break production.

When you mark certain paths as "protected", PRMergeSafe treats any PR that touches them differently:

  1. Force-deep analysis — skips the cheap triage stage and goes straight to full Sonnet deep analysis
  2. Adversarial verification — every HIGH or CRITICAL finding gets a second-opinion Opus check to confirm real risk and cut false positives
  3. Honest uncertainty — when a result is genuinely ambiguous, PRMergeSafe flags it for human review rather than guessing a verdict

Because protected-path PRs always run deep analysis (Sonnet, plus an adversarial Opus check on HIGH/CRITICAL findings) instead of stopping at the cheap triage, they naturally cost more credits than a typical PR that triages to safe. Expect 5–10× the credits of a normal small PR — that's the real AI cost being passed through.

Path syntax

Protected paths use standard glob syntax (the same as your .gitignore):

migrations/**           # all files under migrations/, any depth
src/auth/**             # entire auth directory
src/payments/**         # entire payments directory
**/security/**          # any directory named "security" anywhere
*.sql                   # any .sql file in the repo
src/api/admin/*.ts      # only .ts files directly under src/api/admin

Recommended starting set

A reasonable default for most teams. Copy this into your dashboard and adjust:

migrations/**
**/auth/**
**/security/**
**/payments/**
*.sql
package.json
requirements.txt
go.mod

These cover the categories most likely to break production: schema migrations, auth boundaries, security checks, payment logic, and dependency lockfiles.

Hard cap on patterns

You can have up to 20 protected-path patterns per org or per repo. This isn't a license cap — it's an abuse defense.

Without a limit, a user could add ** as a protected path, forcing every PR through the most expensive pipeline. The 20-pattern cap matches realistic team needs (most teams use 5–10 patterns) while preventing accidental cost spirals.

Per-repo overrides

Org-wide protected paths apply to every repo by default. You can also set per-repo paths that extend the org list (additive) on the per-repo settings page.

Useful when a specific repo has unique sensitive directories (e.g. one repo has a payments module the others don't).

When NOT to use protected paths

  • Files you change often — protected paths always run the full pipeline, which uses more credits. If you touch src/api/** on half your PRs, marking it protected will burn through credits faster than necessary.
  • Low-stakes paths — README, docs, tests. PRMergeSafe's default analysis is already thorough.
  • To "force" deeper analysis just because — the default analysis is good. Reserve protected paths for genuinely high-stakes code.