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 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:
  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

Ten 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. 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 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

Command Prompt rules

These rules judge the targets of rmdir, 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, the ruleId 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>".
Last modified on October 11, 2026