policy.json は、CC Safety Net の設定ファイルです。安全 preset、組み込み保護の有効／無効、保護対象パス、監査レコードの保持期間を設定します。スコープは 2 つあり、ユーザーファイルと、リポジトリにコミットする任意のプロジェクトファイルです。
独自のブロックルールを定義する rule.json や rulebook とは別のファイルです。それらのスキーマはカスタムルールを参照してください。
ポリシーファイルの場所
CC_SAFETY_NET_HOME を設定すると、ユーザーファイルは指定したディレクトリの直下に置かれ、rules/ と並びます。指定方法は環境変数を参照してください。
CC_SAFETY_NET_HOME が効くのはユーザーファイルだけです。プロジェクトファイルは常にプロジェクトルート直下の .cc-safety-net/policy.json で、ルールのスコープが解決するディレクトリと同じです。
ランタイムはツール呼び出しごとに両方のファイルを読み取ります。ユーザーファイルが基準となり、その上にプロジェクトファイルが重なります。プロジェクトポリシーを参照してください。
ダッシュボードがユーザーファイルを書き込むときは、ディレクトリを 0700、ファイルを 0600 で作成します。
プロジェクトポリシー
チームは.cc-safety-net/policy.json をリポジトリにコミットすることで、安全ポリシーを配布できます。メンバーが実行するコマンドはありません。ランタイムが次のツール呼び出しでこのファイルを読み取ります。どのチェックアウトでも同じです。
プロジェクトファイルに書かれるのは、設定したフィールドだけです。書かれていないフィールドは、引き続きユーザーポリシーから継承します。ルールの override を 1 つだけ設定したプロジェクトファイルは、そのルール以外には影響しません。
実効ポリシーは、ユーザーポリシーの上にプロジェクトポリシーを重ねた結果です。
プロジェクトファイルの
audit セクションは無視され、読み込み時に project policy audit settings are ignored; audit is user scope only が報告されます。
報告される緩和
プロジェクトポリシーは書かれたとおりに適用されます。ユーザーポリシーの水準まで引き戻されることはありません。その代わり、ユーザーポリシーより緩めているフィールドが 1 行ずつ報告されます。project policy lowers level: <user> -> <project>project policy disables fail_closed、project policy disables paranoid_rm、project policy disables paranoid_interpretersproject policy enables worktree mode relaxationsproject policy disables destructive command protectionproject policy disables secret protectionproject policy disables rule <id>project policy adds destructive allow path: <path>project policy adds secret allow path: <path>
statusは、プロジェクトファイルのパスを示すProject行と、これらの行を並べたProject policyブロックを追加します。- ステータスラインは、緩和が 1 つでもある間
🔻を表示します。ステータスラインを参照してください。 doctorは、Effective Safety の下にProject policy deltas:ブロックを出力します。doctorとexplainは、安全 preset を供給したスコープをuser policy、project policy、built-in defaultのいずれかで併記します。explain トレースを参照してください。
ポリシーファイルの保護
policy.json は両方のスコープで、ready でも degraded でも、すべてのランタイム状態で保護対象のパスです。ポリシーファイルの保護はポリシースナップショットの読み込みより前に動作するため、設定が壊れていても弱められません。次の操作は即座にブロックされます。
- 任意のツールによる、このファイルへの書き込み、編集、パッチ適用
- ファイル名をオペランドに含むシェルコマンド
- このファイルへの書き込みリダイレクト
- そのディレクトリ、またはその上位ディレクトリに対する再帰的な
rm - このファイルに到達する
find … -deleteとfind … -exec rm - このファイル、そのディレクトリ、または上位ディレクトリを移動元とする
mv
.cc-safety-net ディレクトリだけを対象にします。ここで打ち切るのは意図的です。さらに上までたどると、作業ディレクトリとそのすべての上位ディレクトリまで対象に入ってしまいます。このガードは破壊的コマンドのルールより先に動くため、rm -rf . や find . -delete が本来の具体的な理由ではなく、この汎用的な理由を返すようになります。
読み取りは許可されます。読み取り専用コマンドの許可リストには、[、cat、file、grep、head、jq、less、ls、more、rg、sed、stat、tail、test、wc が含まれます。ただし sed は、-i や --in-place によるその場編集を行わない場合にかぎります。Grep や Glob のような読み取り専用ツールは、完全に対象外です。
ポリシーファイルを編集する
次のいずれかの方法を選びます。- ダッシュボードを使う。
cc-safety-net guiを実行します。ダッシュボードは適切なパーミッションでファイルを書き込み、検証に通らないファイルを修復できます。ファイルにエラーがある間は、フォームにファイル内の有効な値ではなく既定値一式が表示され、ファイルを修復するまで保存できません。修復では、認識できる有効な設定は残し、無効なフィールドを破棄します。この修復動作を使いたくない場合は、ファイルを手動で編集してstatusで確認してください。 - JSON を直接編集する。 エディターでファイルを開いて手作業で変更します。ランタイムは次のツール呼び出しで変更を読み込むため、再起動は必要ありません。
- 提案を適用する。
cc-safety-net policy apply <file>を実行すると、ターミナルで差分を確認したうえで、提案ファイルの内容をどちらかのスコープに書き込みます。提案の確認と適用を参照してください。
degraded になった場合は、ファイルの一部が拒否されています。npx cc-safety-net doctor を実行すると、該当するフィールドが分かります。ランタイムが policy.json を自動で書き換えることはありません。無効なファイルは、手作業またはダッシュボードの修復機能で直すまで残ります。
提案の確認と適用
policy check と policy apply は、1 つの流れをエージェントとユーザーで分担します。エージェントは提案の JSON を書き、policy check を実行して変更内容を示します。policy apply は、ユーザー自身がターミナルで実行します。
Effective policy (user + project merged): の行がそれを示します。設定したフィールドだけを持つ提案でも、セッションが実際に動作するレベルは変わるため、確認画面にはファイル自体の内容ではなくマージ結果を表示します。-g, --global を指定すると、ヘッダーは Scope: user (<path>) になり、マージの行はなくなり、audit.retention_days を含めてユーザーファイルと提案を比較します。
差分の行は、Changes (<n>): の見出しの下に <field>: <before> -> <after> の形式で並びます。片側が存在しない場合は (unset) と表示されます。変更がない場合は No changes. と出力します。
プロジェクトの提案に audit セクションがある場合は、差分を出力する前に <file>: audit settings are user scope only; remove the audit section from a project proposal で拒否されます。
policy apply は、stdin と stdout の両方が TTY である必要があります。TTY でない場合は、実行すべきコマンドを示して終了コード 1 で終了します。
Apply this policy to <path>? [y/N] と確認します。受け入れるのは大文字小文字を問わず y または yes だけで、それ以外は拒否と扱われます。EOF も拒否です。拒否した場合は Cancelled; nothing was written. を出力して終了コード 0 で終了します。書き込んだ場合は Policy applied: <path> を出力します。--yes フラグも非対話モードもありません。
エージェントが policy apply を実行した場合は即座にブロックされます。理由の文言は次のとおりです。
npx、bunx、pnpx、pnpm dlx と yarn dlx、npm exec、pnpm exec、yarn exec、cc-safety-net@latest のようなバージョン指定、bun や node によるエントリポイントファイルの実行です。対象の前にランナーのオプションが置かれていても一致します。policy check はエージェントにも許可されたままです。
ポリシーの完全な例
すべてのフィールドと既定値を次に示します。version だけです。ほかはすべて省略でき、省略した場合は上記の既定値が使われます。ファイル自体が存在しない場合も、CC Safety Net はこの既定値で動作し、判定は ready のままです。
ルートオブジェクトは厳密に検証されます。認識できないトップレベルのキーはエラーです。safety、workflow、destructive_command_protection、secret_protection、audit の中に認識できないキーがある場合も同様にエラーです。
スキーマリファレンス
integer
必須
スキーマのバージョン。
1 である必要があります。唯一の必須フィールドで、値がない場合や誤っている場合の診断メッセージは version must be 1 です。string
デフォルト:"standard"
安全 preset。
"standard"、"strict"、"paranoid" のいずれかです。各 preset は、継承される機能の既定値を定めます。strict は fail_closed を、paranoid は fail_closed、paranoid_rm、paranoid_interpreters を有効にします。各機能の効果は安全レベルを参照してください。boolean
preset にかかわらず、fail closed 機能を明示的に有効または無効にします。preset から継承する場合は、このキーを省略します。
boolean
paranoid の
rm 機能を明示的に有効または無効にします。preset から継承する場合は、このキーを省略します。boolean
paranoid のインタープリター機能を明示的に有効または無効にします。preset から継承する場合は、このキーを省略します。
boolean
デフォルト:"false"
確認済みの linked worktree 内で、ローカルの変更を破棄する Git ルールを緩和します。検出は fail closed です。作業ディレクトリが linked worktree だと確実に判定できない場合は、より厳しい既定のルールがそのまま適用されます。緩和される操作と緩和されない操作の正確な一覧は、安全レベルを参照してください。
boolean
デフォルト:"true"
登録済みの破壊的コマンドルールのマスタースイッチです。
false にすると、登録済みのルールをすべてスキップします。ただし、常に強制される致命的操作のルールは除きます。object
デフォルト:"{}"
登録済みの破壊的コマンドルール ID をキーとする、ルール単位の状態です。値は
"on" または "off" です。機能から決まった状態の上に適用されるため、"on" は preset が無効にしているルールを有効にでき、"off" は preset が有効にしているルールを無効にできます。string[]
デフォルト:"[]"
破壊的コマンドのルールから除外するパスです。各項目は絶対パスであるか、
~/ で始まる必要があります。boolean
デフォルト:"true"
シークレット保護のマスタースイッチです。
false にすると、ユーザーが設定した deny_paths も含め、シークレット判定のステージ全体をスキップします。object
デフォルト:"{}"
登録済みのシークレット保護ルール ID をキーとする、ルール単位の状態です。値は
"on" または "off" です。ほとんどのシークレットルールはシークレット保護が有効なかぎり有効なので、通常使うのは "off" の方向です。一方、Coding CLI 設定階層は既定で無効なので、これらのルールを使う場合は明示的に "on" を指定します。string[]
デフォルト:"[]"
組み込みのシークレットパターンルールから除外する、特定のファイルまたはディレクトリツリーです。設定済みの deny path と Coding CLI の保護は引き続き適用されます。検証ルールと優先順位は、Secret allow pathを参照してください。
integer
デフォルト:"30"
スイープによって削除されるまで監査履歴を保持する日数です。
1 から 365 までの整数である必要があります。安全レベルと機能の override
safety.level で preset を選び、その上で safety.overrides が個別の機能を明示的に設定します。機能を引き下げられるのはここだけで、環境変数のフラグは引き上げることしかできません。
paranoid preset を使い、インタープリターの 1 行コードだけを対象外にしています。最終的な機能の組み合わせがどの preset にも一致しない場合、有効なレベルは custom と報告されます。
環境変数はポリシーのレベルを引き上げたり機能を強制的に有効にしたりできますが、その逆はできません。
policy.json と環境変数の優先順位の全体像（worktree_mode の OR と以前の SAFETY_NET_* エイリアスを含む）は、環境変数を参照してください。破壊的コマンドの保護
destructive_command_protection.overrides では、次のように組み込みルールを ID で指定します。
unknown destructive command rule id "<id>" で拒否されます。"on" と "off" 以外の値は、destructive_command_protection.overrides.<id> must be "on" or "off" で拒否されます。
致命的な操作に対するルールは常に強制され、ユーザーの設定では変えられません。 これらは enabled: false も "off" の override も無視します。対象となるのは、/ やホームディレクトリの削除、Git メタデータの削除、およびそれらに相当する PowerShell と find の操作です。各ルールが何を強制するかは、ブロックされるコマンドを参照してください。
Allow path
destructive_command_protection.allow_paths は、特定の場所を破壊的コマンドのルールから除外します。検証は deny path より厳格です。
シークレット保護
シークレット保護は、資格情報を含むファイルの読み取りと書き込みをブロックします。このセクションで扱うのは設定の仕様です。組み込みルールの全一覧（各 ID、保護対象のパス、除外条件）は、シークレット保護リファレンスを参照してください。secret_protection.overrides では、組み込みルールを個別に ID で指定し、値として "on" または "off" を使います。"off" は既定で有効なルールを無効にし、"on" は既定で無効な階層のルールを有効にします。
unknown secret protection rule id "<id>" で、それ以外の値は secret_protection.overrides.<id> must be "on" or "off" で拒否されます。
既定で無効なルール
組み込みのシークレットルールは、ほとんどがシークレット保護と同時に有効になります。唯一の例外は、対応するコーディングエージェントの設定ファイルと MCP 設定ファイルを対象にする Coding CLI config ルールです。これらのファイルは資格情報を直接含むことがありますが、エージェントが通常の作業で編集することもあります。このため、Coding CLI config は既定で無効です。使うルールごとに"on" の override を指定してください。有効にした config ルールは、エージェントのユーザーレベル設定に加え、任意のリポジトリルートにある同名のプロジェクトレベルファイル（.mcp.json など）も保護します。
既定で無効な 10 個の ID、それぞれに対応する既定で有効な Coding CLI credential ルール、各ルールが保護する正確なパスは、シークレット保護リファレンスに記載しています。
Deny path
secret_protection.deny_paths は、組み込みの機密パスに加えて独自の保護対象を追加します。deny path は組み込みルールより先に評価され、一致した場合はルール ID secret.deny-path による即時ブロックになります。
検証：
相対パスは、各セッションの作業ディレクトリを基準に解決します。ファイルを保存する時点では、そのディレクトリが分からないためです。ホームディレクトリ、その上位パス、
/ は拒否されます。これらを指定すると、ホームディレクトリ配下のほぼすべての作業環境で、あらゆるコマンドがブロックされます。
**有効な deny path が保護する範囲：**そのパス自体と、その配下すべてです。比較の前に、対象は実行時の作業ディレクトリを基準に、設定されたパスは設定時の作業ディレクトリを基準に正規化されます。
知っておくべき制限が 2 つあります。
- deny path が適用されるのは、
secret_protection.enabledがtrueの間だけです。falseにすると、シークレット判定ステージの他の保護もろとも無効になります。 secret.deny-pathは登録済みのシークレットルール ID ではないため、secret_protection.overridesでは無効にできません。無効にできるのはsecret_protection.enabled: falseだけです。
Secret allow path
secret_protection.allow_paths は、特定のファイル、またはディレクトリとその配下すべてを、組み込みのベース名ルール、ホームディレクトリルール、鍵ファイルの派生形ルール、拡張子ルールから除外します。リポジトリ内の .env.test や、シークレットではないものの資格情報らしいファイル名を含むフィクスチャ用ディレクトリなど、意図して管理しているファイルに使います。
優先順位は固定です。
- 設定済みの deny path が常に優先します。同じ対象が両方のリストにある場合、結果は
secret.deny-pathになります。 - Coding CLI の credential ルールと config ルール（
secret.cli.*）が常に優先します。allow path でエージェント自身の資格情報や設定を露出させることはできません。 - allow path に一致した対象については、その他の組み込みシークレットルールが抑制されます。
各項目はリテラルなパスであり、glob パターンではありません。対象は実行時の作業ディレクトリから、相対指定の allow path は設定時の作業ディレクトリから解決されます。一致判定（同一または配下かどうか）の前に、両側とも既存のシンボリックリンクをたどるため、allow path の起点はシンボリックリンク経由で到達する対象も含みます。
ランタイムは、パスを解決した後にも安全性の境界を確認します。ホームディレクトリやその上位に解決される項目は無視します。実際に使われるガード設定ルート配下の対象も除外しません。
CC_SAFETY_NET_HOME でルートを移した場合や、ホームディレクトリまたは ~/.cc-safety-net がシンボリックリンクの場合も同じです。
監査ログの保持期間
audit.retention_days は、保持期間のスイープによって削除されるまで監査レコードを保持する期間を指定します。既定値は 30 日、指定できる範囲は 1〜365 です。
保持期間は、ポリシーの他の部分とは独立して解決されます。スイープはこのフィールドだけをファイルから直接読み取るため、他の箇所で検証に失敗するポリシーでも削除処理は動作します。値がない、整数でない、または使用できない場合は 30 に戻ります。
1 未満は 1 に、365 を超える値は 365 に丸められます。そのため、範囲外の値を指定すると 2 つのことが同時に起こります。スキーマ検証はその値を拒否してランタイムを degraded にし、スイープのほうは値を丸めて使います。"retention_days": 1000 は診断に表示されつつ、実際には 365 日で削除されます。無効なポリシーの扱い
policy.json が無効でも、通常の作業がブロックされることはありません。ランタイムは degraded に移行し、フォールバックを使用します。次の表は 1 つのファイルについての説明です。どちらのスコープも同じ救済処理を通り、診断には元のファイルのパスが接頭辞として付きます。
救済処理は意図的に安全側へ倒してあります。そのため、壊れたファイルでは通常、設定したつもりより多くの操作が拒否されます。
壊れたプロジェクトファイルも同じように救済されます。拒否されたセクションだけが落ち、両方のファイルの残りはそのまま有効です。ユーザーファイルが読み取れない場合でも、プロジェクトポリシーがフィールドを提供していれば、そのフィールドが有効になるため、組み込みの既定値ではなく救済として報告されます。スコープの由来情報は、プロジェクトファイルが存在すれば有効・無効を問わず表示されるため、
status は Project 行を出し続けます。
degraded 状態の完全な仕様、その報告のされ方、ready に戻す方法は、設定の復旧で説明しています。
関連ページ
安全レベル
各安全機能が何を変えるか、worktree モードが何を緩和するか。
環境変数
ポリシーのレベルを引き上げる変数を含む、すべての環境変数。
カスタムルール
独自のブロックルールを定義する
rule.json と rulebook のスキーマ。設定の復旧
ready と degraded の違い、フォールバックの一覧、修復の手順。