Skip to main content
CC Safety Net supports seven AI coding agents, but it does not plug into all of them the same way. There are three integration models. Understanding which one your agent uses helps you install it correctly, debug a hook that is not firing, and know where its configuration lives.

The three integration models

Hook subprocess agents

For these agents, the protection is the runtime hook <flag> command. Each agent names its hook event and shell tool differently, and each expects a different deny shape on stdout: -cc, -cp, and -gc also work as legacy top-level flags (for example cc-safety-net --claude-code). -kc is only valid as hook --kimi-code.
Because these agents use different hook events and deny formats, CC Safety Net emits the correct shape per agent. Gemini CLI, for example, expects a decision/systemMessage object with exit 0 rather than Claude Code’s hookSpecificOutput. You do not need to configure the output format — the flag you pass selects it.

Where each hook agent’s config lives

Only Kimi Code has its config written directly by CC Safety Net (via hook install --kimi-code). The others install through their own plugin or extension marketplaces:

Plugin agents

Codex

Codex loads CC Safety Net as a plugin from the cc-marketplace. Two settings in ~/.codex/config.toml (or $CODEX_HOME/config.toml) must be correct for the hook to fire:
The hook must also be marked trusted via /hooks in the Codex TUI (press t). See Installation for the full setup.

OpenCode

OpenCode loads CC Safety Net as a plugin declared in ~/.config/opencode/opencode.json (or .jsonc) under the plugin[] array, installed via opencode plugin -g cc-safety-net. OpenCode can cache a stale version; see the Installation cache-clearance steps if updates do not take effect.

The Pi extension

Pi is the only agent that runs CC Safety Net in-process. When you run pi install npm:cc-safety-net, Pi reads the package’s pi.extensions field and loads CC Safety Net’s extension directly into the Pi process. The extension does two things:
  1. Registers a tool_call event handler (pi.on('tool_call')). This handler intercepts shell tool calls before they run, analyzes the command with the same engine used everywhere else, and returns a block result when the command is destructive. Unlike the hook subprocesses, there is no JSON-over-stdio — the call and its result stay in memory.
  2. Registers a /cc-safety-net builtin command for managing rulebooks interactively inside Pi.

Tools Pi protects

The extension intercepts both the built-in bash tool and custom Shell tools (such as the one provided by pi-grok-cli). For Shell tools it resolves the call’s working_directory relative to the session cwd before analyzing the command, so the same cwd-aware rules (worktree relaxation, rm -rf target classification) apply. If a tool call is malformed, CC Safety Net fails closed and blocks it.

Detecting Pi

Because there is no config file to inspect, the doctor command detects Pi with a runtime probe (it spawns pi and asks whether the extension is loaded and enabled). This is why a Pi status in doctor may read n/a even when Pi is installed, if the probe cannot run.

Choosing and verifying

Install for your agent using the method documented in Installation. After installing, run the doctor command — it reports the detected integration model and config path for every agent, and runs a self-test wherever protection is active:
For troubleshooting a hook that is not firing for a specific agent, see the per-agent steps in Troubleshooting.
Last modified on June 22, 2026