Skip to main content
Destructive-command protection is the command-analysis stage that blocks commands which can destroy uncommitted work, stashed changes, remote history, other data, or a disk. Every block names one of the rule ids below in the block message, the audit log, and the 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 59 registered rules. Six are catastrophic and cannot be turned off. Every other rule accepts a per-rule override.

Allow a built-in rule

The same three steps apply to every non-catastrophic rule:
  1. Get the rule id. It is printed in the block message, or run explain on the exact command and read ruleId:
  2. Add the id to destructive_command_protection.overrides with the value "off" in policy.json. The user file applies to every project, and the project file .cc-safety-net/policy.json applies to one. Merge into the file you already have; this is a complete example:
  3. Confirm with explain again. The verdict for the command becomes allowed, and status lists the override.
An override turns the whole rule off, not one command. "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

Six rules are marked catastrophic. They ignore destructive_command_protection.enabled: false and ignore an "off" override, so they block at every safety level under every policy. They cover recursive removal of / or your home directory and deletion of Git metadata, in rm, find, and PowerShell form. 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 a safety.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

Execution rules

Last modified on September 17, 2026