Skip to main content
Degraded means CC Safety Net rejected part of your configuration, such as a rulebook with a JSON error or a policy.json field with a wrong value. It keeps working with what it could load. That reduced set is the fallback configuration: every valid part of your files, built-in defaults in place of rejected policy.json fields, and every built-in protection. doctor reports this state as “Runtime is enforcing a fallback configuration”, and the dashboard banner says “A fallback configuration is being enforced”. The doctor finding names each rejected file and field. Fix them with the steps below. A rejected rulebook stops blocking until you fix it. A rejected policy.json field falls back to a default that usually blocks more than you configured.

​
Configuration states

A single warning is enough to move the runtime to degraded:
  • An error names a source that CC Safety Net dropped. That source contributes no rules at all.
  • A warning names a source that stays active. CC Safety Net ignores only the rejected part.

​
Invalid configuration behavior

An invalid configuration never blocks ordinary work on its own, and CC Safety Net never enforces the rejected part.
  • CC Safety Net drops a rule source it cannot verify, and that source’s rules stop applying.
  • Every other verified scope keeps enforcing its rules.
  • Every built-in protection keeps applying. Destructive-command rules, secret protection, policy.json protection, and Git metadata protection do not read rule configuration.
  • An invalid policy.json keeps its valid fields and uses built-in defaults for the rest. See Salvaged policy.json or protective defaults.
The degraded state allows nothing extra, and there is no recovery mode. Reading or editing rule.json and running cc-safety-net rule update are ordinary tool calls, so your agent can repair rule configuration itself.
Dropping a source is not security-neutral. It removes the denials that source contributed, so a command you deliberately blocked in a dropped rulebook can run again until you repair it. Never assume a rulebook named in an error is still protecting you.
A blocked command with a “failed closed” reason is a different case. It means CC Safety Net could not finish analyzing that one command. See Fail-closed enforcement.

​
Configuration fallback matrix

​
Errors that drop the source

Every one of these messages names the file or source it rejected and the repair that fits it. A missing rulebook for a remote source ends with run `cc-safety-net rule update` to vendor <source>. A missing rulebook for a local source ends with create that file or remove that source from the rules config. An invalid rulebook and a name mismatch both end with fix that file.

​
Warnings that keep the source active

See Scope merge behavior for how duplicate names resolve.

​
Salvaged policy.json or protective defaults

CC Safety Net salvages a file it can parse as a JSON object. Each valid field stays, and each invalid field falls back as the second table shows. CC Safety Net replaces any other broken user file with protective defaults, which are the built-in defaults with both protections on, no overrides, and no allow or deny paths. The runtime never rewrites policy.json. Fix it by hand, or use the repair action in the dashboard.

​
Coverage declared in rule.json

transparent_wrappers and command_tools widen what built-in analysis reaches, and both live in rule.json, not in a rulebook.
  • A dropped rulebook keeps both fields, because rule.json itself is still readable.
  • An unreadable rule.json loses both for that scope. Analysis stops looking through that scope’s wrapper commands, and CC Safety Net no longer analyzes the community shell tools it declared. The eight built-in wrappers (caffeinate, exec, nice, nohup, setsid, stdbuf, time, timeout) need no file and still apply, and so do the other scope’s declarations.
This is the one case where rejected configuration reduces built-in coverage rather than only removing your own rules. When an unreadable rule.json drops a scope, repair that file first.

​
Degraded-state reporting

doctor is the only command that reports both rule configuration and policy.json. Diagnostics name the rejected file and the problem but never copy its contents, so they never repeat a secret inside a broken file.

​
Visible and silent failures

  • A dropped rule source is quiet. It removes denials, so nothing in the session blocks or warns you. Run cc-safety-net status after any change to rule configuration and after every upgrade.
  • An unmigrated legacy rule file is quieter. CC Safety Net does not load it and the state stays ready, while those rules protect nothing. doctor reports config.legacy-ignored. See Migrate legacy configuration.
  • An invalid policy.json field is usually visible. Protections fall back to on, so you see more denials than you configured.
  • Two policy.json mistakes lower protection silently. An invalid safety.level falls back to standard, so a typo in paranoid lowers your preset. CC Safety Net drops an invalid deny_paths entry, so it stops protecting that location.
  • Only the status line marker appears without you doing anything. The Config warning: line needs an unrelated denial to appear on, and every other surface waits for you to run a command or open the dashboard.

​
Recover configuration

Your agent can run each command below, even while the runtime is degraded. The CLI reference has the options and exit codes.
1

Check the verdict

It prints ready or degraded, plus one line per diagnostic under Not active. See status.
2

Get the full report

It covers both rule configuration and policy.json. The config.runtime-degraded finding names every rejected source. See doctor.
3

Check rule configuration

rule list shows which rules are active, so you can see what a dropped source took with it. rule verify checks both rule.json files the way the runtime loads them and ends with Config validation failed. when something is broken. See rule verify.
4

Repair the source

For a local rulebook, edit the file the diagnostic names. The runtime reads it on the next tool call.For a remote source that is missing or stale, vendor it again:
Add a source name to update only that one, and --global for the user scope. It reports any diagnostic that remains instead of claiming success. See rule update.
5

Fix policy.json yourself

Your agent cannot edit policy.json. Correct the fields named in the diagnostic, or use the repair action in the dashboard. See Edit the policy file.
Run status again after each repair. The runtime reloads on the next tool call, so there is nothing to restart.

Policy

The complete policy.json contract and defaults.

Custom rules

Rulebook layout, sources, vendoring, overrides, and transparent wrappers.

CLI commands

Full options and exit behavior for status, doctor, and every rule subcommand.

Audit log

Where decisions are recorded, the entry schema, and retention.
Last modified on October 22, 2026