Skip to main content
CC Safety Net は、policy.json と環境変数から設定を読み取ります。モードのトグルには CC_SAFETY_NET_* というプレフィックスを使います。CC_ プレフィックスのない古い SAFETY_NET_* という名前も、以降で明記した箇所では以前からのエイリアスとして使用できます。変数は、エージェントを起動する前にシェルまたはエージェントの起動環境で設定してください。 このページでは、各変数と policy.json との優先順位を説明します。各レベルがブロックする内容は安全レベル、ポリシーファイルの仕様はポリシーを参照してください。

安全レベル

3 つの preset は、いずれも同じ 3 つの機能(fail_closedparanoid_rmparanoid_interpreters)に展開されます。各 preset がブロックする内容と各機能の効果は、安全レベルを参照してください。 standardstrictparanoid 以外の値は無視され、policy.json で設定したレベルがそのまま使われます。無視された値は常に標準エラー出力へ書き出されます。デバッグ用のフラグは必要ありません。
出力される値は、先頭 40 文字までに切り詰められます。空の値は未設定として扱われ、警告も表示されません。

機能トグル

次の変数は、機能ごとの旧来のフラグです。いずれも機能を有効にする方向にしか働きません。偽と解釈される値を設定しても、機能は無効になりません。preset より機能を減らすには、policy.jsonsafety.overrides を使ってください。 この表のほかのフラグは、保護を強める方向にしか働きません。CC_SAFETY_NET_WORKTREE だけが例外です。worktree モードを有効にして、確認済みの linked worktree 内ではローカルの変更を破棄する Git ルールを緩和します。 真偽値のフラグは、1 または true(大文字と小文字は区別しない)を設定すると真になります。CC_SAFETY_NET_* の名前が設定されていればそちらが優先され、プレフィックス付きの名前がない場合にかぎり SAFETY_NET_* のエイリアスを参照します。

優先順位

ポリシーと環境変数は、次の決まった順序で組み合わされます。
  1. preset。 policy.jsonsafety.level が、機能の既定値を決めます。このフィールドがない場合、preset は standard です。
  2. CC_SAFETY_NET_LEVEL 実際に適用される基本レベルは、ポリシー側と環境変数側のうち高い方です。環境変数はレベルを引き上げられますが、引き下げることはできません。
  3. safety.overrides.* 続いて、policy.json の明示的な機能 override が、fail_closedparanoid_rmparanoid_interpreters を上下どちらの方向にも設定します。つまり、引き上げも引き下げもできます。
  4. 機能トグル。 CC_SAFETY_NET_STRICTCC_SAFETY_NET_PARANOIDCC_SAFETY_NET_PARANOID_RMCC_SAFETY_NET_PARANOID_INTERPRETERS のフラグは最後に適用され、単調に働きます。いずれも機能を強制的に true にするだけで、機能を無効にすることはできません。
  5. worktree モードは、workflow.worktree_modeCC_SAFETY_NET_WORKTREE の論理 OR です。
報告される有効なレベルは、最終的な 3 つの機能の組み合わせから決まります。どの preset にも一致しない組み合わせ(たとえば fail_closed が無効で paranoid_rm が有効な場合)は、custom として報告されます。 destructive_command_protection.overrides のルール単位の設定は、機能から決まった状態の後に適用されます。致命的な操作に対するルールは常に強制され、どの設定でも無効にできません。

監査ログの記録範囲

  • all(既定値であり、変数が未設定のときの動作)は、許可とブロックの両方のコマンド判定を記録します。
  • blocked はプライバシーを最重視する設定で、拒否だけを記録します。
  • この設定によって拒否の記録が省略されることはありません
  • これ以外の値を指定した場合は拒否のみの記録に戻り、doctor が警告 environment.audit-scope-invalid として報告します。
許可の判定が記録されるのは、ツール呼び出しがコマンドとして処理された場合だけです。コマンド以外のツール呼び出しは、許可されても記録されません。

デバッグ出力

CC_SAFETY_NET_DEBUG は、記録される判定の範囲を変えるものではありません。それを決めるのは CC_SAFETY_NET_AUDIT_SCOPE です。コマンドが許可された理由を調べるときや、バグ報告を作成するときに使ってください。設定されているかどうかは doctor コマンドが報告します。

設定ディレクトリの上書き

設定すると、policy.json<path>/policy.json から、ユーザースコープの rulebook 設定は <path>/rules/rule.json から、各 rulebook は <path>/rules/<rulebook-name>/rulebook.json から読み取ります。サンドボックス環境や、エージェントがシェルとは別のホームディレクトリで動作する構成など、標準以外の HOME を使う場合に利用できます。 上書きの対象はユーザースコープだけです。プロジェクトのポリシーファイルと rulebook 設定はプロジェクトディレクトリを基準に解決されるため、影響を受けません。
CC_SAFETY_NET_HOME を設定しても、監査ログの場所は変わりません。監査ログのルートは別に解決されます。決まり方については監査ログを参照してください。

更新チェックを無効にする

rule doc は通常、24 時間に 1 回まで新しいリリースの有無を確認します。https://registry.npmjs.org/cc-safety-net/latest を参照し、結果を $HOME/.cc-safety-net/update-check.json にキャッシュして、新しいバージョンがあれば標準エラー出力へ UPDATE_AVAILABLE: の行を書き出します。この確認は、rule doc の実行中に CLI が行う唯一の外部ネットワーク通信です。 CC_SAFETY_NET_NO_UPDATE_CHECK を設定すると、このチェックは完全にスキップされます。レジストリへの問い合わせも、キャッシュの書き込みも、UPDATE_AVAILABLE: の行も発生しません。doctor とダッシュボードが行う別の更新チェックには影響しません。

有効な設定を確認する

手早く確認したいときは status を、詳細なレポートが必要なときは doctor を実行します。
doctor レポートの Environment セクションには、各変数とその値、既定の動作、使用中の旧 SAFETY_NET_* 名が一覧表示されます。両コマンドの構文と出力は CLI コマンド、Claude Code 上で状態を常時確認する方法はステータスラインを参照してください。
最終更新日 2026年8月31日