Skip to main content
No major coding CLI deterministically blocks destructive git commands inside the workspace you handed it. git reset --hard, git checkout -- ., git clean -f, git stash clear, and git push --force all act on files the agent is already allowed to write, so a sandbox that scopes writes to the project directory sees nothing wrong. OpenAI’s Codex security docs say commands under workspace-write “can still mutate state and perform destructive operations”. An independent analysis of Codex permissions (2026-04-20) puts it directly: “No command-level semantic blocking: the system cannot prevent git reset —hard”. Claude Code’s sandboxing docs scope writes to the working directory, which is where your uncommitted work lives. Three more reasons the layer is worth running:
  • A deterministic check under probabilistic ones. Anthropic publishes a 17% false-negative rate for the Claude Code auto-mode classifier on real overeager actions and calls it “not a drop-in replacement for careful human review”. Deny rules and hooks are the deterministic layer instead of a judgment call. Verified against Claude Code 2.1.251, a PreToolUse deny still fires in default, auto, and bypassPermissions modes (tests/e2e-live/protection.test.ts in the project repository). That is a per-version result, not a standing guarantee, so the suite runs again on every release and host upgrade.
  • Secret protection with nothing to configure. Claude Code’s sandboxing docs state that the default read behavior “still allows reading credential files such as ~/.aws/credentials and ~/.ssh/”, and that “There is no built-in credential deny list”. The native equivalents in other CLIs are opt-in config you write per CLI. CC Safety Net blocks content access to those paths and to project .env files on install, across shell commands and the read, edit, write, and search tools.
  • One policy and one audit trail across 13 CLIs. Five vendors ship five incompatible permission mechanisms and no decision log you can read afterwards.
Layers below this one have failed in the field. The protection-layers comparison covers the sandbox and allowlist CVEs, and Adversa’s incident tracker records nine agent destruction cases from 2025 and 2026, with guardrails enabled in about half of them. The founding case still stands. It is just no longer the frontier. An agent wiped hours of work with one rm -rf ~/, and instructions did not stop it. Claude Code now ships a deterministic circuit breaker for critical paths like that one, which is the right fix and the reason it is no longer the headline here. The git commands above have no such breaker. Rules in CLAUDE.md or AGENTS.md can guide an agent, but they cannot enforce a technical limit. CC Safety Net enforces that limit as a check before execution.

What it intercepts

CC Safety Net installs into your coding agent. It runs before the agent’s tool call reaches your machine. It inspects shell commands and file write, edit, search, and patch operations. It then allows the operation or blocks it with a direct reason. A block arrives as a normal tool result, so the agent can continue the task without the blocked operation. CC Safety Net bases its decision on intent, not spelling. It allows git checkout -b feature because the command creates a branch. It blocks git checkout -- file because the command discards uncommitted changes. Both commands start with the same two words. For tool operations that an integration forwards, the same inspection protects supported credential-bearing files, including SSH keys, .env files, cloud credential stores, and coding CLI tokens. CC Safety Net blocks matching forwarded reads and writes before the agent accesses the file. Tool coverage differs by integration; see the integration coverage boundaries and the Secret protection reference. Each agent uses a different integration. Some run CC Safety Net as a short-lived subprocess. Others load it in the agent process. The installer configures the correct integration for your agent. See How it works for the full lifecycle of one tool call.

What it does not replace

Use CC Safety Net with your agent’s permission rules and native sandboxing. It does not replace them. Deny rules give you quick, user-configurable blocks. Sandboxing gives operating-system-level filesystem and network containment. CC Safety Net covers known-destructive Git and filesystem operations that a sandbox can permit inside your project. Use these layers together. See the protection-layers comparison. CC Safety Net does not give complete protection. It is a static pre-execution policy gate. It cannot see inside arbitrary binaries, and it cannot protect commands that bypass an installed integration. Read Known limitations before you rely on it.

Get started

Pick your agent on the Installation page, then confirm protection is live with the Quickstart.
Last modified on August 31, 2026