CC Safety Net: a pre-execution guard for destructive commands in coding agents

The failure CC Safety Net is built around

A coding agent runs shell commands with your credentials. When it decides a working tree is dirty and reaches for `git reset --hard`, or when a misread path turns an `rm` into something wider, nothing between the model and your disk asks a question. The README frames the project as a pre-execution guard: it parses what the command does and blocks it before the tool call runs. That timing is the whole design. A linter or a post-hoc audit tells you what happened; this refuses the call.

The second target is disclosure rather than destruction. The README lists SSH keys, `.env` files, `~/.aws`, and the credential files coding CLIs keep. The rules cover the shell and the agent's read, edit, write, and search tools, so the protection is not limited to commands that spawn a process. Blocking a CLI's own settings files is optional and, per the README, stays off until you turn it on. That default is sensible: a guard that silently rewrites an agent's config on first run would be worse than the problem it solves.

Who is this for? Teams that run agents unattended or with broad filesystem access, and individuals who have already had one bad `git` day. It is a tripwire, not a permission model.

Parsing the command instead of matching the string

The mechanism the README emphasizes is analysis of the command, not pattern matching on its text. The claim is that wrapping the command or reordering flags does not hide it. That is the right place to put the effort, because string matching on `rm -rf` loses to `bash -c`, to a variable, to a reordered flag list, or to a script the agent writes and then executes. The README states the hook still blocks the same command inside `bash -c` or `python -c`, which is the shape of an analyzer that resolves the invocation rather than grepping the line.

The same analyzer backs every integration. The repository ships per-CLI adapter directories at the top level (`.claude-plugin/`, `.codex-plugin/`, `.amp/`, `.agents/`, `kimi.plugin.json`, and others) over a single TypeScript core in `src/`. That structure matters for evaluation: the rule set is written once, and each adapter is the glue that registers the hook with that CLI's lifecycle. If you are deciding whether to trust it, the interesting code is the analyzer, and the adapters are comparatively thin.

One design decision deserves credit. The README states a broken config file never blocks anything. An earlier version of this class of tool would fail closed and lock the agent out of every command the moment a JSON file had a trailing comma. Failing open on a malformed config is a deliberate trade: you keep working, and you lose protection until you notice. The `doctor` subcommand exists to help you notice.

Installing CC Safety Net and blocking your first command

The README points to the full documentation for installation and keeps only the short version in the repository. The package is published as `cc-safety-net` with two binaries, `cc-safety-net` and `ccsn`, and the README's own examples invoke it through `npx`. Start by checking that the CLI you use is on the supported list: Amp Code, Antigravity CLI, Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, Grok Build, Hermes Agent, Kimi Code, OpenClaw, OpenCode, and Pi. The README notes that automated tests cover the analyzer and some Windows integrations, and that Windows support for the remaining CLIs is best effort and untested.

Rulebooks are the documented extension point. The README gives this command for installing official packs, and states that a rulebook can only add blocks and cannot turn built-in protection off:

npx -y cc-safety-net rule add --only terraform aws --global

After that, policy is editable without hand-writing JSON. The README documents a GUI:

npx cc-safety-net gui

Open Policy in that interface. You can turn individual block and secret rules off, and add paths to allow or deny. The README states you cannot turn off the rules that catch wiping `/` or `~`, which is the correct place to draw a line.

For a team, the README describes committing the `.cc-safety-net/` directory so clones and cloud sessions pick up the same rules. Two caveats are stated explicitly: copying the folder is not enough, because the hook still has to be installed, and `policy apply` asks for confirmation in a terminal when a project file tries to loosen a member's stricter settings. `status` and `doctor` report that conflict. The first real test is to ask your agent to run a destructive command in a scratch repository and confirm the call is refused rather than executed.

Where the guard stops and a sandbox begins

The README links a comparison page titled vs Sandboxing, and the sentence it carries is the honest limitation: a sandbox still allows `git reset --hard` inside your project. Read that twice, because it cuts in both directions. A sandbox constrains where a process can reach; this project constrains what the process is allowed to do inside the space it already has. If your threat model is an agent escaping the project directory, CC Safety Net is the wrong tool and you want filesystem isolation. If your threat model is an agent doing something permitted but unrecoverable inside the project, isolation does not help you and this does.

The second limitation is coverage. A hook only fires in CLIs that expose a hook point and only for tool calls that go through it. The README lists thirteen integrations and then admits that Windows support for the CLIs beyond the tested ones is best effort. If your agent runs commands through a path the hook does not see, the analyzer never gets the string.

The third is the fail-open config behavior. A malformed policy file means nothing is blocked. That is a reasonable default for a developer tool and a poor property for a compliance control, and the README does not present it as anything other than what it is.

How it differs from an agent permission prompt

The nearest alternative is the approval prompt most coding agents already ship: the agent asks, you press a key, the command runs. The difference is not the decision, it is who makes it and when. A permission prompt is per-call and human, so it degrades exactly when you stop watching: in long sessions, in CI, in cloud environments, or after the tenth approval of the afternoon. CC Safety Net is a standing rule evaluated before the call, which is why the README's team and cloud-environment guides exist at all.

The cost of that trade is expressiveness. A human approver can reason about intent; a parser reasons about the command. A rule that is too broad will block legitimate work and you will turn it off, and the README gives you the GUI to do precisely that. A rule that is too narrow will miss a destructive variant, which is why the project leans on parsing and on rulebooks instead of a fixed list.

The other alternative is a container or VM boundary, discussed above. It is stronger on containment and weaker on intent, and it does not stop the agent from destroying the repository it was pointed at. The two compose; the README does not claim otherwise.

Maintenance cost, licence, and what ships with the package

The last push to the repository was on 2026-09-09, and the release list shows v2.3.2, v2.3.3, and v2.3.4 landing within a week of each other in early September 2026. That cadence is the relevant fact for anyone pinning a version: the project moves quickly, so a pinned release will age against a rule set that is still being extended. The repository is not archived. The published package version in `package.json` is 2.4.1, ahead of the newest release tag listed, which is worth checking before you assume a tag and the npm artifact match.

The licence is MIT, stated in the README badge and present as a `LICENSE` file at the repository root. MIT is permissive: you can embed the package in your own tools, which the README explicitly supports through the `./api` export in `package.json`. It offers no patent grant and no warranty. That is a description of the licence text, not advice about your situation; if the guard is part of a regulated control, have counsel read it rather than an article.

Upgrade cost is mostly policy, not code. Rulebooks you install with `rule add` and any local allow or deny paths are your own state, and the README's team-setup guidance implies it lives in `.cc-safety-net/` under version control. Review that directory when you bump the version, and run `status` and `doctor` afterward, since those are the documented commands that surface a project policy conflicting with a member's stricter settings.

Editorial conclusion

Install it if your agent runs with your own shell credentials and you want a tripwire on git reset --hard, rm -rf, and reads of SSH keys or .env files, and if you accept that the guard is a hook rather than a sandbox. Do not install it expecting containment: the README states a sandbox still allows git reset --hard inside your project, so the two solve different problems. Verify first that your CLI appears in the installation list, that the hook is actually registered (the README notes copying the .cc-safety-net/ folder is not enough), and which of your own settings files the optional rule would block before turning it on.

Frequently asked questions

Official sources

1. kenryu42/cc-safety-net on GitHub
2. License: MIT
3. Project website
4. README
5. Releases