rule.json です。rule.json に列挙された rulebook はいずれもライブファイルで、同じ呼び出しの中で <scope>/rules/<name>/rulebook.json から読み込まれます。この読み込みでは、書き込みもネットワークアクセスも結果のキャッシュも行わないため、スナップショットは常にディスク上の最新の設定を反映します。
スナップショットの状態は ready と degraded の 2 つだけです。このページでは、設定元が拒否されたときに失われる保護と、ready に戻す手順を説明します。
設定の状態
警告が 1 つでもあれば、ランタイムは
degraded になります。エラーと警告の違いは状態の深刻さではなく、その設定元がどう扱われるかにあります。
- エラーは、その設定元が破棄されたことを示します。その設定元からはルールが一切読み込まれません。
- 警告は、その設定元は有効なままで、拒否された部分だけが無視されることを示します。
degraded になります。
cc-safety-net status が出力する判定は ready と degraded の 2 つだけで、スナップショットの状態がそのまま反映されます。Claude Code のプラグインが無効でも判定は変わりません。その場合、status は Not active の先頭項目として次のように報告します。“plugin cc-safety-net@cc-marketplace is disabled in Claude Code; nothing is enforced in Claude Code until it is re-enabled. Other integrations are not affected.”無効な設定の扱い
設定が無効だというだけの理由で、通常の作業が拒否されることはありません。無効な設定は強制されませんが、それによってエージェントが何もできなくなることもありません。- 検証できないルールの設定元は破棄され、そのルールは強制されなくなります。
- 検証に成功した他のスコープは、引き続きルールを強制します。
- 組み込みの保護は、どの場合でも適用されます。破壊的コマンドのルール、シークレット保護、ポリシーファイルの保護、Git メタデータの保護は、ルールの設定を読み取らないためです。
- ユーザーポリシーのファイルを読み取れない場合は安全側の既定値に戻るため、破壊的コマンドの保護とシークレット保護は有効なままです。プロジェクトポリシーのファイルを読み取れない場合は、そのファイルの内容が一切反映されず、ユーザーポリシーがそのまま有効です。
rule.json の読み取りも、その場での編集も、cc-safety-net rule update の実行も通常のツール呼び出しであり、それぞれの内容に応じて成功または失敗します。そのため、エージェント自身が設定を修復できます。
どの状態でも保護され続けるのは、両スコープの policy.json です。ポリシーファイルの保護と Git メタデータの保護は、ポリシースナップショットの読み込みより前に動作するため、設定が壊れていても影響を受けません。ブロックされる操作の詳細はポリシーを参照してください。
設定のフォールバック一覧
エラー：設定元が破棄される
いずれのメッセージも、拒否したファイルまたは設定元と、それに応じた修復方法を示します。リモートの設定元の rulebook がない場合は
run `cc-safety-net rule update` to vendor <source> で終わります。ローカルの設定元の rulebook がない場合は create that file or remove that source from the rules config で終わります。rulebook が無効な場合と名前が一致しない場合は、どちらも fix that file で終わります。
警告：設定元は有効なまま
rulebook はすべてライブファイルです。保存した編集は次のツール呼び出しから有効になり、反映のための操作は要りません。編集して壊した場合も、黙って見過ごされることはありません。パースできない、またはスキーマに適合しないファイルは、上記の
invalid rulebook のエラーで破棄され、削除されたファイルは missing rulebook file のエラーで破棄されます。どちらの場合もスナップショットは degraded になります。policy.json：救済するか、安全側の既定値に置き換える
フィールド単位で救済するため、1 つの無効なフィールドが、ファイル内の他の保護まで無効にすることはありません。安全側の既定値は、拒否を増やす設定です。破壊的コマンドの保護とシークレット保護を強制的に有効にし、両方の allow path にある無効な項目と、保護を無効にする override を破棄します。有効なシークレットの allow path は、救済後のポリシーにも残ります。
.cc-safety-net/policy.json のプロジェクトファイルも同じように救済されますが、1 点だけ違いがあります。audit はユーザースコープ専用のため、プロジェクトファイルの audit セクションは project policy audit settings are ignored; audit is user scope only という診断とともに無視されます。フィールドごとの挙動はポリシーを参照してください。
ランタイムが policy.json を書き換えることはありません。手作業で修復するか、ダッシュボードの修復機能を使ってください。
ファイルにエラーがある間、ダッシュボードのフォームには救済後の値ではなく既定値一式が表示され、修復するまで保存できません。修復機能は、認識できた有効な設定を残します。ファイル全体が既定値に置き換わるのは、JSON をパースできない場合だけです。
transparent wrapper の対象範囲が欠ける場合
transparent_wrappers は rulebook ではなく rule.json で宣言しますが、rule.json にはダイジェストがありません。その結果、次の 2 点が生じます。
- rulebook が破棄された場合でも、そのスコープの wrapper は維持されます。
rule.json自体は読み取れるためです。 rule.jsonを読み取れない場合は、そのスコープの wrapper が失われます。フォールバックに使える検証済みのコピーがないためです。解析は、wrapper 越しに実行される保護対象コマンドを見つけられなくなります。
rule.json を修復してください。
fail closed になるケース
「fail closed」は、実行時の失敗や解析の失敗に対してその 1 回のツール呼び出しを拒否することを指す言葉であり、設定が無効なときの動作を指す言葉ではありません。
設定が無効な場合の動作は、これとは逆です。ルールの設定元を破棄し、
policy.json を救済するか安全側の既定値に置き換えたうえで、作業は続行します。
degraded 状態の報告
ルールの設定と
policy.json の両方を報告するのは doctor だけです。各コマンドのオプションと終了時の挙動はCLI コマンドを参照してください。
構造上の制限が 2 つあります。
Config warning:の行と監査ログのconfigFallbackフラグが付くのは、スナップショットを読み込んだ後に行われた判定だけです。ポリシーファイルと Git メタデータによる拒否はそれより前に起きるため、どちらも含まれません。- 診断は、拒否したファイルと条件の名前を示すだけで、ファイルの中身をそのまま写すことはありません。不正な設定ファイルに含まれるシークレットがメッセージに再出力されることはありません。
気づきやすい失敗と気づきにくい失敗
- 設定元が破棄されても、その場では通知されません。 拒否が減るため、通常のセッションでは問題に気づけないことがあります。ルールの設定変更後とアップグレード後には、
cc-safety-net statusを実行してください。詳しい診断にはdoctorを使います。 - 未移行の旧設定は、さらに見つけにくい問題です。 ランタイムはそのファイルを読み込まず、何も報告しません。そのため、旧設定のルールが何も保護していない状態でも、スナップショットは
readyのままです。検出にはrule verifyを使います。 - 無効な
policy.jsonは、たいてい自分から気づけます。 拒否されたセクションは、2 つの保護を有効にし、allow path と保護を無効化する override を破棄する安全側の既定値に戻るため、設定したつもりより多くの拒否が発生するからです。 - 無効な
policy.jsonの、気づきにくい側面：無効なsafety.levelは黙ってstandardに戻るため、paranoidの綴り間違いは preset を引き下げてしまいます。無効なsecret_protection.deny_pathsの項目や、ルールを既定より強くするルール単位の override も、修復されずに破棄されます。 - 常時表示されるサインは、ステータスラインの表示だけです。
Config warning:の行は無関係な拒否が起きたときにしか現れず、その他の表示箇所は、コマンドを実行するかダッシュボードを開くまで何も知らせません。
設定を復旧する
以下のコマンドはいずれも通常のツール呼び出しなので、ランタイムが degraded の間でも、エージェント自身が一連の手順をすべて実行できます。各コマンドのオプションと終了時の挙動はCLI コマンドにあります。1
判定を確認する
ready または degraded の判定と、Not active 内の診断を 1 件ずつ表示します。Claude Code のプラグインが無効な場合は、別の判定にはなりません。Not active の先頭項目として表示されます。終了コードを使うゲートにはせず、日常の状態確認に使ってください。2
詳細なレポートを取得する
policy.json の両方を対象にする唯一のコマンドです。ランタイムが degraded の場合は config.runtime-degraded の警告として表示され、その詳細欄に、拒否されたすべての設定元を含む理由の全文が出ます。3
実際に有効なものを確認する
Issues と Warnings を表示します。破棄された設定元と一緒に失われたルールを確認するときに使います。終了コードが 0 以外になるのは、設定にエラーがある場合だけです。警告だけの場合は Warnings に出力したうえで 0 を返します。4
ルールの設定を検証する
rule.json をスキーマに照らして検証し、実行時と同じ読み込みを再現するため、ガードが遭遇するのと同じ問題を検出できます。移行が必要な旧形式のファイルも検出します。問題がなければ All configs valid. または Configs valid with warnings. を出力し、問題があれば Config validation failed. を出力して終了コード 1 を返します。書き込みが 1 つだけ発生する場合があります。有効な rule.json に $schema キーがない場合は追加し、Added $schema to <scope> config. と出力します。それ以外の変更は行いません。5
設定元を修復する
ローカルの rulebook にコマンドは不要です。診断が指すファイルを編集すれば、次のツール呼び出しでガードがそれを読み込みます。リモートの設定元がない、または古い場合は、取り込み直します。設定済みのリモートの設定元をすべて解決し直して
rules/<name>/rulebook.json に書き出し、そのうえでガードと同じ方法でそのスコープを読み込み直します。設定元を 1 つ指定すればそれだけを更新でき、ユーザースコープには --global を付けます。診断が残っている場合は成功と報告せず、診断を出力して 0 以外の終了コードを返します。Rule config updated. に続いて Active rulebooks (<n>): の一覧が出れば、そのスコープに問題はありません。更新は設定元ごとに独立しています。失敗した設定元は Failed to update <spec>: <message> を出力し、すでにあるコピーをそのまま保持します。他の設定元は更新されます。検証の対象は、更新しているスコープだけです。6
policy.json を手作業で直す
ランタイムが
policy.json を書き換えることはありません。診断に挙がったフィールドを自分で修正するか、ダッシュボードの修復機能を使ったうえで、status を実行し直してください。スキーマ全体と既定値はポリシーを参照してください。status を実行し直してください。ランタイムは次のツール呼び出しで再読み込みするため、何かを再起動する必要はありません。
以前のバージョンのロックとキャッシュを移行する
以前のバージョンで設定したスコープには、rule.lock と cache ディレクトリが残っていることがあります。どちらも読み込まれなくなったため、スナップショットは ready のままで、そこから強制されるものもありません。cc-safety-net doctor は、これらを info 重大度の finding config.v2-leftovers（タイトルは “Rulebook lock and cache leftovers detected”）として報告し、詳細欄に Files an earlier version left behind are no longer read: <paths>. を出します。修正のヒントは Run `cc-safety-net rule sync` (add `--global` for user scope) to migrate them, then rerun doctor. です。
現在の rule sync が行うのは、この移行だけです。オフラインで動作し、最初に非推奨の告知を出力します。
rule.json がない、または読み取れない場合は、実行を中止します。設定元を記録しているのがロックだけになるためです。出力されるメッセージの全体は rule sync を参照してください。
旧形式のインラインルールを移行する
旧形式のインライン設定ファイル（~/.cc-safety-net/config.json と .safety-net.json）は、実行時に読み込まれず、診断も出ません。他の部分は動作しますが、それらのルールはまったく強制されず、スナップショットは ready のままです。アップグレード後には、この状態を見落とすことがあります。移行待ちの旧形式ファイルは、cc-safety-net rule verify だけが検出します。
変換したい旧設定があるプロジェクトで、移行コマンドを実行します。
rule migrate は同期の結果をそのまま引き継ぎます。移行後のスコープに診断が残っている場合は、成功とは報告せず、その診断を出力します。移行後のファイルは書き込まれ、旧形式のファイルも残るため、報告された問題を直してから再実行できます。移行先となる rulebook の構成はカスタムルールを参照してください。
関連ページ
ポリシー
policy.json の完全な仕様、既定値、フィールド単位の救済。カスタムルール
rulebook の構成、設定元、取り込み、override、transparent wrapper。
CLI コマンド
status、doctor、および各 rule サブコマンドのオプションと終了時の挙動。監査ログ
判定が記録される場所、エントリのスキーマ、保持期間。