Skip to main content
CC Safety Net reads its settings from policy.json, rule.json, and the CC_SAFETY_NET_* environment variables on this page. Set a variable in your shell or your agent’s launch environment before you start the agent. An environment variable can raise your safety level but never lower it. Older SAFETY_NET_* names without the CC_ prefix still work where the tables list them. For what each level blocks, see Modes. For the policy file, see Policy.

​
Where configuration lives

Project paths are relative to the directory the agent session runs in. See config working directory. CC_SAFETY_NET_HOME helps when an agent runs with a different home directory than your shell, as in a sandbox. It moves the user scope only. Project files always resolve from the project. It does not move the audit log. Audit log explains how to move that. CC Safety Net protects only policy.json from the agent. rule.json and rulebooks are ordinary files an agent can edit.

​
Safety level

Each preset turns on a set of three capabilities: fail_closed, paranoid_rm, and paranoid_interpreters. See Modes for what each one blocks. CC Safety Net ignores any other value, keeps the level from policy.json, and always prints this warning on stderr:
An empty value counts as unset and prints no warning.

​
Capability toggles

These older per-capability flags only raise their capability. A falsy value does not turn a capability off. To turn a capability off below its preset, use safety.overrides in policy.json. A flag is on when set to 1 or true, in any case. When a CC_SAFETY_NET_* name is set, it wins, and CC Safety Net reads the SAFETY_NET_* alias only when the prefixed name is absent.

​
Precedence

CC Safety Net combines policy and environment in a fixed order:
  1. Preset. safety.level in policy.json supplies the inherited capability defaults. When the field is absent, the preset is standard.
  2. CC_SAFETY_NET_LEVEL. The effective base level is the higher of the policy level and the environment level. The environment can raise the level but never lower it.
  3. safety.overrides.*. Explicit capability overrides in policy.json can then set fail_closed, paranoid_rm, or paranoid_interpreters to true or false.
  4. Capability toggles. CC Safety Net applies the CC_SAFETY_NET_STRICT, CC_SAFETY_NET_PARANOID, CC_SAFETY_NET_PARANOID_RM, and CC_SAFETY_NET_PARANOID_INTERPRETERS flags last. These flags are monotonic. Each one forces its capability to true, and none can turn a capability off.
  5. Worktree mode is the logical OR of workflow.worktree_mode and CC_SAFETY_NET_WORKTREE.
CC Safety Net derives the reported effective level from the resulting capability values. It reports a combination that matches no preset as custom, for example paranoid_rm on with fail_closed off. CC Safety Net applies per-rule entries in destructive_command_protection.overrides on top of the state the capabilities set. Catastrophic rules always apply, and none of the above can disable them.

​
Project policy weakenings

Without the switch, a project safety.overrides entry can turn off a capability that CC_SAFETY_NET_LEVEL enables, because overrides apply after the level (step 3 above). The capability toggles apply last, so a project file never turns them off. See Ignore project weakenings for the fields the switch drops.

​
Audit scope

The audit log always records denials. See Audit scope for what an invalid value does.

​
Debug output

Use it when you investigate why a command was allowed or when you file a bug report. It does not change what the audit log records.

​
Update-check opt-out

It does not affect the update check that doctor and the dashboard run. See rule doc update notice for the notice it prints.

​
Check your active configuration

status shows the effective level and any problems. The Environment section of doctor lists each variable, its value, and any legacy SAFETY_NET_* name in use.
Last modified on October 22, 2026