Skip to main content
CC Safety Net ships with sensible defaults but provides three operation modes via environment variables that let you tune its behavior to your workflow. You can enable any combination of modes by exporting the corresponding variables before starting your AI coding agent.
Mode and debug flags use CC_SAFETY_NET_* environment variables. Older SAFETY_NET_* names (without the CC_ prefix) are also accepted for strict, paranoid, paranoid-rm, paranoid-interpreters, and worktree toggles. See the environment variable reference for the full list, including CC_SAFETY_NET_DEBUG and CC_SAFETY_NET_HOME.

​
Default Mode

No environment variables are required to get started. In default mode, CC Safety Net protects against all built-in destructive git and filesystem patterns. This is the recommended starting point for most users. Most malformed input is already handled safely regardless of mode:
  • Invalid hook input JSON is always blocked (fail-closed), in every mode.
  • If the analyzer itself throws an unexpected error, the command is always blocked (fail-closed) with a “failed closed” reason, in every mode.
  • If a command cannot be tokenized by the shell parser (for example, an unterminated quote), CC Safety Net runs a fallback text scan for known-dangerous patterns. If the scan matches, the command is blocked; if it does not match, the command is allowed through (fail-open). Strict mode changes only this last case.

​
Strict Mode (CC_SAFETY_NET_STRICT=1)

When strict mode is enabled, CC Safety Net switches to fail-closed behavior on commands that cannot be tokenized by the shell parser. Any command the parser cannot split into tokens is blocked rather than allowed, even if the fallback text scan finds no dangerous pattern. Note that invalid hook input JSON and analyzer exceptions are already fail-closed in every mode — strict mode only tightens the unparseable-command case described above. How to enable: 
export CC_SAFETY_NET_STRICT=1
When to use: Enable strict mode when you want maximum protection and can tolerate occasional false positives on unusual or exotic command syntax.

​
Paranoid Mode (CC_SAFETY_NET_PARANOID=1)

Paranoid mode enables additional safety checks that go beyond the defaults. These checks may be disruptive to some normal workflows, so they are opt-in. You can enable all paranoid checks at once, or activate individual checks selectively.

​
rm check (CC_SAFETY_NET_PARANOID_RM=1)

By default, rm -rf within the current working directory is allowed — the assumption is that deleting files inside your own project root is intentional. With the paranoid rm check enabled, all non-temp rm -rf commands are blocked, including those targeting paths inside the cwd.

​
Interpreter one-liners (CC_SAFETY_NET_PARANOID_INTERPRETERS=1)

Interpreter one-liners can hide destructive commands inside strings that are hard to inspect statically. With this check enabled, the following forms are blocked entirely:
  • python -c '...'
  • node -e '...'
  • ruby -e '...'
  • perl -e '...'
How to enable all paranoid checks at once: 
export CC_SAFETY_NET_PARANOID=1
How to enable individual paranoid checks: 
export CC_SAFETY_NET_PARANOID_RM=1
export CC_SAFETY_NET_PARANOID_INTERPRETERS=1
Setting CC_SAFETY_NET_PARANOID=1 is equivalent to enabling both CC_SAFETY_NET_PARANOID_RM=1 and CC_SAFETY_NET_PARANOID_INTERPRETERS=1 simultaneously.

​
Worktree Mode (CC_SAFETY_NET_WORKTREE=1)

Linked git worktrees are designed as disposable, isolated workspaces. Discarding changes inside one does not risk the main working tree, making the usual local-discard restrictions unnecessarily strict in that context. Worktree mode relaxes those rules — but only when CC Safety Net can positively confirm that the current working directory is inside a linked worktree. How to enable: 
export CC_SAFETY_NET_WORKTREE=1

​
What’s allowed inside a linked worktree

When worktree mode is active and the cwd is confirmed to be a linked worktree, the following commands are permitted:
  • git restore <file> and git restore --worktree <file>
  • git checkout -- <file>, git checkout <ref> -- <file>, git checkout --force, and ambiguous multi-positional checkout forms
  • git reset --hard and git reset --merge
  • git clean -f (and combined short flags like -fd)
  • git switch --discard-changes and git switch -f / --force

​
What remains blocked even in worktrees

These commands affect shared refs or other worktrees and are never relaxed, regardless of worktree mode:
  • git push --force — affects the remote
  • git branch -D — force-deletes a branch that is shared across worktrees
  • git stash drop / git stash clear — the stash is shared across worktrees
  • git worktree remove --force — could delete another worktree

​
Detection and fail-closed behavior

Worktree detection is fail-closed: if CC Safety Net cannot positively identify the cwd as a linked worktree, the stricter default rules remain in effect. Specifically:
  • A linked worktree is identified by a .git file (not a directory) whose resolved git directory contains a commondir file. Main worktrees and submodules are not relaxed.
  • The cwd walk uses realpath so symlinked paths resolve correctly.
  • git -C <path> arguments are honored; unresolved targets keep the command blocked.
  • Relaxation is disabled if --git-dir / --work-tree is passed, or if GIT_DIR / GIT_WORK_TREE / GIT_COMMON_DIR / GIT_INDEX_FILE is set in the environment.
  • Certain local discards are never relaxed even inside a confirmed worktree: commands with dynamic arguments containing $, *, ?, or [; forced branch resets (git checkout -B/-Bf or git switch -C/-Cf with -f or --discard-changes); git clean with more than one -f; and any command using --recurse-submodules (or a recursive-submodule config).

​
Summary

VariableEffect
CC_SAFETY_NET_STRICT=1Fail-closed on unparseable commands
CC_SAFETY_NET_PARANOID=1All paranoid checks (rm + interpreters)
CC_SAFETY_NET_PARANOID_RM=1Block rm -rf even within cwd
CC_SAFETY_NET_PARANOID_INTERPRETERS=1Block interpreter one-liners
CC_SAFETY_NET_WORKTREE=1Relax local-discard rules in linked worktrees
You can check which modes are currently active by running npx cc-safety-net doctor or by looking at the status line in Claude Code. See Status Line for setup instructions.