codyswanngt/lisa-parity-safety-net-rules

Parity Safety-Net Rules

Manage the custom guard rules that Lisa's safety-net hook enforces on every Bash command. The hook (hooks/parity-safety-net.sh, registered as a PreToolUse matcher on Bash) ships with built-in guards against catastrophic commands; this skill lets a project view, set, and verify additional project-specific rules on top of those built-ins.

Lisa-native reimplementation. Upstream 0.9.0 shipped two rule-management skills (set-custom-rules + verify-custom-rules), which this skill consolidates. Upstream 1.0.6 consolidated them too (into cc-safety-net) and moved custom rules to a JSON rulebook system driven by the npx cc-safety-net rule CLI. Lisa deliberately keeps its simpler ERE-lines-file design: the Lisa hook must run identically on Codex, agy, Copilot, Cursor, and Claude without an npx dependency, and a flat regex file is auditable in any of those runtimes. It is reimplemented from scratch against Lisa conventions — it does not port or invoke upstream plugin code.

Drift tracking. Pinned to safety-net@[email protected]. scripts/plugin-parity-drift.mjs compares this pin against the upstream version in the plugin cache and flags staleness. Do not port or copy upstream plugin code.

2.0.3 review. Upstream 2.0.2–2.0.3 added Kimi Code and Amp installation support and release tooling. Those changes do not alter the upstream rule-management skill or Lisa's project-local ERE rule contract, and Lisa does not currently ship hooks for those runtimes, so no behavior is absorbed here.

2.0.4 review. Method, so the next person can re-run it rather than trust it: hash the sorted (relative path, content) manifest of every rule-bearing directory in the plugin cache under both versions, then diff the trees excluding dist/, .git/, and node_modules/. Result — src/ (230 files), skills/ (1), and hooks/ (1) are byte-identical across 2.0.3 and 2.0.4 (src digest 7e346e205fbd1aa7 both sides). The only non-generated differences are the version string in package.json, kimi.plugin.json, and .claude-plugin/plugin.json, plus a test-harness fix in tests/cli/cli-statusline.test.ts that tolerates EPIPE when an oversized payload is flushed at the bounded reader's cap. Everything else is rebuilt dist/ output. No rule, guard family, or skill surface moved, so nothing is absorbed here — and, critically, 2.0.4 does not close the gap recorded below, which therefore carries forward unchanged rather than being dropped at the new pin.

Known gap at the 2.0.4 pin. Upstream 2.0.0 rebuilt its engine and added two guard families this hook does not mirror: secret.* (blocks reading or copying SSH keys, .env files, cloud credentials, and coding-CLI credential stores) and rm.git-metadata (blocks deleting the .git control plane). Both were measured against this hook rather than assumed — see the probe table in parity/plugin-routing/[email protected]. Absorbing secret.* also needs a matcher change, because this hook is registered on Bash only while upstream also screens file tools. That work is tracked separately in parity/FOLLOWUPS.md §5; do not treat this skill's built-in guard list as covering secret access.

How the rules work

• The hook always enforces its built-in guards (see below). These cannot be disabled from the rules file — they are the floor.
• Custom rules live in a project-local file, one POSIX extended regular expression (ERE) per line. Blank lines and lines beginning with # are ignored. Matching is case-insensitive (grep -Ei).
• If any built-in guard or custom rule matches the proposed command, the hook exits non-zero and the Bash call is blocked, with the reason shown to the agent.

Rules file location

Resolved in this order:

1. $SAFETY_NET_RULES_FILE (explicit override), else
2. ${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt

RULES_FILE="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"

Built-in guards (always on)

1. rm -rf of a filesystem root, $HOME/~, or a top-level wildcard — with quote-aware boundaries, so wrapper/interpreter forms like bash -c "rm -rf /" and python -c "… os.system('rm -rf /')" match too. Path-prefixed spellings (/bin/rm, ./rm) count as rm for every rm guard.
2. rm -rf target hardening: the cwd itself (././), ..-traversal paths, home-anchored ~/… paths, absolute paths outside the project (/tmp, /var/tmp, and $TMPDIR are allowed), $VAR targets other than $TMPDIR, and any recursive forced delete while the working directory is $HOME.
3. Force-pushing a protected branch (main/master/production/prod/release). --force-with-lease is intentionally allowed, and so is force-pushing a feature branch (sanctioned rebase workflow). Acceptable parity divergence: a refspec force-push (git push origin +main) is not blocked — upstream 1.0.6 allows it too.
4. git reset --hard / git reset --merge while the working tree is dirty (would discard work). Clean-tree resets are intentionally allowed.
5. git rebase --abort / git rebase --quit while the in-progress rebase holds human-made conflict resolutions (they would be discarded). A clean or untouched rebase state stays abortable — an agent-recoverable wedge; the apply backend and a missing AUTO_MERGE ref fail closed. Deliberate divergence: upstream blocks rebase --abort unconditionally.
6. git checkout discards: the -- pathspec form (with or without a ref), -f/--force, --pathspec-from-file, and bare git checkout .. Branch switching and -b/-B creation stay allowed.
7. git switch --discard-changes / -f/--force.
8. git restore touching the worktree — only git restore --staged <path> without --worktree is allowed (unstaging is safe).
9. git stash drop / git stash clear (push/pop/list/apply stay allowed).
10. git clean with a force flag and no dry-run — -n/--dry-run anywhere makes it a safe preview.
11. git branch -D (or -d combined with -f, clustered or split); safe -d and rename -m stay allowed.
12. git tag -d, git reflog delete, git worktree remove --force.
13. Deletion via find … -delete, find … -exec rm -rf, and xargs … rm -rf (plain non-recursive rm on find/xargs output stays allowed).
14. Disk destroyers: dd of=/dev/…, mkfs … /dev/…, shred.
15. Destructive SQL — DROP DATABASE/SCHEMA/TABLE, TRUNCATE TABLE.

Every git guard sees through leading git global options (-C <path>, -c <k>=<v>, --git-dir[=…], --no-pager, …), so git -C /path <destructive> is screened the same as git <destructive>.

Malformed hook input fails closed (exit 2 denies the command). A text-scan hook cannot exempt display commands, so prose like echo "docs about rm -rf /" can false-positive — quote-break the string or use the gh-writer heredoc form (payload is stripped before the guards run). For the same reason the rm guard treats substitution-wrapping as verdict-neutral (issue #1982): an executable echo "$(rm -rf /)" is blocked, and so are inert twins the shell would never expand — a single-quoted echo '$(rm -rf /)' or an escaped echo "\$(rm -rf /)" — since the scan has no quote-context awareness. The same quote-break or heredoc workaround applies. Spell that heredoc workaround with a quote-pair delimiter (gh issue create --body-file - <<'EOF') — only that spelling reaches the payload-strip path. <<"EOF" and <<\EOF do not, and a gh … <<\EOF writer now fails closed instead.

What this does and does not defend against

Read this before treating the safety net as a wall.

What it is for: stopping accidental catastrophic commands — an agent (or a human) that reaches for rm -rf /, force-pushes main, drops a table, or writes to a raw device by mistake. Within that job the guards above are the floor and they are always on.

What it is not: a security boundary against a deliberate adversary. Two structural reasons, both accepted rather than open bugs:

• It is a text scan, not a shell engine. It has no quote-context awareness, which produces the false positives described above and means an operation spelled in a way the patterns do not anticipate is not matched.
• The here-doc classifier re-implements bash's lexer in Python to decide which payload text is inert data. Every divergence from real bash is a shape it mis-classifies. Eight distinct divergences were found and fixed across issues #1958 and #1993; the class is open-ended, so it is now closed as an accepted limitation rather than chased indefinitely.

Why that is tolerable: a here-doc mis-classification degrades to the content guards rather than bypassing them. Only the narrow gh issue|pr writer form ever strips payload text; every other path passes the raw command to the guards, and since issue #1982 those guards see through substitution wrappers. So a mis-read here-doc costs no guard coverage for any destructive class listed above.

The honest bottom line: an agent that is actively trying to run something destructive has many paths that never involve a here-doc at all — the safety net does not claim to close them. Do not rely on it as the only control over what an agent may execute; treat it as the last line of defence against mistakes, and keep the real boundary (credentials, permissions, environment isolation) outside the agent.

View the current rules

RULES_FILE="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"
if [ -f "$RULES_FILE" ]; then
  echo "Custom safety-net rules ($RULES_FILE):"
  grep -vE '^[[:space:]]*(#|$)' "$RULES_FILE" || echo "(no active rules)"
else
  echo "No custom rules file yet ($RULES_FILE). Only built-in guards are active."
fi

Read the file to show comments and structure as well.

Set (add or edit) a rule

A rule is an ERE matched against the full command string. Keep rules specific to avoid blocking legitimate work — anchor on the dangerous verb and its target.

1. Ensure the file exists, then append a commented rule (use Edit/Write, or append from the shell):

   RULES_FILE="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-net-rules.txt}"
   mkdir -p "$(dirname "$RULES_FILE")"
   {
     echo "# Block deleting a Kubernetes namespace"
     echo 'kubectl[[:space:]]+delete[[:space:]]+namespace'
   } >> "$RULES_FILE"
   

2. Always verify the new rule (next section) before considering it set — confirm it blocks what it should and allows what it shouldn't.

Editing/removing: open the file with Edit and change or delete the line. Removing a rule never affects the built-in guards.

Verify the rules

Two checks — both should pass before you trust a rule.

1. The ERE is valid

An invalid regex would make the hook error on every command. Validate it:

printf '%s' "$RULE" | grep -Eq -- "$RULE" 2>/dev/null && echo "valid ERE" \
  || echo "INVALID ERE — fix before saving"

2. The rule behaves as intended

Drive the actual hook with a fake PreToolUse payload and assert the exit code (non-zero = blocked, 0 = allowed). Build the JSON with jq so the test command line itself never contains the dangerous literal:

HOOK="${CLAUDE_PLUGIN_ROOT}/hooks/parity-safety-net.sh"

check() { # check <expect: block|allow> <command>
  jq -nc --arg c "$2" '{tool_name:"Bash",tool_input:{command:$c}}' \
    | bash "$HOOK" >/dev/null 2>&1
  local code=$?
  local got=allow; [ "$code" -ne 0 ] && got=block
  printf '%-5s want=%-5s got=%-5s  %s\n' \
    "$([ "$got" = "$1" ] && echo OK || echo FAIL)" "$1" "$got" "$2"
}

# Should block (matches the new rule):
check block "kubectl delete namespace prod"
# Should allow (must not over-match):
check allow "kubectl get pods"

Report a table of cases with want/got/verdict. If any case disagrees, tighten the ERE and re-verify.

Rules

• Built-in guards are the floor — custom rules only add blocks; they cannot weaken the built-ins.
• Prefer specific over broad — a rule that blocks too much trains users to bypass the safety net. Anchor on verb + target.
• Verify every rule against the real hook before saving — never ship an unverified or syntactically invalid ERE.
• Never weaken the net to unblock yourself. If a built-in guard fires on a command that is genuinely safe, run it manually outside the agent after the user confirms — do not edit the hook to remove the guard.