Skip to main content
CC Safety Net には、cc-safety-net という 1 つの CLI があります。npx cc-safety-net または bunx cc-safety-net で実行します。 適用処理は、cc-safety-net install が設定するプラグイン、拡張機能、hook を通して、エージェント内で動作します。CLI 自体をグローバルにインストールする必要はありません。npx または bunx は、ここで説明するコマンドの実行時に CLI を取得します。 このページは、コマンド、サブコマンド、オプション、終了動作をまとめたリファレンスです。初回実行の手順はクイックスタート、エージェントごとの設定はインストールを参照してください。

コマンドの概要

CLI は 12 個のコマンドを登録します。次の順序は、cc-safety-net --help に表示される順序です。 doctor には別名 --doctor もあります。コマンド検索では大文字と小文字を区別しません。
statusstatusline は異なる 2 つのコマンドです。status は人向けの複数行レポートを出力します。statusline はステータスバー向けに、絵文字インジケーターの正確に 1 行だけを出力します。

status

status は、「ランタイムが現在何を適用しているか」という 1 つの質問に答えます。保護を信頼する前に、保護が動作していることを最も速く確認する方法です。

判定

先頭の判定は、次の 2 値のいずれかです。 無効な Claude Code プラグインは、独自の判定ではなくなりました。その 1 つの連携に限定した、Not active リストの最初の項目として報告されます。
~/.claude/settings.json がない、解析に失敗する、enabledPlugins がない、または cc-safety-net@cc-marketplacetrue に設定していない場合、プラグインは無効と見なされます。検査の既定値は無効なので、読み取れない設定ファイルは、有効ではなく無効として扱われます。 判定はポリシースナップショットから取得され、設定から再導出されることはありません。プラグイン検査はその項目を追加するだけで、判定を変更しません。

出力

status は、判定行、整列した情報ブロック、確認または問題のリストを順に出力します。 情報行は 1 行です。長い値は折り返さず、 で切り詰めます。 情報ブロックの後に、statusEverything configured is active.、または Not active セクションを出力します。後者には、問題ごとに折り返した項目があり、該当する場合はプラグイン無効の項目が最初、その後にスナップショット診断が続きます。最後に Full report: cc-safety-net doctor を出力します。 NO_COLOR が設定されている場合、または標準出力が端末でない場合、出力は ASCII のみになります。チェックマークとバツ印の代わりに ok / OFF· の代わりに - を使い、先頭の盾のアイコンも付きません。

終了コード

判定が degraded の場合も含め、status常に 0 で終了します。情報提供専用なので、スクリプトを失敗させません。問題でゼロ以外の終了コードが必要な場合は、doctor を使ってください。

doctor

doctor は、インストールと設定の完全な正常性検査を実行し、セクションに分けたレポートを出力します。
オプション: doctor は、codex plugin list から Codex の状態を読み取ります。CC Safety Net に一致する行に installed, enabled がある場合は Detected かつ Configured です。それ以外の installed, がある一致行は Detected かつ Not configured です。登録済みのマーケットプレイス行が not installed の場合は、無効ではなく Not detected です。 GitHub Copilot CLI では、doctor はプラグインの checkout 状態と hook の定義を確認します。インライン設定の優先順は、<repo>/.github/copilot/settings.local.json<repo>/.github/copilot/settings.json<repo>/.claude/settings.local.json<repo>/.claude/settings.json$COPILOT_HOME/settings.json$COPILOT_HOME/config.json です(COPILOT_HOME の既定値は ~/.copilot)。さらに、<repo>/.github/hooks/*.json$COPILOT_HOME/hooks/*.json も調べます。.claude ファイルのエントリは、コマンドに hook --copilot-cli または hook -cp がある場合だけ対象です。Claude Code 用の hook だけでは対象になりません。インライン設定には GitHub Copilot CLI 1.0.8+、ユーザー hook ファイルには 0.0.422+ が必要です。 doctor1 で終了するのは、エンジンのセルフテストが失敗した場合と、Findings セクションに error 重大度の finding が 1 つでもある場合です。それ以外は 0 で終了します。警告は終了コードに影響しません。次の finding は error 重大度です。
  • エージェント連携が設定されていません。
  • hook の検査に失敗しました。
  • ユーザーまたはプロジェクトのルール設定が無効です。
  • policy、config、audit のいずれかのディレクトリが安全ではありません。現在のユーザーの所有ではない、グループまたはその他のユーザーに書き込み権限がある、シンボリックリンクである、ディレクトリではない、のいずれかに当てはまる状態を指します。
以前のバージョンが残した rule.lock ファイルまたは cache ディレクトリがあると、info 重大度の finding config.v2-leftovers(タイトルは Rulebook lock and cache leftovers detected)が発生します。ランタイムはどちらももう読み取りません。修正ヒントは Run `cc-safety-net rule sync` (add `--global` for user scope) to migrate them, then rerun doctor. です。info の finding は終了コードに影響しません。 一部の監査ログファイルを読み取れない場合、Recent Activity セクションの末尾に Warning: <n> audit log sources could not be read; this summary is incomplete が表示されます(1 件の場合は source)。これにより、操作が少ない週を完全なデータと誤認しません。

管理対象 hook の設定ずれ

Cursor と Grok Build は、hook のエントリを手で編集できる設定ファイルに保持します。そのため doctor は、ディスク上のエントリと、インストールが書き込むエントリを比較します。ずれているエントリも、管理対象のエントリであることに変わりはありません。エージェントは Configured のままで、一致しなかった項目ごとに Warning (<Agent>): <message> を出力し、終了コードも変わりません。インストールを実行し直せば、エントリは書き直されます。 Antigravity CLI には、ずれの検査がありません。doctor は正規のエントリと比較するのではなく、コマンドのパターンで hook を照合します。そのため Detected かつ Configured と報告し、hook の定義に enabled: false がある場合は Detected かつ Not configured と報告します。 hook の設定ファイルをパースできない場合は、3 つとも結果が変わります。検出の段階で管理対象のエントリが見つからないため、そのエージェントは未設定として数えられ、Discovery、Configuration、Inspection の各列は UnknownUnknownFailed になります。メッセージも、警告ではなくエラーとして赤で表示されます。
  • Error (Antigravity CLI): Failed to parse Antigravity hooks config <path>: <reason>
  • Error (Cursor): Failed to parse Cursor hooks config <path>: <reason>
  • Error (Grok Build): Failed to parse Grok Build hooks config <path>: <reason>
いずれの場合も <Agent> inspection failed の finding が error 重大度で発生するため、doctor1 で終了します。

logs

logs は、1 つの許可またはブロックされたコマンド判定を 1 レコードとして、監査ログを読み取ります。
既定では、logs はすべてのプロジェクトについて、過去 30 日間の最新の拒否 20 件を出力します。許可判定も含めるには --all を指定します。

フィルターとオプション

--suspect は、再確認する価値がある拒否に結果を絞ります。failureStage を持つ拒否(解析に失敗し、ガードが fail closed になったため、コマンドが危険だと証明されたわけではない)、または同じセッション内で同じコマンド署名が 2 回以上拒否された場合です。繰り返し回数は、--limit で出力を切り詰める前に、--since の期間全体で数えます。 同時に使えない組み合わせ。 次の 2 つは、明示的なメッセージと終了コード 1 で拒否されます。
  • --id は、--agent--rule--session--project--suspect--since--limit と同時に使えません。
  • --prune-legacy は、--id--agent--rule--session--project--suspect--all--since--limit と同時に使えません。一緒に使えるフラグは --json--dry-run だけです。
--dry-run だけを指定することも拒否されます。--dry-run requires --prune-legacy を出力し、1 で終了します。 認識しないオプションは Unknown option for logs: <arg> を出力し、1 で終了します。 監査ログファイルを読み取れない場合、またはレコードが不正な場合、logs は標準エラー出力に 1 つの警告 warning: <n> audit log sources could not be read; these results are incomplete を出力します(1 件の場合は source)。標準出力と終了コードは変更しません。

機械可読出力

人向けの出力では、エントリごとに ID、タイムスタンプ、判定、エージェント、ルール ID、50 文字に切り詰めたコマンドを 1 行で出力します。完全なコマンドと異なるセグメントには が付きます。--id は、代わりにレコードのすべてのフィールドを含むラベル付き詳細ブロックを出力します。

logs —prune-legacy

logs --prune-legacy は、監査ルートにあるすべてのレガシーのルートレベル *.jsonl ファイルを即時かつ元に戻せない形で削除します。確認プロンプトも --yes もありません。削除対象を確認するには、先に --dry-run を追加してください。経過時間と内容は関係ありません。対象かどうかはファイルの場所だけで決まります。
ネストされたプロジェクトごとの監査ログには触れません。コマンドは実行後にそのことを表示します。すべての削除に成功すると 0、いずれかのファイルを削除できないと 1 で終了します。削除対象がない状態で再度実行すると、何もしません。 --dry-run では何も削除しません。コマンドは Would remove <n> legacy audit log files (<size>).、または No legacy audit log files found. を出力し、次に Nested v2 audit logs are not included. を出力します。削除対象がある場合は、Run the same command without --dry-run to delete them. も出力します。常に 0 で終了します。--json と一緒に使うと、代わりに 1 つのコンパクトオブジェクト {"dryRun":true,"files":n,"bytes":n} を出力します。 レガシー配置と現在の配置の違いについては、監査ログを参照してください。

explain

explain は、CC Safety Net がコマンドを解析する方法を手順ごとにトレースします。コマンドがブロックまたは許可される理由、カスタムルールが適用される方法を確認するために使います。
オプション: -- はフラグ解析を終了します。その後にあるすべてのものがコマンドです。残りの引数が 1 つなら、シェル演算子を維持するため、そのまま使います。複数の引数は再度引用します。 例:
オプションの解析に成功した後、explain はブロックと許可のどちらの結果でも 0 で終了します。終了コードではなく result フィールドを読んでください。1 で終了するのは次の 2 つの場合です。1 つはオプションの検証です。
  • 不明なオプションは Unknown option for explain: <arg> を出力します。値がない --cwd--cwd requires a value を出力します。どちらの解析エラーにも Usage: cc-safety-net explain [--json] [--cwd <path>] <command>Pass -- before a command that starts with dashes. が続き、1 で終了します。
  • 存在しない --cwd パスは Error: --cwd path does not exist: <path> を出力し、1 で終了します。
  • 空のコマンドは Error: No command provided と使用方法の行を出力し、1 で終了します。
もう 1 つは解析の上限です。構造的なコマンド解析の上限、パス正規化の上限、ツール入力の走査上限のいずれかを使い切ったコマンドは、スタックトレースではなく 1 行のエラーメッセージを出力して 1 で終了します。--json では標準出力全体が 1 つのエラーオブジェクトになり、それ以外の場合はメッセージを標準エラー出力に書き出します。
最上位パーサーも同じ方法で -- を処理します。最初の ----help--version の検索を停止します。そのため、explain -- --help はヘルプを出力せず、リテラルコマンド --help を explain します。
explain の出力は、そのまま安全に共有できるとは限りません。入力したコマンド、解析後のトークン、ホームディレクトリを含む絶対パスがそのまま表示されます。Issue やチャットにトレースを貼り付ける前に、explain トレースを確認してください。
--json が返す JSON のスキーマ、つまり ExplainResult のフィールドと TraceStep の全種類については、explain トレースリファレンスを参照してください。

rule

rule は、ルール設定、rulebook の設定元、transparent wrapper を管理します。このセクションではコマンドインターフェースを説明します。rulebook のスキーマ、ライフサイクル、override の意味については、カスタムルールを参照してください。 サブコマンドなしで rule を実行すると、ヘルプを出力して 1 で終了します。rule --help は同じヘルプを出力して 0 で終了します。 オプション: --check は受け付けなくなりました。どのサブコマンドでも Unknown option for rule <subcommand>: --check として拒否されます。rulebook は毎回ディスクから読み込まれるため、addupdate のドライランに意味を持たせるには、結局その候補を取得して検証するほかありません。オフラインでの検証には rule verify を使います。

rule init

現在のスコープにルール設定を作成します。ファイルが存在する場合は、rulesoverridestransparent_wrappers を維持したまま、正規形式に書き換えます。キャッシュディレクトリは作成しません。
rule init だけを実行すると、ルールを含まない非アクティブな設定を書き込みます。example-rules という開始用 rulebook も書き込むには、--example を指定します。
サンプル rulebook は、example-rules/rulebook.json が存在しない場合にのみ書き込まれます。設定から参照されないため、非アクティブです。有効にするには、rule add example-rules で追加します。 書き込み後、rule init はガードと同じ方法でスコープを読み込みます。エラーがあれば出力して 1 で終了します。問題がなければ Rule config initialized. を出力して 0 で終了します。

rule add

使用方法は rule add [source] [--ref <ref>] [--only <rulebook...>] です。設定元には 3 つの形式があります。project-rules のような裸のローカル名、acme/safety-rules のようなリポジトリ全体、owner/repo#ref/<rulebook-name> という正規形式で指定する単一の rulebook です。 オプション: 例:
設定元を指定せずに --ref または --only を渡すと、公式カタログの cc-safety-net/rulebooks が設定元になります。どちらのフラグもない rule addrule add requires a source (pass --only <rulebook...> to select from cc-safety-net/rulebooks) を出力して 1 で終了します。そのため、公式 rulebook をすべて追加する場合は、これまでどおり rule add cc-safety-net/rulebooks と明示する必要があります。 他のサブコマンドと同様に、-g / --global でユーザースコープを選択します。 リポジトリを設定元に指定した場合、rule add は書き込みの前に ref をコミットへ解決し、そのコミット時点のリポジトリにある .cc-safety-net/rules/<name>/rulebook.json をすべて列挙します。--only がなければ、それらを名前順ですべて追加します。--only を指定すると、指定した順序で該当する rulebook だけを追加し、重複は無視します。リポジトリに存在しない名前を指定すると、追加は失敗します。 --ref--onlyowner/repo 形式の設定元にのみ指定できます。それ以外では --ref can only select a ref for an owner/repo source: <source> または --only can only select rulebooks from an owner/repo source を出力します。--ref を省略した場合、rule add はリポジトリの既定ブランチを使います。ref には / を含むセグメントを指定できるため、--ref feature/rulebook-v2 は有効です。ref 全体が ^[A-Za-z0-9._-]+(?:/[A-Za-z0-9._-]+)*$ に一致する必要があり、一致しない場合は --ref must use valid path segments: <ref> を出力します。 rule.json には、指定した ref を含む正規形式 owner/repo#ref/<rulebook-name> が保存されます。rule add は解決されたコミットを出力しますが、保存はしません。 追加に成功すると、まず Scope: project (<config dir>) を出力します。--global を付けた場合は Scope: user (<config dir>) で、いずれも書き込んだ rule.json があるディレクトリを示します。この行がなければ、誤ったディレクトリで実行した追加も成功に見えてしまいます。失敗した追加は何も書き込んでおらず、スコープの行も出力しません。 リポジトリを追加した場合は、続けて次の順序で出力します。
  • Added <n> rulebooks from <source> at <ref>:(1 件の場合は rulebook)に続けて、rulebook ごとに - <name> の行
  • 選択した rulebook のうち rule.json にすでにあったものについて Rulebooks already configured from <source> at <ref>: <names>
  • Vendored at <commit>.。解決されたコミットを先頭 7 文字に短縮したもので、新しい設定元を 1 つ以上書き込んだ場合にのみ出力される
  • 書き込んだファイルごとに 1 ブロック。新規ファイルは Vendored <spec> (<version>)、既存ファイルの更新は Updated <spec> (<before> -> <after>) に続けて、追加・削除・名前は同じで内容が変わったルールをそれぞれ + <rule> - <rule> ~ <rule> の行で表示
  • Rule config updated.、空行、Active rulebooks (<n>):。各エントリは - <name> <version> (<n> rules) Source: <spec>
裸のローカル名または正規形式 owner/repo#ref/<rulebook-name> の設定元では、スコープの行はそのまま出力され、上記の最初の 3 項目は省かれます。リポジトリ追加で Rule config updated. が出る位置には、Added rulebook source: <source> が出力されます。

rule remove

rulebook の設定元を削除して同期します。ローカルの設定元ディレクトリの中身が rulebook.json だけの場合に、そのディレクトリも削除するには --delete-source を追加します。
--delete-source は、ディレクトリの中身が rulebook.json だけであることを 2 回確認します。1 回目は同期の前、2 回目は削除の直前です。その間の同期で、GitHub からの取得を待つことがあるためです。
  • その間に別のプロセスがファイルを追加した場合、2 回目の確認が削除を拒否し、Local rulebook source directory contains extra files: <dir>. delete manually if you really want to remove the directory. を出力します。設定の変更はロールバックされて再同期されるため、削除しようとした設定元は元に戻ります。
  • 削除は再帰的ではありません。検証済みの rulebook.json を削除してから、非再帰の rmdir でディレクトリ自体を削除します。unlink の後にファイルが追加されると rmdir が失敗し、そのファイルはそのまま残ります。削除されるのは rulebook ファイルだけです。
  • 削除の時点でディレクトリがすでにない場合は、削除をスキップして成功として報告します。求められた最終状態に達しているためです。

rule update

すべての設定元について、リモート rulebook を再取得して取り込みます。設定元を 1 つ指定した場合は、その設定元だけを対象にします。
実行のたびにブランチとタグの ref を解決し直すため、main や移動するタグを指している設定元は現在のコミットを取り込みます。ローカルの設定元には取得するものがありません。設定元はすべてレポートに現れますが、再取得されるのは選択した設定元だけで、残りはディスク上のファイルから読み込まれます。出力される変更ブロックは rule add と同じで、その後に Rule config updated. とアクティブな rulebook の一覧が続きます。 各設定元は独立して更新されます。取得や検証に失敗した設定元は、すでに取り込んである内容をそのまま保持し、Failed to update <spec>: <message> として報告されます。更新に成功した他の設定元は書き込まれます。1 つでも失敗した場合は 1、それ以外は 0 で終了します。 例外はリソース制限による失敗です。GitHub の取得予算を使い切った実行は Rule synchronization exceeds CC Safety Net's safe resource limits. を出力して停止し、上限に達した設定元だけでなく、その実行に含まれるすべての設定元が失敗します。

rule sync

rule sync は非推奨です。rulebook はライブファイルであり、同期するものはありません。この実行は、以前のバージョンが書き込んだ rule.lock ファイルと cache ディレクトリをオフラインで移行し、その後どちらも削除します。
実行は必ず次の非推奨の通知から始まります。
ネットワークからは何も取得しません。記録されたダイジェストと一致するキャッシュのコピーは <config-dir>/<name>/rulebook.json に書き込まれ、Vendored <spec> from the v2 cache. として報告されます。書き込み先のファイルは存在するものの使用できない場合は、Restored <spec> from the v2 cache over an invalid file. になります。キャッシュから復元できない設定元については Could not migrate <spec> from the v2 cache. Run `cc-safety-net rule update <spec>` to vendor it. を出力します。ユーザースコープでは、このコマンドに --global が付きます。最後の行は Removed the v2 lock and cache under <dir>. です。 移行するものがない場合は、No v2 lock or cache leftovers found in <dir>; nothing to migrate. を出力して 0 で終了します。これらのファイルが残っているのにスコープの rule.json が存在しないか読み取れない場合は、設定元の唯一の記録を失わないように移行を拒否し、Cannot migrate: the rules config in <dir> is missing or unreadable while v2 leftovers remain. Restore rule.json, then re-run rule sync. を出力して 1 で終了します。 doctor は、残っているこれらのファイルを info 重大度の finding config.v2-leftovers として報告します。

rule list

ユーザースコープとプロジェクトスコープの両方について、有効な rulebook と解決済みの設定元を一覧表示します。
rule list は両方のスコープを一度に読み取るため、--global は拒否されます。ポリシーのエラーがある場合だけ 1 で終了します。警告は出力されますが、終了コードは 0 です。 Active rules では、どのルールも Command: の行と Reason: の行を出力します。その間の行は、ルール自身の rulebook のバージョンによって変わります。バージョン 1 のルールは、サブコマンドを設定していれば Command:<command> <subcommand> を表示し、ブロック対象の引数を Block args: に表示します。rulebook_version: 2 のルールは、Command: にコマンド名と match.command_path の語を並べて表示し、設定されているものだけ Any args: Exclude args: を出力します。Block args: の行は出力しません。

rule wrapper

transparent wrapper を管理します。これは引数を別のコマンドへ渡すコマンドであり、CC Safety Net はラッパー自体ではなく内部のコマンドを解析します。
  • 操作の指定は必須で、addremovelist のいずれかでなければなりません。
  • wrapper list は追加の引数を受け取りません。Transparent wrappers: (none) または番号付きリストを出力します。
  • wrapper addwrapper remove は、それぞれ正確に 1 つのコマンド名が必要です。
  • ラッパー名は ^[a-zA-Z][a-zA-Z0-9_-]*$ に一致する必要があります。予約済みコマンドはラッパーとして登録できません。
  • add は重複を除去し、remove はフィルタリングします。スコープは -g / --global に従います。
登録済みのラッパーは、explain トレースtransparent-wrapper のステップとして表示されます。

rule verify

レガシーパスとスキーマ種類の検出を含め、両方のスコープのルール設定ファイルを検証します。設定を手動で編集した後に使います。
すべて有効なら 0、それ以外はゼロ以外で終了します。 rule verify は純粋な検査ではなく、検証するファイルを変更することがあります。スコープの rule.json が正常に検証されても $schema キーがない場合、コマンドはそのファイルを書き換え、次の内容を最初のキーとして挿入します。
そして Added $schema to user config. または Added $schema to project config. を出力します。これは、ユーザースコープまたはプロジェクトスコープにある有効な rules-schema 設定でのみ動作します。レガシー設定またはエラーがある設定では動作しません。無効にするフラグはありません。書き換えはファイル全体を 2 スペースのインデントで再シリアライズします。そのため、CI では追跡対象ファイルに変更が残る場合があります。rule verify を読み取り専用にする必要がある場合は、先に $schema キーをコミットしてください。

rule migrate

レガシーのインライン設定ファイル、プロジェクトの .safety-net.json とユーザーの ~/.cc-safety-net/config.json を、rulebook 配置に変換します。
--cleanup は、移行したルールの検証後にレガシーファイルを削除します。migrate は、--global と 2 つ目の位置引数を拒否します。

rule doc

rulebook の作成ガイドを標準出力に出力します。このガイドをエージェントにパイプで渡せば、rulebook の作成と検証を任せられます。
ガイドを出力した後、rule doc は npm レジストリに新しいバージョンがあるかを確認します。確認は 24 時間に 1 回までで、結果は ~/.cc-safety-net/update-check.json にキャッシュされます。新しいバージョンがある場合は、標準エラー出力にちょうど 1 行だけ出力します。
ガイド自体は標準出力に出るため、パイプで渡す内容が混ざることはありません。同じバージョンについては 7 日間、再通知されません。この確認を完全に無効にするには CC_SAFETY_NET_NO_UPDATE_CHECK を設定します。レジストリへの問い合わせが失敗しても通知はされず、いずれの場合も終了コードは 0 のままです。

policy

policy は、ポリシーの提案を検査して適用します。ポリシーファイルが持つフィールドと、それぞれの意味はポリシーを参照してください。 オプション: 例:
対象は、プロジェクトの .cc-safety-net/policy.json です。--global を指定した場合はユーザーポリシーファイルになります。

出力

どちらのサブコマンドも、apply が書き込む前に同じレポートを出力します。
--global を指定した場合、1 行目は Scope: user (<path>) になります。プロジェクトスコープでは、ユーザーポリシーとプロジェクトファイルをマージした実効ポリシーについて、適用前と適用後を比較します。この差分は Effective policy (user + project merged): の見出しの下に並びます。設定したフィールドだけを持つ提案でも、セッションが実際に動作するレベルは変わります。そのため差分は、ファイル自体の内容ではなくその変化を報告します。safety.level を設定すれば実効レベルが下がるか上がり、設定しなければユーザーポリシーから継承したレベルに戻ります。ユーザースコープでは、ユーザーポリシーファイル自体を比較し、この見出しは出力しません。差分がない場合の出力は No changes. の 1 行だけです。片側に値がない行は (unset) と表示されます。 check は差分を出力した時点で終了し、終了コードは 0 です。 差分を出力する前に標準エラー出力へ書き出され、1 で終了するエラーは次のとおりです。Unknown option for policy: <arg>Unknown policy subcommand: <name>policy <subcommand> requires a fileUnexpected policy argument: <arg>。監査設定はユーザースコープ専用のため、audit セクションを含むプロジェクト向けの提案も同じように拒否されます。

適用

apply は stdin と stdout の両方が TTY であることを要求します。TTY でない場合は、自分で実行するためのコマンドを出力して 1 で終了します。
--global を指定していた場合は、出力されるコマンドにも --global が付きます。 ターミナルでは、applyApply this policy to <path>? [y/N] と確認します。確認とみなされるのは、大文字小文字を問わず y または yes だけです。それ以外は、プロンプトでの EOF も含めてすべて拒否として扱われ、Cancelled; nothing was written. を出力して 0 で終了します。確認して適用した場合はファイルを書き込み、Policy applied: <path> を出力して、同じく 0 で終了します。プロジェクトへの適用では、提案が設定しているフィールドだけが書き込まれます。省略したフィールドは、引き続きユーザーポリシーを継承します。
--yes はなく、非対話モードもありません。提案を適用する方法は、ターミナルでプロンプトに答えることだけです。
エージェントが policy apply を実行した場合、ガードは intent hard_stop と次の理由で拒否します。
policy check は許可されたままです。エージェントは提案を作成し、その差分を提示するところまでは実行できます。

install

install は、CC Safety Net をコーディングエージェント CLI にインストールします。ターゲットセットは CC Safety Net の連携カタログから取得されるため、GUI と doctor が使うリストと同じです。 エージェントごとの手順、インストール後の操作、レガシープラグイン ID の移行については、インストールを参照してください。

ターゲット

13 個のターゲットを使用できます。次の順序はインストールされる順序です。

インストールの仕組み

CC Safety Net は、3 つのインストール方法を使います。
  • ネイティブのプラグインまたは拡張機能のコマンド:Claude Code、Codex、GitHub Copilot CLI、Gemini CLI、OpenClaw、OpenCode、Pi。CC Safety Net はエージェント自身のプラグインマネージャーを実行し、置き換えられた古いプラグイン ID を削除します。OpenClaw のインストールは、その後に OpenClaw がプラグインを読み込み済みと報告することも確認し、OpenClaw Gateway の再起動を求めます。OpenCode のインストールは、キャッシュ済みパッケージのエントリを import し、呼び出し可能な CCSafetyNetPlugin を export することを確認します。OpenCode が何も読み込まず fail open になる場合、インストールは失敗します。
  • 設定ファイルへの書き込み:Antigravity CLI、Cursor、Grok Build、Kimi Code。CC Safety Net がエージェントの設定を直接編集するのは、この 4 つだけです。
  • 管理対象プラグイン成果物:Amp Code と Hermes Agent。Amp のプラグインは、amp CLI を通じてアカウントのホスト型 Amp Personal Plugins リポジトリに公開されます(事前確認は amp plugins repositories --json)。そのため、インストールには amp CLI と amp login が必要です。公開されたプラグインは、Orb スレッドを含むすべての Amp セッションに適用されます。~/.config/amp/plugins/cc-safety-net.ts に管理対象のローカルコピーが残っているとパーソナルプラグインを覆い隠すため、インストール時に削除されます。変更後は Amp を再起動するか plugins: reload を実行します。Hermes Agent では、インストール時にプラグインをディスクに書き込んで hermes plugins enable も実行し、変更後に Hermes の再起動が必要です。
Antigravity CLI、Cursor、Grok Build、Kimi Code の設定ファイルへのインストールと、Hermes Agent へのインストールでは、何かを書き込む前に npx キャッシュから古い cc-safety-net を削除します。npm キャッシュの _npx ディレクトリ($npm_config_cache が設定されている場合はその場所。それ以外は macOS と Linux で ~/.npm、Windows で %LOCALAPPDATA%\npm-cache)の下にあり、node_modulescc-safety-net を含むすべてのエントリを削除します。この 5 つの連携は npx で hook を実行するため、この処理により、新しくインストールした hook はキャッシュ済みのバージョンではなく最新版を解決します。 Kimi Code には 2 つのインストール方式があります。 ターミナルで install --kimi-code を実行するか、ピッカーで Kimi Code を選択すると、単一選択プロンプトが開きます。グローバル hook を今インストールするか、代わりにネイティブ Kimi プラグインの手順を表示するかを選びます(Kimi Code 内で /plugins install https://github.com/kenryu42/cc-safety-net を実行し、次に /reload を実行するか新しいセッションを開始します。信頼プロンプトの既定はキャンセルです)。プラグイン方式を選んでも何も書き込まれず、手順を表示するだけです。非対話セッションではプロンプトをスキップして、グローバル hook を直接インストールします。このプロンプトがプラグイン手順への唯一の経路であるため、グローバル hook が設定済みでも install 時の Kimi Code の行は選択可能なままで、(global hook installed) と表示されます。

ターゲットの選択

  • フラグなしの対話型ターミナル: 矢印キーを使う複数選択プロンプトが表示されます。各ターゲットの使用可否を調べます。そのため、エージェントがインストールされていない場合は CLI not installed、設定済みの場合は already installed、uninstall 時に未設定の場合は not installed と表示されます。Windows では、この使用可否の検査もインストール自体も npm の .cmd シムをシェル経由で解決するため、npm でインストールした CLI が CLI not installed と表示されることなく検出されます。
  • ターゲットフラグあり: 正確に 1 つのターゲットフラグを指定します。複数指定すると Choose exactly one install|uninstall target: の後に完全なフラグリストを表示します。不明な - 引数と余分な位置引数もエラーです。
セレクターのキーバインドはフッターに表示されます。install 時のフッターは次のとおりです。
Space は強調表示したターゲットの選択を切り替えます。Enter は確定します。何も選択されていない場合はターミナルベルを鳴らすだけです。Up / Down または k / j は、選択可能な行の間を移動します。install 時に u(または U)を押すとセレクターを終了して update フローを実行します。uninstall のフッターにはこのキーがありません。q または Esc で終了すると、Cancelled: nothing was installed.(または Cancelled: nothing was uninstalled.)を出力し、0 で終了します。終了は判定であり、失敗ではありません。一方、Ctrl-CSIGINT を送出するため、通常の中断されたプログラムと同じ方法でプロセスが終了します。 選択したターゲットは、選択した順序ではなく、常にカタログのインストール順で実行されます。ターミナルでは、各ターゲットは Installing <name> integration… または Uninstalling <name> integration… というスピナーの後ろで実行され、スピナーが止まった後にレポートが表示されます。TTY でない場合、スピナーはありません。120 秒経っても終わらないホスト CLI のコマンドは強制終了され、失敗として報告されます。失敗すると、権限問題、パス不足、ディレクトリではないパス要素など、エラー固有のヒントとともに 1 で終了します。

update

update は、インストール済みのすべての連携を更新します。新しい連携をインストールすることはありません。設定していないエージェントには触れません。
TTY で update を直接実行すると、インストールバナーを表示する前に検出を開始するため、バナーのアニメーション中にも検出が進みます。バナーの後も検出が続く場合は、Checking installed integrations… を表示します。Enter を押すとアニメーションをスキップできます。対話型の install セレクターで u を押して update を開始した場合、すでに表示したバナーを使い、2 つ目のバナーは表示しません。TTY でない場合、バナーとスピナーは表示しません。 ターゲットは、各エージェントの設定ファイルと状態ファイルを読み取って検出します。現在無効な場合でも、インストール済みと検出される連携が対象です。Amp Code は amp plugins list の出力によって対象になります。この出力は、codex plugin list と同じく 30 秒のタイムアウトで取得します。コールドラン時は checkout をネットワーク経由で更新するため、既定の 5 秒を超えることがあるからです。GitHub Copilot CLI は例外です。Copilot の installed-plugins ディレクトリに CC Safety Net プラグインの checkout がある場合だけ対象になります。無効状態と、何もインストールされていない kill-switch 状態を区別できず、update が install になることを防ぐためです。改名前の safety-net@cc-marketplace プラグイン ID を使うインストール(Claude Code、Codex、および GitHub Copilot CLI のプラグイン checkout cc-marketplace/safety-net)も検出されます。更新時に現在の ID へ移行し、レガシーコピーをベストエフォートで削除します。レガシーコピーの削除に失敗しても、ターゲットは失敗せず警告になります。 すべてのターゲットは、1 つの Updating <n> integration… または Updating <n> integrations… スピナーの後ろで、install と同じ操作を並列に実行します。すべてのターゲットが完了した後、レポートを安定したカタログ順でまとめて出力します。メッセージだけが Updated … または … up to date に変わります。インストール時にエージェント自身の CLI を使うターゲットでは、先にベンダーバイナリを調べます。対象は Claude Code、Codex、GitHub Copilot CLI、Gemini CLI、Hermes Agent、OpenClaw、OpenCode、Pi です。バイナリがない場合は <Agent> not found; skipped(例は Codex not found; skipped)を出力して処理を続けます。設定ファイルを使うターゲット、つまり Antigravity CLI、Cursor、Grok Build、Kimi Code にはバイナリが不要で、常に更新されます。Amp Code には別途の検査は不要です。amp plugins list がパーソナルプラグインを表示する場合にのみ検出され、その更新は amp CLI を実行して現在の成果物を公開します。Claude Code、Codex、GitHub Copilot CLI では、登録済みのマーケットプレイスをプラグイン処理の前に更新します(例は claude plugin marketplace update cc-marketplace)。何もしない add に頼らないため、古いカタログ checkout が更新を失敗させることはありません。 並列処理の前に、キャッシュに依存するターゲット(Antigravity CLI、Cursor、Grok Build、Hermes Agent、Kimi Code)が 1 つでもある場合、updatenpx キャッシュを 1 回消去します。消去に失敗した場合、そのキャッシュに依存するターゲットだけが失敗し、ほかのターゲットは実行を続けます。 bunx キャッシュの消去は無条件です。bunx cc-safety-net は連携ではなくユーザー自身が実行するものなので、対象の連携が 1 つも見つからない実行も含め、update は毎回このキャッシュから自分の cc-safety-net のエントリを消去します。 bunx は各パッケージを、OS の一時ディレクトリの下に bunx-<uid>-<package>@<version-or-latest> という名前でインストールします。消去の対象はこの名前で判定します。macOS と Linux では、自分の uid と一致するものだけが対象です。Windows では %TEMP% がユーザーごとに分かれているため、任意の数値 ID が対象になります。末尾の @ があるため、cc-safety-net-* のような似た名前は対象になりません。実行中のプロセス自身のエントリは対象から除外されます。そのため、bunx から起動した update が自分のファイルを削除することはありません。除外されたエントリは、bun 自身のマニフェスト TTL によって再解決されます。消去に失敗した場合は、エラーを出力して 1 で終了します。 対象がない場合、updateNo installed integrations found. Run `cc-safety-net install` to set one up. を出力して 0 で終了します。この実行が 1 で終了するのは、bunx キャッシュの消去に失敗した場合だけです。 npm レジストリに新しいリリースがある場合、update は最後にベストエフォートで次の案内を出力します。
この案内は、永続的にインストールした CLI に向けたものです。npxbunx での実行は一時的なもので、上記のキャッシュ消去によってすでに最新版に更新されるため、レジストリの確認自体をスキップします。一時的な実行かどうかは、パスに _npx のセグメントがあるか、bun の実際のキャッシュ名 bunx-<digits>- に一致するセグメントがあるかで判定します。数字を伴わない bunx- を含むだけのパス(たとえば /opt/bunx-tools)は永続的なインストールとして扱われ、案内が出ます。確認に失敗した場合、オフラインの場合、開発ビルドの場合は、何も出力されず終了コードも変わりません。 update はターゲットフラグも引数も受け取りません。使用できるのは -h / --help だけです。ほかのオプションは Unknown option for update: <flag>、位置引数は Unexpected argument for update: <arg> を出力し、どちらも 1 で終了します。1 つのターゲットが失敗しても実行は止まりません。エラーは install と同じヒントとともに表示され、update は残りのターゲットを続行し、いずれかのターゲットが失敗していれば最後に 1 で終了します。それ以外の終了コードは 0 です。 対話型の install セレクターで u を押して、update フローへ移ることもできます。

uninstall

uninstall は、install と同じ 13 個のターゲットフラグを受け取り、同じ選択ルールとターゲット順序を使います。
設定ファイルを使うターゲットでは、uninstall は CC Safety Net が管理するエントリだけを削除します。エントリは CC Safety Net 固有の hook コマンド文字列で照合され、ファイル内のほかのものは変更しません。

hook

hook は、CC Safety Net をエージェントのランタイム hook として実行します。エージェントの hook 入力を標準入力から JSON として読み取り、そのエージェントの拒否形式を出力します。通常は手動で実行しません。エージェントのプラグインまたは設定が接続します。保護の背後にあるコマンドです。 hook には正確に 1 つの連携フラグが必要です。フラグがない場合、または複数ある場合は、hook requires exactly one integration flag. Try: cc-safety-net hook --kimi-code とコマンドヘルプを表示し、1 で終了します。 Amp Code、OpenClaw、OpenCode、Pi には、独自の hook フラグがありません。いずれも、プラグインまたは拡張機能として CC Safety Net をプロセス内に読み込みます。各エージェントの接続方法については、連携アーキテクチャを参照してください。
hook install または hook uninstall サブコマンドはありません。インストールは最上位の installuninstall コマンドが処理します。

Antigravity CLI エントリーポイント

install --agy-cli は、コマンド npx -y cc-safety-net hook --agy-cli~/.gemini/config/hooks.json に書き込みます。Antigravity は .gemini ディレクトリを共有します。管理対象エントリの名前は cc-safety-net で、30 秒のタイムアウトを持つ PreToolUse のコマンド hook を登録します。install は、ファイルがない場合は作成し、無効な管理対象エントリがある場合は再度有効にし、それ以外は新しいエントリを追加します。uninstall は、コマンドが管理対象の文字列と一致するエントリだけを削除します。 実行時に、hook は Antigravity の run_command ツール呼び出しを読み、conversationId からセッション ID を取得し、{ "decision": "deny", "reason": … } で拒否します。

Cursor エントリーポイント

install --cursor は、コマンド npx -y cc-safety-net hook --cursor~/.cursor/hooks.jsonhooks.preToolUse に書き込みます。"version": 1 のドキュメントで、30 秒のタイムアウトと failClosed: true を設定します。インストーラーはドキュメントのバージョンと形式を検証し、認識できないものを書き換えず、説明付きエラーで失敗します。重複する管理対象エントリは 1 つにまとめられます。 実行時、hook は Cursor の Shell ツール呼び出しを読み取り、conversation_id からセッション ID を取得して、{ "permission": "deny", … } または { "permission": "allow" } を返します。Cursor の working_directory フィールドは、ワークスペースのルート内に収まっているかを検査されます。宣言されているのに値がない場合、またはワークスペースのルートの外を指す場合は fail closed になります。

Grok Build エントリーポイント

install --grok-build は、コマンド npx -y cc-safety-net hook --grok-build~/.grok/hooks/cc-safety-net.jsonGROK_HOME が設定されている場合は $GROK_HOME/hooks/cc-safety-net.json)に書き込みます。30 秒のタイムアウトを持ち、マッチャーのない PreToolUse エントリです。そのため run_terminal_command だけでなく、すべてのツール呼び出しが hook に届きます。install が書き換えるのは管理対象のエントリだけです。管理対象外のエントリ、同じエントリ内の管理対象外のハンドラー、ほかの hook イベントはそのまま残ります。パースできないファイルは、正規の内容に修復します。Grok Build はパースできない hook ファイルを丸ごと読み飛ばすため、そのようなファイルが動作する管理対象外の hook を保持していることはないからです。uninstall は管理対象のハンドラーだけを取り除き、ファイルを削除するのは、ほかに何も残らない場合だけです。 実行時、hook は Grok Build の camelCase の入力(toolNametoolInputsessionIdcwdworkspaceRoot)を読み取ります。コマンドツールは run_terminal_command だけで、そのシェルの方言は自動判定します。セッション ID は sessionId から取得し、Grok Build が読み取る唯一の形式である { "decision": "deny", "reason": … } または { "decision": "allow" } を返します。toolInputTruncated: true は fail closed になります。Grok Build はツール入力を 128 KB で切り詰めるため、切れたコマンドは解析できないからです。信頼するルートは workspaceRoot で、workspaceRoot がない場合は cwd です。cwd は、正規化した結果がそのルートの内側のディレクトリでなければなりません。cwd がない場合や空の場合は . として扱います。ルートを正規化できない場合、または cwd がルートの外を指す場合は fail closed になります。

gui

gui は、ローカルのポリシーエディターを起動し、ブラウザーで開きます。ダッシュボードのビューと確認動作については、ダッシュボードを参照してください。

オプション

gui が受け取る引数は --no-open だけです。ほかの引数は、オプションなら Unknown option for gui: <arg>、位置引数なら Unexpected argument for gui: <arg> というエラーを出力し、次に Usage: cc-safety-net gui [--no-open] を出力して 1 で終了します。 サーバーは常に先に起動し、フラグの有無に関係なく、URL は常に CC Safety Net policy GUI: <url> として出力されます。--no-open はブラウザーの起動だけを抑制します。ブラウザーの起動失敗は致命的ではありません。gui は手動で開く URL を出力し、サーバーは動作を続けます。 サーバーは 127.0.0.1 の一時ポートにバインドし、実行のたびに新しいトークンを生成します。そのため URL は http://127.0.0.1:<port>/?token=<token> のような形になります。すべてのリクエストにトークンが必要で、書き込みを伴うリクエストではヘッダーにもトークンを付ける必要があります。プロセスは、中断するまで動作し続けます。

statusline

statusline は、エージェントのステータスバー向けに、CC Safety Net の現在の状態を絵文字インジケーターの 1 行として出力します。--claude-code(短縮形 -cc)が必要です。ない場合はエラーになり、ヘルプを表示して 1 で終了します。
プラグインが無効な場合、この行は 🛡️ CC Safety Net ❌ になります。それ以外の場合はレベルを絵文字で表します。standard は 、strict は 🔒、paranoid は 👁️、customised は 🔧 です。worktree の緩和が有効な場合は 🌳 が、ポリシーのスナップショットが degraded の場合は末尾に ⚠️ が付きます。 入力がパイプされると、statusline は標準入力を読み取ります。Claude Code の JSON ステータスペイロードは破棄します。それ以外のパイプされたテキストは維持し、<stdin> | <status> としてインジケーターの前に置きます。 statuslinestatus は、同じポリシースナップショットと環境モードを使います。出力形式は異なります。ターミナルレポートには status、プログラムまたはステータスバーには statusline を使います。 設定手順と各インジケーターの意味については、ステータスラインの設定ページを参照してください。

グローバルオプション

いつでもインストール済みバージョンを確認し、使用方法を表示できます。--version の短縮形は -V--help の短縮形は -h です。
特定のコマンドの使用方法を表示するには、help <command> または <command> --help を使います。
認識しないコマンドは Unknown command: <name> を出力します。- で始まる場合は Unknown option: <name> を出力します。その後に Run 'cc-safety-net --help' for usage. を出力し、1 で終了します。不明なコマンドに対する help <name> は、代わりに Unknown command: <name>Run 'cc-safety-net --help' for available commands. を出力します。表示するヘルプテキストを含め、これらの失敗パスのメッセージはすべて標準エラー出力へ書き出されます。
最終更新日 2026年9月3日