kenryu42/claude-code-safety-net/cc-safety-net

CC Safety Net

CC Safety Net hooks into coding agent CLIs (Claude Code, Codex, Cursor, Gemini CLI, and others) and blocks destructive commands and secret access before they run. The cc-safety-net CLI inspects and controls that protection. Run it as npx -y cc-safety-net.

Learn the current CLI

The installed CLI is the authority for command syntax. Do not guess flags.

npx -y cc-safety-net --help
npx -y cc-safety-net help <command>

Run npx -y cc-safety-net rule doc and treat that output as the complete source of truth for rulebook schema, paths, GitHub sources, matching behavior, and validation.

These commands are read-only and safe to run for discovery: --help, --version, status, doctor, logs (without --prune-legacy), explain, rule list, rule verify, rule doc, policy check, help. Every other command mutates configuration or installed integrations; run those only as part of a workflow below.

Core model

• Built-in guards always apply. Custom rules only add restrictions; nothing in rule config can

bypass built-in CC Safety Net protections.

• Config files (rule.json) list rulebook sources. Rule definitions live in rulebook.json,

not directly in rule.json.

• Three scopes: user (all projects), project (current project only), and shareable GitHub

rulebooks at .cc-safety-net/rules/<rulebook-name>/rulebook.json in a repository.

• Rulebooks are live files. The runtime reads each rulebook.json on every tool call, so a saved

edit applies to the next command with no sync step.

• policy.json sets the safety level, per-feature toggles, per-rule overrides, and path lists. It

has two scopes: the project file .cc-safety-net/policy.json, committed and shared with the team, layered on the user file that applies to every project.

• The session safety level is standard, strict, or paranoid, set per session with the

CC_SAFETY_NET_LEVEL environment variable.

Choose the workflow

• The user asks why a command was blocked, or shows a BLOCKED by CC Safety Net message:

explain a decision.

• The user thinks a block was wrong: triage a false positive.
• The user wants to add, edit, disable, or migrate blocking rules: configure rules.
• The user wants to change the safety level, toggle a protection, or adjust path lists: configure

the policy.

• The user wants CC Safety Net installed into or removed from an agent CLI: manage integrations.
• A rule does not fire, or the user asks whether protection is working: diagnose.
• The user asks how or why the analyzer behaves a certain way, beyond what explain and

rule doc show: answer from the source.

Explain a decision

1. Get the exact blocked command. If the user does not have it, find it with

npx -y cc-safety-net logs (narrow with --project ., --agent <name>, or --since <days>).

1. Pass the exact command to npx -y cc-safety-net explain as one literal argument. Prefer an

argv-capable tool; when invoking through a shell, shell-escape the whole command as one argument. Never interpolate raw command text into double quotes: $(), backticks, and variables would expand before explain receives it. Add --cwd <path> when the decision depends on the working directory, and --shell posix or --shell powershell when the blocked call came from a host tool that runs that shell, such as Claude Code's Bash or PowerShell tool; the default auto can read a command differently. Once received, explain analyzes the string and never executes it.

1. Read the trace: how the command was split, which rule matched, and the RESULT status and

reason. explain exits 0 for both allowed and blocked verdicts; read the verdict from the output, not the exit status.

1. Report the reason in plain language. For a genuine hazard, suggest the safer alternative the

reason names, such as git stash before git reset --hard.

Triage a false positive

1. List recent suspect denials with npx -y cc-safety-net logs --suspect --since 7, or fetch

one entry with npx -y cc-safety-net logs --id <id>.

1. Reproduce the decision with explain and read which rule fired.
2. If a custom rule fired, fix that rulebook: disable or reword it with an override, or edit the

rule (see configure rules), then re-run explain to confirm the new verdict.

1. If a built-in rule fired, no rule edit can relax it. Check the reason for a documented escape

hatch, such as CC_SAFETY_NET_WORKTREE=1 for local git discards in linked worktrees (git discards in a temp-root repository outside the workspace are already allowed), or rule wrapper add when a trusted transparent wrapper hid the real command from the analyzer. Pass the wrapper name as a separate argv value, or shell-escape it as one argument. If the user explicitly wants that built-in rule off, read its id from the ruleId field of explain --json and propose a per-rule policy override (see configure the policy). Otherwise explain the risk the rule guards against and suggest reporting the case at https://github.com/kenryu42/cc-safety-net/issues.

Configure rules

Use information already provided in the user's prompt. Ask only when the scope, action, rule intent, merge behavior, or target command is unclear.

1. Determine the requested scope from the prompt when possible:

• User: applies to all projects.
• Project: applies only to the current project.
• GitHub: edits or creates a shareable rulebook structure in the current repository.

1. Determine whether to add a rule, edit a rule, disable a rule, override a reason, trust a

transparent wrapper, migrate legacy rules, or explain custom rules from the prompt when possible.

1. Inspect existing configs before modifying installed local rules:

• Run npx -y cc-safety-net rule verify
• Run npx -y cc-safety-net rule list

1. Inspect relevant project files only when the user asks for rule suggestions or the requested

rule depends on project context. Look at manifests, scripts, task runners, CI, infrastructure, database, migration, and deployment files that explain risky commands.

1. Convert the request into valid CC Safety Net JSON using rule doc.

• For User or Project scope, add or edit the selected local rule.json and

<rulebook-name>/rulebook.json.

• For GitHub scope, add or edit .cc-safety-net/rules/<rulebook-name>/rulebook.json in the

current repository.

• Do not offer to add a GitHub source with owner/repo; installing rules from a GitHub

source is outside this workflow.

• If the user explicitly asks to install existing GitHub rulebooks instead of authoring them,

use npx -y cc-safety-net rule add owner/repo --only <rulebook...>; omit --only only when they want every rulebook, and add --ref <ref> only when they name a non-default ref. rule add --only <rulebook...> with no source selects from the official cc-safety-net/rulebooks repository, whose curated rulebooks block destructive Terraform, AWS, gcloud, and Azure CLI operations; prefer installing one of those over authoring when it already covers the request.

• For transparent wrappers, prefer npx -y cc-safety-net rule wrapper add with the trusted

wrapper name passed as a separate argv value, or shell-escaped as one argument, over editing rule.json by hand.

1. Preserve unrelated existing rulebook sources, overrides, and rulebooks. Preview proposed JSON

before writing when creating a new rulebook, merging with existing config, or resolving ambiguity.

1. For GitHub rules, ensure the repository layout is

.cc-safety-net/rules/<rulebook-name>/rulebook.json, and ensure the source name, directory name, and rulebook name match exactly.

1. Validate after edits:

• User or Project rules: run npx -y cc-safety-net rule verify and `npx -y cc-safety-net rule

list. Both commands cover every scope, so neither takes --global`.

• Shareable GitHub rulebook-only edits: run npx -y cc-safety-net rule verify. Run list only

if the rulebook is also installed in local rule.json.

1. If validation fails, show the exact errors and make the smallest fix.
2. Confirm the saved paths or GitHub rulebook path and summarize the added or updated rules.

Rule invariants:

• Do not use legacy inline .safety-net.json or ~/.cc-safety-net/config.json rules. Convert

existing legacy files with npx -y cc-safety-net rule migrate.

• Every rule command must be listed in allowed_commands. The tests fixtures are optional;

rule verify evaluates rulebook_version 2 fixtures against the rulebook's own rules, and fixture commands are analyzer input that CC Safety Net never executes.

• A blocked fixture, when present, must specify the expected rule, and that rule must exist in

the rulebook.

• Local source names are bare names such as project-rules; do not put filesystem paths in

rules.

• A saved rulebook is live. There is no pending state and nothing to run afterwards, so verify the

edit rather than activating it.

• A missing or invalid rulebook file makes that source inactive, and an unreadable or invalid

rule.json makes every source in its scope inactive: those rules stop applying while other custom rules and built-in protections stay active. Fix the file named in the diagnostic.

• A duplicate rulebook name keeps the first claim, user scope before project scope, and ignores

the later rulebook.

• npx -y cc-safety-net rule add owner/repo fetches remote rulebooks, validates them, and vendors

each one into <rulebook-name>/rulebook.json; npx -y cc-safety-net rule update [source] re-fetches and overwrites those copies and prints what changed. The runtime never fetches, and a remote source with no vendored file reports that rule update has to vendor it first.

• rule sync is deprecated: it only migrates lock and cache leftovers from an earlier version.

Never run it as a validation or activation step.

Configure the policy

Both policy.json files are protected: you propose the change, the user applies it. Reading them is allowed, writing them is not.

policy.json fields, all optional except version: 1 (policy check reports every schema error, so validate against it rather than guessing further fields):

• safety.level: standard, strict, or paranoid. safety.overrides: booleans for

fail_closed, paranoid_rm, and paranoid_interpreters that pin one capability apart from the level.

• workflow.worktree_mode: boolean, allows local git discards in linked worktrees; discards in a

temp-root repository outside the workspace need no toggle.

• destructive_command_protection and secret_protection: an enabled boolean, and per-rule

overrides mapping a built-in rule id (git.reset-hard, secret.basename.env) to "on" or "off". Get the id for a blocked command from the ruleId field of explain --json.

• destructive_command_protection.allow_paths: absolute or ~/ paths where recursive delete

targets are permitted. secret_protection.allow_paths: exact user-managed files or directories, or a folder followed by **/ and an exact file name (for example ~/code/**/.env.local; the folder cannot be home or above it), exempted from built-in secret patterns. Deny paths and Coding CLI protections still win. Other glob forms are rejected. secret_protection.deny_paths: extra paths protected like built-in secrets.

• audit.retention_days: days of audit history to keep, user scope only.