The lifecycle of one tool call
1
Your agent prepares a tool call
The agent decides to run something — a shell command such as
git reset --hard, or a file write, edit, search, or patch — and hands it to its tool layer.2
The integration intercepts it
CC Safety Net’s integration for that agent receives the call before the tool executes and before the operating system ever sees it. Some agents call CC Safety Net as a short-lived subprocess hook; others load it in-process as a plugin or extension. Either way the same guard runs. See Integration architecture for which agent uses which model.
3
CC Safety Net checks the operation
CC Safety Net reads the tool input with limits on its depth, size, and number of fields. It parses the input once, then runs the fixed sequence in What gets checked, in order. The order does not depend on the agent.
4
An allow or a block comes back
A safe call is allowed and executes normally. A blocked call never runs; the agent receives a block message naming the reason, the offending command, and what it should do next. See What a block looks like.
5
The decision can be audited
Denials are appended to the local audit log. Eligible allowed command decisions are also logged when the configured audit scope includes them. See The audit record.
What gets checked, in order
Every tool call runs through the same stages, in this order:- Bounded input extraction. The command is read out of the tool input under traversal limits on depth, node count, key count, and size. Exceeding a limit blocks the call rather than risking an unbounded walk.
- A single parse. The command is parsed once into structural facts that every later stage reuses. Exhausting a parser budget blocks the call — in every safety level.
- Policy-file protection. Anything that would modify or delete CC Safety Net’s own
policy.json, its directory, or an ancestor is stopped outright. - Git-metadata protection. Anything that would delete, move, overwrite, or patch your repository’s
.gitmetadata or hooks directory is stopped outright — including from inside the working directory. - Configuration load. Your policy, rulebooks, and safety level are resolved.
- Sensitive-path protection. Commands, paths, searches, and patches are checked against built-in sensitive locations (
.env,~/.ssh, cloud and coding-CLI credential files) and any deny paths you configured. - Destructive-command analysis. The command is split into segments, wrappers and interpreters are unwrapped, and each segment is classified by the analyzer that understands it —
git,rm,Remove-Item,find,xargs,parallel, the device commands, and your custom rules.
Why intent, not string matching
CC Safety Net analyzes what a command does, not what it looks like. It parses the executable, subcommand, flags, and arguments. The analyzer for that executable applies its option grammar.
Both begin with
git checkout. A simple prefix rule cannot distinguish these outcomes without duplicating Git option logic. Structural analysis also handles reordered flags (rm -r -f /), shell wrappers (sh -c "rm -rf /"), and interpreter one-liners (python -c 'import os; os.system("rm -rf /")'). CC Safety Net unwraps and re-analyzes nested commands up to 10 levels deep.
This page does not list every rule. See Blocked commands for the full behavior matrix of what is stopped, and Allowed commands for what deliberately is not.
What a block looks like
The agent receives the block message as the tool result:Rule: id, the Tool: name, the specific Segment: that triggered the block, and a Config warning: if a fallback configuration is in force. Command and segment text is excerpted, and everything in the message is secret-redacted before it leaves the process.
A block does not end the agent session. The message arrives as a normal tool result and directs the agent back to the task instead of retrying variants. The rule’s intent selects the closing instruction:
Why the messages are written this way — and why the instruction is advisory while enforcement stays with the guard — is covered in Design principles.
The audit record
CC Safety Net always records denials in a local audit log. It records allowed command decisions by default. Read the log with:When a decision surprises you
1
Ask why
npx cc-safety-net explain "<command>" replays the analysis for a command and shows which rule matched and why. Add --json for the structured trace.2
Check that protection is actually in force
npx cc-safety-net status prints ready or degraded in one screen, and lists anything that is not enforced — including a disabled Claude Code plugin — under Not active. degraded means a configuration source was rejected and a fallback is being enforced — see Configuration recovery for what is and is not active, and how to repair it. npx cc-safety-net doctor gives the full report.3
Adjust or report
If the block is correct but too strict for your workflow, change your safety mode or add a per-rule override. If a safe command is blocked, or a destructive one was not, see Troubleshooting and the security policy for where to report it.