ruleId field of explain --json.
This page lists every built-in rule id, what it blocks, and when it is active. Use it to look up a rule from a block message and decide whether to turn it off. See Blocked commands for the boundary of each rule with worked examples, Policy for the destructive_command_protection schema, and Custom rules to add rules of your own.
There are 70 registered rules. Ten are catastrophic and cannot be turned off. Every other rule accepts a per-rule override. A deny that no rule produced carries one of the fixed denial ids instead, and no override can turn those off.
Allow a built-in rule
The same three steps apply to every non-catastrophic rule:-
Get the rule id. It is printed in the block message, or run
explainon the exact command and readruleId: -
Add the id to
destructive_command_protection.overrideswith the value"off"inpolicy.json. The user file applies to every project, and the project file.cc-safety-net/policy.jsonapplies to one. Merge into the file you already have; this is a complete example: -
Confirm with
explainagain. The verdict for the command becomes allowed, andstatuslists the override.
"on" does the opposite and enables a rule that your safety level leaves off, such as rm.recursive-force-paranoid in standard mode. A path-specific exemption for recursive deletes is destructive_command_protection.allow_paths, described under Allow paths. An unregistered id is rejected by policy check.
Catastrophic rules
Ten rules are marked catastrophic. They ignoredestructive_command_protection.enabled: false and ignore an "off" override, so they block at every safety level under every policy. Eight cover recursive removal of / or your home directory and deletion of Git metadata, in rm, find, PowerShell, and cmd form. The other two cover recursive deletes whose targets cannot be read safely: a cmd delete whose quoting can split the target so that one piece names the drive root, and a recursive delete handed to powershell or pwsh in a form the analyzer does not read. They are marked Catastrophic in the tables below.
Reading the tables
Active when says which safety level or capability turns the rule on. All levels means standard, strict, and paranoid. A rule tied to a capability is on whenever that capability is on, whether the safety level or asafety.overrides entry set it. The examples are the shortest command that fires the rule; the Blocked commands reference shows where each boundary falls.
Git rules
Filesystem rules
PowerShell rules
Command Prompt rules
These rules judge the targets ofrmdir, rd, del, and erase with an /s switch inside a cmd /c or cmd /k body. Command Prompt bodies explains how the body is read.
Execution rules
Fixed denial ids
Some denials do not come from any rule. They come from the guards that run before command analysis, from analysis limits and failures, and from unusable working directories. Each carries a fixed id in the block message, the audit log, theruleId field of explain --json, and the ruleId of a checkCommand deny. These ids are not registered rules, so destructive_command_protection.overrides cannot name them. policy check rejects each one with unknown destructive command rule id "<id>".