A PreToolUse hook that intercepts and blocks destructive git and filesystem commands before AI coding agents run them. CC Safety Net parses command semantics — so flag reordering, shell wrappers, and interpreter one-liners can't bypass it.
Note
Full documentation → — installation, configuration, reference, guides, and the security model live on the docs site.
We learned the hard way that instructions aren't enough to keep AI agents in check. After an agent silently wiped hours of progress with a single rm -rf ~/ or git checkout --, it became clear that soft rules in a CLAUDE.md or AGENTS.md file cannot replace hard technical constraints. CC Safety Net is that constraint: it intercepts every Bash tool call and blocks destructive commands before they reach the shell. See What Is CC Safety Net for the full background.
CC Safety Net works across seven coding agent CLIs: Claude Code, Codex, Gemini CLI, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi. Each integration is documented at Architecture.
- Node.js 18 or higher.
- Enable Codex plugin hooks in
~/.codex/config.toml:
[features]
plugin_hooks = true- Add the marketplace:
codex plugin marketplace add kenryu42/cc-marketplace- Start Codex.
- In the TUI, run
/plugins. - Use arrow keys to select
[cc-marketplace]. - Press Enter to install the plugin.
- run
/hooksand select the safety-net PreToolUse hook and presstto trust it.
/plugin marketplace add kenryu42/cc-marketplace
/plugin install safety-net@cc-marketplace
/reload-plugins- Run
/plugin→ SelectMarketplaces→ Choosecc-marketplace→ Enable auto-update
gemini extensions install https://github.com/kenryu42/gemini-safety-net/plugin install kenryu42/copilot-safety-netInstall CC Safety Net into your Kimi Code config:
npx -y cc-safety-net hook install --kimi-codeOptional: run npx skill add kenryu42/cc-safety-net to add the /cc-safety-net skill for configuring custom rules.
Install CC Safety Net with OpenCode's native plugin command:
opencode plugin -g cc-safety-netNote
OpenCode can sometimes keep using a stale cached plugin version. See anomalyco/opencode#25293 for the current tracking issue.
To force OpenCode to reinstall cc-safety-net, remove its cached package and
install the version you want:
rm -rf ~/.cache/opencode/packages/cc-safety-net@latest
opencode plugin -g -f cc-safety-net@latestIf you prefer pinning a specific version:
rm -rf ~/.cache/opencode/packages/cc-safety-net@latest
opencode plugin -g -f cc-safety-net@<version>Restart OpenCode after updating so the plugin is loaded from the refreshed cache.
Install CC Safety Net with Pi's package installer:
pi install npm:cc-safety-net| Capability | What it catches |
|---|---|
| Semantic command analysis | rm -rf on destructive targets, git reset --hard, git checkout --, git push --force, git stash clear, git clean -f, find -delete, dd/mkfs/shred — by intent, not string pattern. git checkout -b feature (safe) is allowed while git checkout -- file (destructive) is blocked. |
| Shell wrapper detection | Destructive commands hidden in bash -c, sh -c, and similar wrappers, recursively analyzed up to 10 levels deep. |
| Interpreter one-liners | Destructive code in python -c, node -e, ruby -e, perl -e one-liners (e.g. os.system("rm -rf /")). |
| Fail-closed by default | Malformed hook input, unparseable commands (in strict mode), invalid config, and broken rulebooks block rather than allow. |
| Custom rules via rulebooks | Add your own blocking rules at user or project scope, pinned by SHA-256 digest when fetched from GitHub. |
| Audit logging | Every blocked command logged to ~/.cc-safety-net/logs/<session_id>.jsonl with secrets auto-redacted. |
Full blocked/allowed command lists: Blocked Commands · Allowed Commands.
A workspace-writable sandbox still permits git reset --hard, git push --force, and rm -rf . inside the project directory, because the OS only sees writes to an allowed path. Sandboxing contains blast radius; CC Safety Net catches the destructive operations sandboxing permits — use both for defense-in-depth. See vs Sandboxing.
CC Safety Net has opt-in modes toggled by CC_SAFETY_NET_* environment variables (legacy SAFETY_NET_* names also accepted):
| Mode | Flag | Effect |
|---|---|---|
| Strict | CC_SAFETY_NET_STRICT=1 |
Fail closed on unparseable commands, not just malformed input. |
| Paranoid | CC_SAFETY_NET_PARANOID=1 |
Stricter checks; or use CC_SAFETY_NET_PARANOID_RM=1 (block rm -rf even within cwd) and CC_SAFETY_NET_PARANOID_INTERPRETERS=1 (block interpreter one-liners). |
| Worktree | CC_SAFETY_NET_WORKTREE=1 |
Relax local git discards inside verified linked worktrees. |
See Modes and Environment.
# Verify your installation and run a self-test
npx cc-safety-net doctor
# Trace how a command is analyzed step-by-step
npx cc-safety-net explain "git reset --hard"Both support --json for machine-readable output. Full reference: CLI Commands · Explain Trace.
Warning
If you previously defined custom rules in a legacy inline config (.safety-net.json or ~/.cc-safety-net/config.json), those files are no longer loaded at runtime. Commands now fail closed (stay blocked) until you migrate. Run npx -y cc-safety-net rule migrate to convert them to the rulebook layout. See the migration guide.
All details live on the docs site at ccsafetynet.com/docs:
| Area | Pages |
|---|---|
| Get started | Introduction · Installation · Quickstart |
| Configuration | Modes · Environment · Custom Rules · Status Line |
| Reference | Blocked Commands · Allowed Commands · Audit Log · CLI Commands · Explain Trace · Glossary |
| Guides | How It Works · Architecture · Analysis Engine · Design Principles · Security Model · vs Sandboxing · Known Limitations · Troubleshooting |
| Project | Contributing · Security Policy |
See CONTRIBUTING.md for details on how to contribute to this project.
MIT