Skip to main content
Most coding agent CLIs now ship or support OS-level sandboxing that provides filesystem and network isolation. CC Safety Net operates at the application layer. They protect against different threats — using both gives the most complete protection.

​
Common patterns

Sandboxing implementations vary by platform, but most converge on the same OS primitives — macOS Seatbelt and Linux bubblewrap — and the same default posture: reads are broad, writes are limited to the working directory and a temp directory, and network access is restricted or off by default. Every implementation also separates two controls: the sandbox itself, a technical boundary over what can be touched, and an approval policy that decides when the agent must ask before acting.

​
Different layers of protection

​
Why sandboxing isn’t enough

Sandboxing restricts where you can write, but it doesn’t understand whether an operation is destructive within those boundaries. The following commands are all permitted by the sandbox because they operate inside the current working directory:
Whether these commands run automatically or require confirmation depends on your agent’s sandbox mode and approval policy. Network-dependent commands like git push --force also depend on your allowed-domain configuration.
Sandboxing sees git reset --hard as a safe operation — it only modifies files within the current directory. But your AI agent just discarded all of your uncommitted work.
From the OS’s perspective, these commands are entirely legitimate: they write to an allowed path, don’t touch the network (except push), and complete without error. The sandbox has no concept of git history, uncommitted changes, or stash entries. CC Safety Net understands these semantics and blocks them accordingly.

​
When sandboxing is the better choice

Sandboxing is the right tool when your primary concern is:
  • Prompt injection attacks — reduces exfiltration risk by restricting outbound network domains
  • Malicious dependencies — limits filesystem writes and network access from untrusted packages
  • Untrusted code execution — OS-level containment is fundamentally stronger than pattern matching
  • Network control — CC Safety Net has no network protection at all
If you’re running code from an untrusted source, or you’re worried about a compromised dependency reaching out to an attacker-controlled server, sandboxing is the layer that addresses those threats.

​
Where CC Safety Net cannot help

CC Safety Net operates only on shell commands and only on known-destructive patterns. It has no read-protection layer and no network layer. That means it does not stop an agent from reading sensitive files (for example ~/.aws/credentials, ~/.ssh/id_*, or .env files, which the sandbox permits reads of by default), and it does not stop data exfiltration over the network. Those threats are exactly what sandboxing’s read constraints and network restrictions are for — which is why the two tools are complementary rather than alternatives.

​
Using both together

Run both for defense-in-depth. They complement each other cleanly:
  • Sandboxing contains the blast radius — even if something goes wrong, damage is limited to the current working directory and approved network domains.
  • CC Safety Net prevents footguns — catches git-specific and filesystem-destructive mistakes that sandboxing permits because they operate within cwd.
Sandboxing handles unknown threats by constraining what the agent can do at the OS level. CC Safety Net handles known destructive patterns by intercepting commands before they execute. Together, they cover the gaps that each leaves on its own.
Last modified on June 23, 2026