Core concepts
| Term | Definition |
|---|---|
| PreToolUse hook | The agent event that runs before a tool executes. CC Safety Net uses it, or each agent’s equivalent event, to check commands before they run. See How it works. |
| Fail-closed | Denying one tool call when CC Safety Net cannot reach a trustworthy verdict, instead of allowing it. See Security model. |
| Decision | The allow or deny outcome for one tool call, which the audit log records. See Audit log. |
| Segment | One command split from a compound command at &&, ||, |, ;, or a newline. If CC Safety Net blocks any segment, it denies the whole command. See How it works. |
| Analysis engine | The core that parses a command and decides whether to block it, shared by every agent integration. See How it works. |
| Integration model | How an agent runs CC Safety Net, such as a hook subprocess or an in-process plugin. See Integration models. |
Configuration
| Term | Definition |
|---|---|
| Policy | The settings file policy.json, by default ~/.cc-safety-net/policy.json, which holds the safety preset, capability overrides, worktree mode, protection switches, and audit retention. See Policy. |
| Project policy | The optional .cc-safety-net/policy.json in a project root, which sets only the fields it lists on top of the user policy. See Project policy. |
| Effective policy | The user policy with the project policy layered on top. See Policy. |
| Policy snapshot | The configuration CC Safety Net reads fresh on every tool call from the policy files, rule.json, and rulebooks. Its state is either ready or degraded. See Configuration recovery. |
| Preset | The safety.level value, standard, strict, or paranoid, that sets default capabilities. The effective level reads custom when overrides match no preset. See Modes. |
| Capability | One protection you can turn on or off separately from the preset: fail_closed, paranoid_rm, or paranoid_interpreters. See Modes. |
| Degraded | The state CC Safety Net enters when it rejects a configuration source and falls back to protective defaults while work continues. See Configuration recovery. |
Shell command forms
| Term | Definition |
|---|---|
| Shell wrapper | A shell command that runs another command, such as bash -c 'git reset --hard', which CC Safety Net unwraps and checks. See Blocked commands. |
| Interpreter one-liner | Inline code run by an interpreter, such as python -c 'import os; os.system("rm -rf /")', which CC Safety Net checks for dangerous patterns. See Blocked commands. |
| Dynamic substitution | A value that depends on runtime expansion, such as $(...), <(...), or $VAR, which some safety levels block. See Blocked commands. |
Recursive removal and paths
| Term | Definition |
|---|---|
| CWD self-target | A recursive rm target that is the working directory itself, such as rm -rf ., which every safety level blocks. See Blocked commands. |
| Effective cwd | The working directory CC Safety Net tracks across cd commands inside one compound command. See Filesystem commands. |
| Within-cwd target | A recursive rm or find -delete target inside the working directory, which CC Safety Net allows by default and the paranoid_rm capability blocks. See Filesystem commands. |
Modes
| Term | Definition |
|---|---|
| Strict mode | The strict preset, which denies commands that CC Safety Net cannot safely analyze. See Modes. |
| Paranoid mode | The paranoid preset, which adds stricter rm and interpreter checks on top of strict. See Modes. |
| Worktree relaxation | Worktree mode’s allowance for selected local Git discard commands inside a confirmed linked Git worktree. See Modes. |
Rules
| Term | Definition |
|---|---|
| Rulebook | A JSON file of custom blocking rules at rules/<name>/rulebook.json, that rule.json lists as a source and CC Safety Net reads on every tool call. See Custom rules. |
| Transparent wrapper | A command such as nohup or timeout that CC Safety Net looks through to check the command it runs. You declare extra wrappers in rule.json. See Transparent wrappers. |
| Vendored rulebook | The local copy of a remote rulebook that rule add and rule update write into your repository, so a diff shows what an update changed. See Official rulebooks. |