CC Safety Net: a pre-execution hook that reads commands before your agent runs them

The failure it targets is an agent with a shell, not a malicious user

Coding agents are given shell access and then asked to make progress. The failure mode is not exotic: the agent decides a clean checkout is the fastest route, runs git reset --hard, and discards work that was never committed. Or it greps for a config value, walks into .env, and pastes the contents into a transcript. Neither action requires an adversary. It requires a plausible-sounding plan and a tool call.

CC Safety Net is aimed at that gap. The README describes it as blocking "destructive commands and access to secrets such as SSH keys and .env files before the tool call runs." The audience is developers who already run one of the supported coding CLIs on a workstation or a cloud session and want a gate that does not depend on the model choosing well. It is not an endpoint security product and does not claim to be one.

The analyzer parses the command instead of matching strings

The mechanism that matters here is that the guard interprets what a command does rather than looking for a known-dangerous string. The README states plainly: "It parses what the command does. Wrapping the command or reordering flags does not hide it." That is the difference between this and a deny-list of regexes. A blocklist that looks for rm -rf misses the same command written with separated flags or nested inside an interpreter invocation. An analyzer that resolves the command shape does not.

The README gives the concrete cases: the hook "still blocks the same command inside bash -c or python -c." Those two wrappers are the standard way an agent talks itself past a naive filter, because the outer process is just bash or python and looks harmless. The covered destructive set is named explicitly: git reset --hard, git push --force, rm -rf on dangerous targets, find -delete, and PowerShell Remove-Item.

Secret access is handled on a second axis. The rules cover SSH keys, .env files, ~/.aws, and "the credential files coding CLIs keep." Critically, the README says the rules span both the shell and the agent's own read, edit, write, and search tools. A guard that only inspects Bash leaves the Read tool as an open door to the same file, so covering both surfaces is the correct scope decision.

One design choice is worth flagging as a trade-off. Blocking a CLI's own settings files is optional and "stays off until you turn it on." That is a deliberate default toward not breaking the agent's own configuration workflow, but it also means the out-of-the-box posture is narrower than the feature list suggests.

Fail-open on a broken config is the right call, and you should know you accepted it

The README contains one line that deserves more attention than it usually gets: "A broken config file never blocks anything." Read that as a fail-open policy. If the configuration is malformed or unreadable, the guard does not stop the tool call; it lets it through.

For a developer tool this is defensible. A safety layer that bricks every agent session because of a stray comma in a JSON file gets uninstalled within a day, and an uninstalled guard protects nothing. But it changes what you are buying. You are buying protection against the common case, not a guarantee. If your policy files are managed by hand across a team, a syntax error silently returns you to an unguarded state, and nothing in the README suggests the agent surfaces that to you mid-session.

This is the sort of thing to verify rather than assume. The README points to a doctor command in the policy-sharing context, and the natural first check after any config edit is whether that command still reports a healthy state.

Installation is per-CLI, and the policy layer is a git directory

The project supports a long list of CLIs: Amp Code, Antigravity CLI, Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, Grok Build, Hermes Agent, Kimi Code, OpenClaw, OpenCode, and Pi. Each has its own installation page on ccsafetynet.com, which tells you the integration is not one universal hook but a set of adapters per tool. That is the honest shape of this problem, since each CLI exposes a different hook surface.

The GUI is the entry point for tuning. The README gives the command directly:

npx cc-safety-net gui

Open Policy from there to turn individual block and secret rules off, or to add paths to allow or deny. Two rules are not negotiable: the README says you "cannot turn off the rules that catch wiping / or ~." That immovable floor is a reasonable line to draw, since those two commands have no legitimate agent use case.

Rulebooks extend coverage without weakening it. The README is explicit that "a rulebook can only add blocks. It cannot turn built-in protection off." Official packs exist for Terraform, AWS, gcloud, and Azure, and live in a separate repository at cc-safety-net/rulebooks. Installation is a single command:

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

The --only flag selects which packs to pull and --global sets the scope. The one-way nature of rulebooks is a good structural choice: third-party or self-written JSON cannot be used to quietly disable a built-in rule, which removes an obvious supply-chain footgun.

Team distribution goes through git. You commit a .cc-safety-net/ directory so that clones and cloud sessions inherit the same rules. The README notes two guardrails on that path. If a project file tries to loosen a member's stricter settings, status and doctor report it. And policy apply asks for confirmation in a terminal. It also warns that "copying the folder is not enough. The hook still has to be installed." That last sentence matters because it is the most likely way a team believes it is covered when it is not.

A sandbox and this guard answer different questions

The README links to its own comparison page on sandboxing, and the distinction it draws is the useful one. A sandbox constrains where a command can act; a command guard decides whether the command runs at all. The README states that "a sandbox still allows git reset --hard inside your project." That is not a defect in sandboxing. It is the boundary of what a filesystem sandbox is for.

For the agent-accident case, the two approaches overlap less than people assume. A container that mounts your project read-write will happily let the agent destroy the working tree inside it. Conversely, a command guard that blocks git reset --hard does nothing about an agent that writes a bad migration through an allowed path. If your concern is blast radius on a shared machine, sandboxing or a disposable container is the stronger control. If your concern is a specific set of irreversible commands and credential reads, the analyzer approach catches things a mount policy cannot express.

Running both is coherent, and the README's framing supports that reading rather than positioning the project as a replacement.

Where coverage stops, and what the project does not claim

The support matrix has a real seam in it. The README states that automated tests cover the analyzer and some Windows integrations, and that "Windows support for the remaining CLIs is best effort and has not been tested." Amp is called out separately: it documents macOS, Linux, and WSL, but not native Windows. So on Windows, outside the tested integrations, you are relying on code paths the maintainers have not validated. That is disclosed rather than hidden, but it should decide whether this is the right tool for a Windows-only team.

The larger limitation is conceptual. This is a parser, not a proof. It blocks the destructive commands its rules describe. An agent that destroys your work through a command the analyzer does not classify as destructive will not be stopped, and the README makes no claim otherwise. Treat it as a reduction in the frequency and severity of accidents, not as a boundary against an agent actively trying to evade it.

The fail-open behavior on a broken config compounds this. Two independent conditions have to hold for protection: your config parses, and the command is in scope. Neither is guaranteed by installing the package.

Maintenance cost is low, but the policy directory is yours to keep correct

The project is MIT licensed, which permits commercial and private use, modification, and redistribution provided the license and copyright notice are preserved. Nothing in the supplied material suggests any additional restriction, dual-licensing, or contributor agreement that would change that. This is a description of the license text, not legal advice; if you are embedding the analyzer in a distributed product, have counsel read the MIT terms rather than this paragraph.

The release cadence visible in the repository is frequent: v2.3.4 on 2026-09-08, v2.3.3 on 2026-09-04, and v2.3.2 on 2026-09-03. Three patch releases in five days suggests active maintenance and also suggests you should not pin to a specific patch and forget it. The upgrade surface is small because the artifact is an npx-invoked hook plus a .cc-safety-net/ directory, but the policy directory is the part that accumulates drift. Every rule you disable in Policy and every path you add to allow or deny is state that outlives the package version.

The rulebooks add a second dependency to track. If you install the Terraform and AWS packs, those live in a separate repository and can move independently of the core project. The one-way constraint means a rulebook update can only add blocks, so an upgrade cannot silently loosen your posture, but it can start blocking commands your team relied on. Budget for that in the same way you would for a linter rule change.

Who should install it, and the first three things to check

Install it if you run one of the supported CLIs on macOS or Linux and that machine has credentials worth protecting. The combination of command analysis, coverage of both shell and file tools, and rulebooks that cannot subtract from built-in rules is a coherent design, and the MIT license removes procurement friction.

Do not install it expecting a security boundary against a motivated attacker, and think twice if your team is Windows-only outside the tested integrations. If your actual risk is an agent corrupting a shared environment, a disposable container addresses that more directly, and the README's own sandboxing comparison concedes the point.

Three things to verify before you rely on it. First, run npx cc-safety-net doctor after installation and after any policy change, and confirm it reports the state you expect rather than assuming a malformed file failed loudly. Second, open npx cc-safety-net gui, go to Policy, and read which rules you have actually left on, since CLI settings file blocking is off by default. Third, if you are rolling this out across a team, confirm that the hook is installed on each machine and not just that .cc-safety-net/ is present in the repository, because the README is explicit that copying the folder alone does not activate anything.

Editorial conclusion

Adopt CC Safety Net if you run Claude Code, Codex, Cursor, Gemini CLI or one of the other supported agents on a machine that holds real credentials, and you want a block layer that survives flag reordering and shell wrapping. Skip it if your threat model is a determined attacker rather than a careless agent, or if you depend on a CLI that is not on the supported list. Before trusting it, run npx cc-safety-net doctor, read the vs Sandboxing guide on ccsafetynet.com, and confirm which rules you have actually left enabled in Policy.

Official sources

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