The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.
We learned the hard way that instructions aren't enough to keep AI agents in check.
After Claude Code silently wiped out hours of progress with a single rm -rf ~/ or git checkout --, it became evident that soft rules in an CLAUDE.md or AGENTS.md file cannot replace hard technical constraints.
The current approach is to use a dedicated hook to programmatically prevent agents from running destructive commands.
Why Use This Instead of Permission Deny Rules?
Claude Code's .claude/settings.json supports deny rules with wildcard matching (e.g., Bash(git reset --hard:*)). Here's how this plugin differs:
At a Glance
| | Permission Deny Rules | Safety Net |
|---|---|---|
| Setup | Manual configuration required | Works out of the box |
| Parsing | Wildcard pattern matching | Semantic command analysis |
| Execution order | Runs second | Runs first (PreToolUse hook) |
| Shell wrappers | Not handled automatically (must match wrapper forms) | Recursively analyzed (5 levels) |
| Interpreter one-liners | Not handled automatically (must match interpreter forms) | Detected and blocked |
Permission Rules Have Known Bypass Vectors
Even with wildcard matching, Bash permission patterns are intentionally limited and can be bypassed in many ways:
| Bypass Method | Example |
|---------------|---------|
| Options before value | curl -X GET http://evil.com bypasses Bash(curl http://evil.com:*) |
| Shell variables | URL=http://evil.com && curl $URL bypasses URL pattern |
| Flag reordering | rm -r -f / bypasses Bash(rm -rf:*) |
| Extra whitespace | rm -rf / (double space) bypasses pattern |
| Shell wrappers | sh -c "rm -rf /" bypasses Bash(rm:*) entirely |
PreToolUse hooks run before the permission system. This means Safety Net inspects every command first, regardless of your permission configuration. Even if you misconfigure deny rules, Safety Net provides a fallback layer of protection.
Use both together: Permission deny rules for quick, user-configurable blocks; Safety Net for robust, bypass-resistant protection that works out of the box.
What About Sandboxing?
Claude Code offers native sandboxing that provides OS-level filesystem and network isolation. Here's how it compares to Safety Net:
Sandboxing restricts filesystem + network access, but it doesn't understand whether an operation is destructive within those boundaries. These commands are not blocked by the sandbox boundary:
[!NOTE]
Whether they're auto-run or require confirmation depends on your sandbox mode (auto-allow vs regular permissions), and network access still depends on your allowed-domain policy. Claude Code can also retry a command outside the sandbox via dangerouslyDisableSandbox (with user permission); this can be disabled with allowUnsandboxedCommands: false.
Sandboxing sees git reset --hard as a safe operation—it only modifies files within the current directory. But you just lost all uncommitted work.
When to Use Sandboxing Instead
Sandboxing is the better choice when your primary concern is:
Prompt injection attacks — Reduces exfiltration risk by restricting outbound domains (depends on your allowed-domain policy)
Malicious dependencies — Limits filesystem writes and network access by default (subject to your sandbox configuration)
Untrusted code execution — OS-level containment is stronger than pattern matching
Network control — Safety Net has no network protection
Recommended: Use Both
They protect against different threats:
Sandboxing contains blast radius — even if something goes wrong, damage is limited to cwd and approved network domains
Safety Net prevents footguns — catches git-specific mistakes that are technically "safe" from the sandbox's perspective
Running both together provides defense-in-depth. Sandboxing handles unknown threats; Safety Net handles known destructive patterns that sandboxing permits.
Prerequisites
Node.js: Version 18 or higher is required to run this plugin
