Skip to main content
CC Safety Net reads its configuration from policy.json and environment variables. Mode toggles use the CC_SAFETY_NET_* prefix. Older SAFETY_NET_* names without the CC_ prefix remain as legacy aliases where noted. Set variables in your shell or your agent’s launch environment before you start the agent. This page is the reference for the variables themselves and for how they combine with policy.json. For what each level blocks, see Modes; for the full policy file contract, see Policy.

​
Safety level

The three presets expand into the same three capabilities — fail_closed, paranoid_rm, and paranoid_interpreters. See Modes for what each preset blocks and what each capability changes. Any value other than standard, strict, or paranoid is ignored and the level configured in policy.json is used unchanged. The rejected value is always reported on stderr — no debug flag is required:
The reported value is truncated to its first 40 characters. An empty value is treated as unset and produces no warning.

​
Capability toggles

These are the legacy per-capability flags. Each one only raises its capability — setting a flag to a falsy value does not turn a capability off. Use safety.overrides in policy.json when you need to turn a capability off below its preset. Boolean flags are truthy when set to 1 or true (case-insensitive). When a CC_SAFETY_NET_* name is set it wins; the SAFETY_NET_* alias is only consulted when the prefixed name is absent.

​
Precedence

Policy and environment are combined 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 then set fail_closed, paranoid_rm, or paranoid_interpreters in either direction — up or down.
  4. Capability toggles. The CC_SAFETY_NET_STRICT, CC_SAFETY_NET_PARANOID, CC_SAFETY_NET_PARANOID_RM, and CC_SAFETY_NET_PARANOID_INTERPRETERS flags are applied last and are monotonic — each forces its capability to true and none of them can turn a capability off.
  5. Worktree mode is the logical OR of workflow.worktree_mode and CC_SAFETY_NET_WORKTREE.
The reported effective level is derived from the resulting capability triple. A combination that matches no preset — for example paranoid_rm on with fail_closed off — is reported as custom. Per-rule entries in destructive_command_protection.overrides are applied on top of the capability-derived state. Catastrophic rules are always enforced and cannot be disabled by any of the above.

​
Audit scope

  • all (the default, and the behavior when the variable is unset) records both allowed and blocked command decisions.
  • blocked is the privacy-minimizing setting: only denials are recorded.
  • Denials are never suppressed by this setting.
  • Any other value falls back to denials-only recording, and doctor reports it as the warning finding environment.audit-scope-invalid.
Allowed decisions are recorded only when the tool call routed to a command; allowed non-command tool calls produce no record.

​
Debug output

CC_SAFETY_NET_DEBUG does not change which decisions are recorded — that is CC_SAFETY_NET_AUDIT_SCOPE. Use it when investigating why a command was allowed or when filing a bug report. The doctor command reports whether it is set.

​
Configuration directory override

When set, policy.json is read from <path>/policy.json, user-scope rulebook config from <path>/rules/, and the rulebook lock and cache from that same tree. This is useful in sandboxed or non-standard HOME setups, for example when an agent runs with a different home directory than your shell.
CC_SAFETY_NET_HOME does not relocate the audit log. The audit root resolves independently — see Audit log for how it is derived.

​
Update-check opt-out

rule doc normally checks for a newer release at most once every 24 hours: it polls https://registry.npmjs.org/cc-safety-net/latest, caches the result in $HOME/.cc-safety-net/update-check.json, and prints an UPDATE_AVAILABLE: line on stderr when a newer version exists. That poll is the only outbound network request the CLI makes during rule doc. When CC_SAFETY_NET_NO_UPDATE_CHECK is set, the check is skipped entirely: no registry poll, no cache write, and no UPDATE_AVAILABLE: line. It does not affect the separate update check that doctor and the dashboard run.

​
Check your active configuration

Run status for a quick check, or run doctor for the full report:
The Environment section of the doctor report lists each variable, its value, its default behavior, and any legacy SAFETY_NET_* name that is in use. See CLI commands for the full syntax and output of both commands, and Status line for the at-a-glance indicator in Claude Code.
Last modified on August 11, 2026