policy.json の値が誤ったフィールドなど、設定の一部を CC Safety Net が拒否した状態です。CC Safety Net は読み込めた設定で動作を続けます。この縮小された設定がフォールバック設定です。ファイル内の有効な部分すべて、拒否された policy.json のフィールドに代わる組み込みの既定値、そしてすべての組み込み保護で構成されます。
doctor はこの状態を「Runtime is enforcing a fallback configuration」と報告し、ダッシュボードのバナーには「A fallback configuration is being enforced」と表示されます。doctor の検出結果には、拒否されたファイルとフィールドがそれぞれ示されます。後述の手順で修正してください。
拒否されたルールブックは、修正するまでブロックしなくなります。拒否された policy.json のフィールドは既定値に戻り、たいていは設定したときよりも多くの操作をブロックします。
設定の状態
警告が 1 つでもあれば、ランタイムは
degraded になります。
- エラーは、CC Safety Net が破棄した設定元を示します。その設定元のルールは一切使われません。
- 警告は、有効なままの設定元を示します。無視されるのは、拒否された部分だけです。
無効な設定の扱い
設定が無効だというだけで、通常の作業がブロックされることはありません。また、拒否された部分が強制されることもありません。- 検証できないルールの設定元は破棄され、そのルールは適用されなくなります。
- 検証に成功したほかのスコープは、引き続きルールを強制します。
- 組み込みの保護はすべて適用され続けます。破壊的コマンドのルール、シークレット保護、
policy.jsonの保護、Git メタデータの保護は、ルールの設定を読み取らないためです。 - 無効な
policy.jsonは、有効なフィールドをそのまま使い、残りには組み込みの既定値を使います。policy.json：救済するか、安全側の既定値に置き換えるを参照してください。
rule.json の読み取りや編集、cc-safety-net rule update の実行は通常のツール呼び出しなので、エージェント自身がルールの設定を修復できます。
ブロックの理由が「failed closed」の場合は、これとは別のケースです。CC Safety Net がそのコマンド 1 つの解析を完了できなかったことを意味します。フェイルクローズによる強制を参照してください。
設定のフォールバック一覧
エラー：設定元が破棄される
いずれのメッセージも、拒否したファイルまたは設定元と、それに応じた修復方法を示します。リモートの設定元のルールブックがない場合は
run `cc-safety-net rule update` to vendor <source> で、ローカルの設定元のルールブックがない場合は create that file or remove that source from the rules config で終わります。ルールブックが無効な場合と名前が一致しない場合は、どちらも fix that file で終わります。
警告：設定元は有効なまま
名前が重複した場合の解決方法はスコープのマージを参照してください。
policy.json：救済するか、安全側の既定値に置き換える
JSON オブジェクトとしてパースできるファイルは救済されます。有効なフィールドはそのまま残り、無効なフィールドは 2 つ目の表のとおりフォールバックします。それ以外の壊れたユーザーファイルは、安全側の既定値に置き換えられます。安全側の既定値とは、両方の保護が有効で、オーバーライドも許可パスも拒否パスもない組み込みの既定値です。
ランタイムが
policy.json を書き換えることはありません。手作業で修正するか、ダッシュボードの修復機能を使ってください。
rule.json で宣言する対象範囲
transparent_wrappers と command_tools は、組み込みの解析が届く範囲を広げます。どちらもルールブックではなく rule.json に書きます。
- ルールブックが破棄されても、どちらのフィールドも残ります。
rule.json自体は読み取れるためです。 rule.jsonを読み取れない場合は、そのスコープで両方とも失われます。そのスコープのラッパーを透過した解析は行われなくなり、そのスコープで宣言したコミュニティ製のシェルツールも解析されなくなります。組み込みの 8 つのラッパー（caffeinate、exec、nice、nohup、setsid、stdbuf、time、timeout）はファイルを必要としないため引き続き適用され、もう一方のスコープの宣言も同様です。
rule.json を読み取れずにスコープが破棄された場合は、まずそのファイルを修復してください。
degraded 状態の報告
ルールの設定と
policy.json の両方を報告するのは doctor だけです。診断は拒否したファイルと問題を示しますが、ファイルの中身は写さないため、壊れたファイル内のシークレットが表示されることはありません。
気づきやすい失敗と気づきにくい失敗
- 設定元の破棄は気づきにくい。 拒否が減るため、セッション中に何かがブロックされたり警告が出たりすることはありません。ルールの設定を変更したあとと、アップグレードのたびに
cc-safety-net statusを実行してください。 - 未移行の旧形式のルールファイルは、さらに気づきにくい。 CC Safety Net はそのファイルを読み込まず、状態は
readyのままですが、そのルールは何も保護していません。doctorはconfig.legacy-ignoredとして報告します。旧形式の設定を移行するを参照してください。 - 無効な
policy.jsonのフィールドは、たいてい気づける。 保護が有効の状態に戻るため、設定したよりも多くの拒否が発生します。 policy.jsonの 2 種類の誤りは、気づかないうちに保護を下げる。 無効なsafety.levelはstandardに戻るため、paranoidの綴りを間違えるとプリセットが下がります。無効なdeny_pathsの項目は破棄されるため、その場所は保護されなくなります。- 何もしなくても表示されるのは、ステータスラインの表示だけです。
Config warning:の行は無関係な拒否が起きたときにしか現れず、ほかの表示箇所は、コマンドを実行するかダッシュボードを開くまで何も知らせません。
設定を復旧する
以下のコマンドは、ランタイムが degraded の間でもエージェントが実行できます。オプションと終了コードは CLI リファレンスにあります。1
判定を確認する
ready または degraded と、Not active の下に診断を 1 件ずつ表示します。status を参照してください。2
詳細なレポートを取得する
policy.json の両方を対象にします。config.runtime-degraded の検出結果に、拒否されたすべての設定元が示されます。doctor を参照してください。3
ルールの設定を確認する
rule list は有効なルールを表示するため、破棄された設定元とともに何が失われたかが分かります。rule verify は、両方の rule.json をランタイムと同じ方法で読み込んで確認し、問題があれば Config validation failed. で終わります。rule verify を参照してください。4
設定元を修復する
ローカルのルールブックは、診断が示すファイルを編集します。ランタイムは次のツール呼び出しでそれを読み込みます。リモートの設定元がない、または古い場合は、取り込み直します。設定元の名前を指定すればそれだけを更新でき、ユーザースコープには
--global を付けます。診断が残っている場合は、成功と報告せずにその診断を出力します。rule update を参照してください。5
policy.json を自分で直す
エージェントは
policy.json を編集できません。診断に挙がったフィールドを自分で修正するか、ダッシュボードの修復機能を使ってください。ポリシーファイルを編集するを参照してください。status を実行し直してください。ランタイムは次のツール呼び出しで再読み込みするため、再起動は必要ありません。
関連ページ
ポリシー
policy.json の完全な仕様と既定値。カスタムルール
ルールブックの構成、設定元、取り込み、オーバーライド、透過ラッパー。
CLI コマンド
status、doctor、各 rule サブコマンドのオプションと終了時の挙動。監査ログ
判定が記録される場所、エントリのスキーマ、保持期間。