メインコンテンツへスキップ
policy.json は CC Safety Net の設定ファイルです。安全プリセットの選択、組み込みルールの有効化と無効化、特定パスの許可とブロック、監査レコードの保持期間を設定します。ユーザーファイルはどこでも適用され、リポジトリにコミットした任意のプロジェクトファイルがその上に重なります。 独自のブロックルールは、policy.json ではなく rule.json とルールブックに書きます。カスタムルールを参照してください。

ポリシーファイルの場所

ランタイムはツール呼び出しのたびに両方のファイルを読み取るため、編集は次のコマンドから反映されます。CC Safety Net が読み取るファイルと、CC_SAFETY_NET_HOME で移動するものの一覧は、設定ファイルの場所を参照してください。

設定時の作業ディレクトリとは

設定時の作業ディレクトリは、エージェントのセッションが動いているディレクトリです。CC Safety Net は、ここからプロジェクトの .cc-safety-net/ フォルダーを読み取り、相対パスで書かれた deny_paths と allow_paths の項目もここを基準に解決します。コマンド内の cd や、独自の作業ディレクトリを指定したツール呼び出しでは変わりません。

プロジェクトポリシー

チームは .cc-safety-net/policy.json をリポジトリにコミットすることで、安全ポリシーを配布できます。メンバーは何も実行する必要がなく、ランタイムが次のツール呼び出しでこのファイルを読み取ります。プロジェクトファイルに書くのは、設定したいフィールドだけです。書かれていないフィールドはユーザーポリシーから継承します。 実効ポリシーは、ユーザーポリシーの上にプロジェクトポリシーを重ねたものです。 プロジェクトファイルの audit セクションは無視され、project policy audit settings are ignored; audit is user scope only が報告されます。

ユーザー設定ディレクトリはプロジェクトではない

ユーザーの .cc-safety-net/ があるディレクトリ(既定ではホームディレクトリ)が、同時にプロジェクトになることはありません。そこで実行すると .cc-safety-net/policy.json はユーザーファイルそのものなので、上に重なるプロジェクトファイルはありません。プロジェクトファイルに書き込むコマンドは、そこでは実行を拒否します。policy が書き込むファイルを参照してください。

報告される緩和

プロジェクトポリシーは書かれたとおりに適用されます。CC Safety Net は、プロジェクトがユーザーポリシーより緩めているフィールドを 1 行ずつ報告します。
  • project policy lowers level: <user> -> <project>
  • project policy disables fail_closed、project policy disables paranoid_rm、project policy disables paranoid_interpreters
  • project policy enables worktree mode relaxations
  • project policy disables destructive command protection
  • project policy disables secret protection
  • project policy disables rule <id>
  • project policy adds destructive allow path: <path>
  • project policy adds secret allow path: <path>
status はこれらの行を Project policy の下に、doctor は Project policy deltas: の下に出力します。ステータスラインは、緩和が 1 つでも適用されている間 🔻 を表示します。
レベルの引き下げは、ユーザーポリシーの safety.level を基準に判定します。機能の無効化は、ユーザーポリシーのレベルを CC_SAFETY_NET_LEVEL で引き上げたものを基準に判定します。そのため CC_SAFETY_NET_LEVEL=paranoid のもとでプロジェクトが safety.overrides.paranoid_rm: false を設定すると、paranoid_rm は無効になり、緩和として報告されます。後述のスイッチを設定した場合は無効になりません。

プロジェクトの緩和を無視する

CC_SAFETY_NET_PROJECT_TIGHTEN_ONLY=1 を設定すると、プロジェクトポリシーによる緩和をすべて拒否できます。マージ時に上の一覧のフィールドを取り除き、保護を強める設定はそのまま適用します。環境変数を参照してください。 取り除いたフィールドも、status では Project policy (ignored) の下に、doctor では Project policy deltas (ignored): の下に報告されます。ステータスラインに 🔻 は表示されません。policy check、policy apply、ダッシュボードのプロジェクト下書きは、このスイッチなしでマージした結果をプレビューします。表示されるのは、スイッチを設定していないメンバーに適用される内容です。

ポリシーファイルを編集する

エージェントは、どちらのスコープの policy.json も変更できません。ブロックの内容は保護される policy.json ファイルで説明しています。変更は、次のいずれかの方法で自分で行います。
  • ダッシュボードを使う。 cc-safety-net gui を実行します。検証に通らないファイルの修復もできます。ダッシュボードを参照してください。
  • JSON を直接編集する。 ランタイムは次のツール呼び出しで変更を読み込みます。再起動は必要ありません。
  • エージェントの提案を適用する。 エージェントが提案ファイルを書き、cc-safety-net policy check <file> を実行して差分を示します。ユーザーがターミナルで cc-safety-net policy apply <file> を実行し、確認に答えます。policy を参照してください。
手作業で編集したら、結果を確認します。
判定が degraded なら、CC Safety Net がファイルの一部を拒否しています。npx cc-safety-net doctor を実行すると、該当するフィールドが分かります。無効なポリシーの扱いを参照してください。

ポリシーの完全な例

すべてのフィールドと既定値を次に示します。
必須のフィールドは version だけで、省略したフィールドには上の既定値が使われます。認識できないキーは、トップレベルでも各セクションの中でもエラーになります。

スキーマリファレンス

integer
必須
スキーマのバージョンで、1 でなければなりません。唯一の必須フィールドです。値がない場合や誤っている場合は version must be 1 が報告されます。
string
デフォルト:"standard"
安全プリセット。"standard"、"strict"、"paranoid" のいずれかです。strict は fail_closed を、paranoid は fail_closed、paranoid_rm、paranoid_interpreters を有効にします。各機能で何が変わるかはモードを参照してください。
boolean
プリセットにかかわらず、フェイルクローズ機能を明示的に有効または無効にします。プリセットから継承する場合は、このキーを省略します。
boolean
paranoid の rm 機能を明示的に有効または無効にします。プリセットから継承する場合は、このキーを省略します。
boolean
paranoid のインタープリター機能を明示的に有効または無効にします。プリセットから継承する場合は、このキーを省略します。
boolean
デフォルト:"false"
確認済みのリンクされたワークツリー内で、ローカル破棄の Git ルールを緩和します。緩和される操作と、決して緩和されない操作はモードを参照してください。
boolean
デフォルト:"true"
登録済みの破壊的コマンドルールのマスタースイッチです。false にすると、登録済みのルールをすべてスキップします。ただし、常に適用される致命的なルールは除きます。
object
デフォルト:"{}"
破壊的コマンドのルール ID をキーとする、ルール単位の状態です。値は "on" または "off" です。プリセットの上に適用されるため、"on" はプリセットで無効なルールを有効にでき、"off" はプリセットで有効なルールを無効にできます。
string[]
デフォルト:"[]"
破壊的コマンドのルールから除外するパスです。各項目は絶対パスか、~/ で始まるパスでなければなりません。
boolean
デフォルト:"true"
シークレット保護のマスタースイッチです。false にすると、deny_paths も含めてシークレット判定のステージ全体をスキップします。
object
デフォルト:"{}"
シークレット保護のルール ID をキーとする、ルール単位の状態です。値は "on" または "off" です。ほとんどのシークレットルールは既定で有効なので、通常使うのは "off" です。"on" は、既定で無効な Coding CLI 設定階層のルールを有効にします。
string[]
デフォルト:"[]"
組み込みの機密パスに加えて、シークレットとして保護するパスです。検証ルールは拒否パスを参照してください。
string[]
デフォルト:"[]"
組み込みのシークレットパターンルールから除外する、特定のファイルまたはディレクトリツリーです。設定した拒否パスと Coding CLI の保護は引き続き適用されます。指定できる形と優先順位はシークレットの許可パスを参照してください。
integer
デフォルト:"30"
スイープで削除されるまで監査履歴を保持する日数です。1 から 365 までの整数でなければなりません。

安全レベルと機能のオーバーライド

safety.level でプリセットを選び、safety.overrides で個別の機能を明示的に設定します。機能を引き下げられるのはここだけです。環境変数は、レベルを引き上げるか機能を強制的に有効にすることしかできません。優先順位の全体は環境変数を参照してください。
この例は paranoid プリセットを使いつつ、インタープリターのワンライナーはブロックしません。機能の組み合わせがどのプリセットにも一致しない場合、有効なレベルは custom と報告されます。

どの許可リストを使うか

ブロックした原因に合わせて設定を選びます。ブロックメッセージにはルール ID が表示されます。 エージェントに作業用フォルダーを自由に使わせたいなら、/tmp などの一時ディレクトリ配下に置きます。一時ディレクトリでは、再帰削除も Git の破棄操作もすでに許可されています。2 つの allow_paths は別々のリストで、一方が他方のルールを緩和することはありません。

破壊的コマンドの保護

ブロックされたコマンドを許可するには、それをブロックしたルールを無効にします。ルール ID の調べ方と変更の確かめ方はブロックされたコマンドを許可するで説明しています。 destructive_command_protection.overrides では、次のように組み込みルールを ID で指定します。
登録されていない ID は unknown destructive command rule id "<id>" で拒否されます。guard.policy-config などの固定の拒否 ID もルールではないため、同じく拒否されます。"on" と "off" 以外の値は destructive_command_protection.overrides.<id> must be "on" or "off" で拒否されます。 致命的なルールは無効にできません。enabled: false も "off" のオーバーライドも無視します。

許可パス

destructive_command_protection.allow_paths に指定したディレクトリは、再帰削除について一時ディレクトリと同じ扱いになります。対象範囲は allow_paths 配下の再帰削除を参照してください。検証は拒否パスより厳格です。

シークレット保護

シークレット保護は、資格情報を含みうるファイルの読み取りと書き込みをブロックします。組み込みルールの ID と、それぞれが保護するパスの一覧はシークレット保護リファレンスにあります。保護されたファイルを許可する方法はブロックされたファイルを許可するを参照してください。 secret_protection.overrides では、組み込みルールを ID で個別に指定し、値に "on" または "off" を使います。"off" は既定で有効なルールを無効にし、"on" は既定で無効な階層のルールを有効にします。
登録されていない ID は unknown secret protection rule id "<id>" で、それ以外の値は secret_protection.overrides.<id> must be "on" or "off" で拒否されます。

既定で無効なルール

Coding CLI 設定ルールは、コーディングエージェントの設定ファイルと MCP ファイルを対象とします。エージェントが通常の作業でこれらのファイルを編集するため、既定では無効です。使うルールごとに、明示的に "on" のオーバーライドを指定してください。ID とそれぞれのパスはシークレット保護リファレンスに一覧があります。

拒否パスで任意のファイルやフォルダーをブロックする

secret_protection.deny_paths に指定したファイルやフォルダーは、シークレットを含むかどうかにかかわらず、エージェントからのアクセスがすべてブロックされます。たとえば、エージェントにシェルのプロファイルを触らせないようにするには次のようにします。
拒否パスは、すべての安全レベルで読み取りと書き込みの両方をブロックします。上の設定では、cat ~/.zshrc も echo x >> ~/.zshrc も secret.deny-path でブロックされます。フォルダーを指定すると、その中身すべてが対象になります。拒否パスが許可パスやオーバーライドで緩和されることはありません。 検証: 拒否パスはシークレット保護の一部なので、secret_protection.enabled: false にすると拒否パスも無効になります。secret.deny-path は登録済みのルール ID ではないため、オーバーライドでは無効にできません。

シークレットの許可パス

secret_protection.allow_paths は、特定のファイル、またはディレクトリとその配下すべてを、組み込みのシークレットパターンルールから除外します。リポジトリの .env.test や、シークレットではないものの資格情報らしいファイルを含むフィクスチャ用ディレクトリなど、意図して置いているファイルに使います。 フォルダー、**/、正確なファイル名の順に並べた形も指定できます。~/code/**/.env.local は、~/code 配下の任意の深さにある .env.local だけを除外します。これ以外の glob の形は指定できません。 優先順位は固定です。
  1. 設定した拒否パスが常に優先します。同じ対象が両方のリストにある場合、結果は secret.deny-path です。
  2. Coding CLI の資格情報ルールと設定ルール(secret.cli.*)が常に優先します。
  3. 許可パスに一致した対象では、その他の組み込みシークレットルールが適用されません。
検証: **/ の項目でフォルダー自体が除外されることはありません。許可パスは、シンボリックリンク経由で到達する対象にも適用されます。

監査ログの保持期間

audit.retention_days は、監査レコードを保持する日数を指定します。既定値は 30、指定できる範囲は 1〜365 です。
範囲外の値を指定するとランタイムは degraded になり、保持期間には最も近い境界値が使われます。整数でない場合は 30 が使われます。スイープがレコードを削除するタイミングは保持期間を参照してください。

無効なポリシーの扱い

policy.json が無効でも、通常の作業がブロックされることはありません。CC Safety Net は有効なフィールドをそのまま使い、無効なフィールドを安全側の既定値に置き換えて、ランタイムを degraded と報告します。ファイルが存在しないことはエラーではありません。CC Safety Net は組み込みの既定値を使い、ランタイムは ready のままです。
CC Safety Net は無効な項目を修復せずに破棄します。書き間違えた拒否パスは、気づかないうちにその場所を保護しなくなります。無効な safety.level は、気づかないうちに standard に下がります。手作業で編集したら、そのつど npx cc-safety-net status を実行してください。
無効な各フィールドのフォールバック先と、ready に戻す方法は設定の復旧にあります。

関連ページ

モード

各安全機能で何が変わるか、ワークツリーモードで何が緩和されるか。

環境変数

すべての環境変数と、各設定ファイルの場所。

カスタムルール

独自のブロックルールを定義する、rule.json とルールブックのスキーマ。

設定の復旧

ready と degraded の違い、フィールドごとのフォールバック、修復の手順。
最終更新日 2026年10月27日