standard、strict、paranoid の 3 つの安全レベルに解決します。各レベルは同じ 3 つの機能に展開される preset です。したがって、レベルは別の code path ではなく短縮指定です。
policy.json の safety.level または環境変数 CC_SAFETY_NET_LEVEL でレベルを設定します。有効な基本レベルには、2 つのうち高い方を使用します。このページで説明する個別の toggle は、その基本レベルに 1 つの機能を追加します。3 つの preset のどれとも正確に一致しない機能の組み合わせは、有効レベル custom として報告されます。
既定モード
既定モードはstandard 安全レベルです。開始時に環境変数は不要です。CC Safety Net は、組み込みの破壊的な Git およびファイルシステム pattern から保護します。多くのユーザーには、このレベルから始めることを推奨します。
一部の失敗は、すべてのレベルで同じ方法で処理します。
- 無効な hook 入力 JSON は、すべてのモードで常にブロック（fail-closed）します。
- analyzer 自身が予期しない error を throw した場合、すべてのモードで “failed closed” の理由を付けてコマンドを常にブロック（fail-closed）します。
- parser の再帰上限または構造検証上限を超えるコマンドは、すべてのモードで常にブロックします。この resource-exhaustion 上限は、standard レベルでも緩和しません。
- shell parser がコマンドを token に分割できない場合（例えば、閉じていない quote）、CC Safety Net は既知の危険な pattern を fallback text scan で確認します。一致した場合はブロックします。一致しない場合はコマンドを許可します。したがって、
echo 'unterminatedは許可されますが、git reset --hard 'unterminatedは heuristic scan で引き続きブロックされます。 - standard は動的な再帰削除対象を一律にブロックしません。 ここでは
rm -rf "$target"を許可し、fail-closed 機能が有効になった場合にのみブロックします。
policy.json）を緩和することはありません。
Strict モード（CC_SAFETY_NET_STRICT=1）
Strict モードは fail_closed 機能を有効にします。解析不能なコマンドだけではなく、次の 5 つを厳しくします。
- 解析不能なコマンドをブロックします。 fallback text scan が危険な pattern を検出しない場合でも、parser が token に分割できないコマンドを “Command could not be safely analyzed (strict mode)” で拒否します。
echo 'unterminatedは standard で許可され、ここではブロックされます。 - Heredoc は fail-closed です。 heredoc が 1 つだけで、stdin にあり、delimiter が quote され、他の入力 redirection がなく、consumer が literal の
cat、tee、git apply、git commit、gh pr create、gh issue createのいずれかでない限り、heredoc を含むコマンドを拒否します。したがって、python3 - <<'PY'と quote されていない<<EOFはここで拒否されますが、git commit -F - <<'EOF'は許可されます。正確な gate については、heredoc 解析を参照してください。 - 次の 5 つのルールで、検証不能な破壊的対象をブロックします。
- メタデータだけの機密パス検出をブロックします。
test -f ~/.ssh/id_rsaとfind ~/.ssh -type fは standard で許可され、strict で拒否されます。 - standard 専用の inline-data 緩和を無効にします。 standard では、上限付き lexical scan がファイルシステムまたはコマンド実行 marker を検出しない場合、Node または Bun inline evaluation 内の機密パス literal を不活性な診断 data として扱います。Strict はこの緩和を削除します。
fail_closed が有効な場合にのみ動作します。
無効な hook 入力 JSON、analyzer の例外、parser の resource-limit failure は、すべてのモードですでに fail-closed です。strict が追加する動作ではありません。
strict 安全レベルを有効にする
CC_SAFETY_NET_STRICT=1 も同じ機能を設定し、引き続き使用できます。
strict 安全レベルを使用する場合
コマンドが敵対的または信頼できない状況から来る可能性がある場合は、strict モードを有効にします。最大の保護が必要で、一般的でないコマンド構文に対する誤検知を許容できる場合にも使用できます。policy.json の
destructive_command_protection.overrides で、個別の strict-tier ルールを無効にできます。また、"on" override を使用すると、standard で任意の strict-tier ルールを強制的に有効にできます。parser の fail-closed や機密パスの結果など、破壊的コマンドの rule id がない fail-closed 結果については、Strict は引き続き strict です。Paranoid モード（CC_SAFETY_NET_PARANOID=1）
paranoid レベルは strict に 2 つの機能、paranoid_rm と paranoid_interpreters を追加します。これらの確認は通常のワークフローを妨げる場合があるため、opt-in です。レベル全体を選択するか、個別の機能を有効にできます。片方だけを持つレベルは、有効レベル custom として報告されます。
rm チェック（CC_SAFETY_NET_PARANOID_RM=1）
既定では、現在の作業ディレクトリ内の rm -rf を許可します。自身のプロジェクト root 内にあるファイルの削除は意図的であると仮定します。paranoid rm チェックを有効にすると、現在の作業ディレクトリ内でも、一時パス以外の再帰強制削除をブロックします。rm -rf ./cache は rm.recursive-force-paranoid に一致し、PowerShell の同等コマンド Remove-Item ./cache -Recurse -Force は powershell.remove-item-recursive-force-paranoid に一致します。
このチェックでも、一時対象と destructive_command_protection.allow_paths に指定したディレクトリは許可されます。
Interpreter の 1 行コード（CC_SAFETY_NET_PARANOID_INTERPRETERS=1）
Interpreter の 1 行コードは、静的な検査が難しい文字列内に破壊的コマンドを隠すことができます。paranoid より下では、body に危険なコマンドを含む 1 行コードだけをブロックします（ルール interpreter.dangerous-command）。このチェックを有効にすると、内容に関係なく、interpreter.one-liner-paranoid によってすべての interpreter 1 行コードをブロックします。
python -c '...'（python3とpython2も含む）node -e '...'ruby -e '...'perl -e '...'
python -c "print(1)" は standard と strict で許可され、ここではブロックされます。
paranoid 安全レベルを有効にする
fail-closed 動作なしで両方の paranoid チェックを有効にする
個別の paranoid チェックを有効にする
CC_SAFETY_NET_PARANOID=1 の設定は、CC_SAFETY_NET_PARANOID_RM=1 と CC_SAFETY_NET_PARANOID_INTERPRETERS=1 の両方を有効にすることと同じです。fail_closed は有効にしません。そのため、既定の standard レベルに追加すると、有効レベルは paranoid ではなく custom になります。完全な preset が必要な場合は、CC_SAFETY_NET_LEVEL=paranoid（または safety.level: "paranoid"）を使用します。
Worktree モード（CC_SAFETY_NET_WORKTREE=1）
Linked Git worktree は、隔離された workspace を提供できます。Worktree モードは、現在の作業ディレクトリが linked worktree 内にあると CC Safety Net が確認した場合にのみ、選択したローカル破棄ルールを緩和します。
worktree モードを有効にする
workflow.worktree_mode: true を設定することもできます。2 つは論理 OR で組み合わせます。どちらか一方で worktree モードが有効になります。
linked worktree 内で許可するコマンド
worktree モードが有効で、cwd が linked worktree であると確認できた場合は、次のコマンドを許可します。git restore <file>とgit restore --worktree <file>git checkout -- <file>、git checkout <ref> -- <file>、git checkout --force、および複数の positional argument を持つ曖昧な checkout 形式git reset --hardとgit reset --mergegit clean -f（-fdなど、組み合わせた short flag を含む）git switch --discard-changesとgit switch -f / --force
linked worktree 内でもブロックするコマンド
次のコマンドは共有 ref または他の worktree に影響するため、worktree モードに関係なく決して緩和しません。git push --force— remote に影響するgit branch -D— worktree 間で共有する branch を強制削除するgit stash drop/git stash clear— stash は worktree 間で共有されるgit worktree remove --force— 別の worktree を削除する可能性がある
linked worktree の検出
Worktree 検出は fail-closed です。CC Safety Net が cwd を linked worktree と明確に特定できない場合、厳しい既定ルールを引き続き使用します。具体的な条件は次のとおりです。- Linked worktree は、解決後の Git directory に
commondirファイルがある.gitファイル（directory ではない）で識別します。main worktree と submodule は緩和しません。 - cwd の上方向への走査は
realpathを使用するため、symlink path を正しく解決します。 git -C <path>の引数を適用します。対象を解決できない場合、コマンドはブロックされたままです。--git-dir/--work-treeを渡した場合、または環境にGIT_DIR/GIT_WORK_TREE/GIT_COMMON_DIR/GIT_INDEX_FILEがある場合、緩和を無効にします。- 確認済み worktree 内でも、一部のローカル破棄は緩和しません。
$、*、?、[を含む動的引数を持つコマンド、branch の強制 reset（git checkout -B/-Bfまたは、-fや--discard-changesを使用するgit switch -C/-Cf）、複数の-fを持つgit clean、および--recurse-submodules（または recursive-submodule 設定）を使用するコマンドが対象です。
安全レベルのまとめ
Worktree モードはレベルから独立しています。確認済み linked worktree 内のローカル破棄ルールを緩和します。
レベルを選択または機能を強制するすべての変数、以前の
SAFETY_NET_* alias、および policy.json と環境の完全な優先順位については、環境変数を参照してください。