Fence wraps any command in a sandbox that blocks network by default and restricts filesystem writes. Useful for running semi-trusted code (package installs, build scripts, unfamiliar repos) with controlled side effects, or even just blocking tools that phone home.
> fence curl https://example.com # -> blocked
> fence -t code -- npm install # -> template with registries allowed
> fence -m -- npm install # -> monitor mode: see what gets blocked
One use-case is to use it with AI coding agents to reduce the risk of running agents with fewer interactive permission prompts:
> fence -t code -- claude --dangerously-skip-permissions
You can import existing Claude Code permissions with `fence import --claude`.
Fence uses OS-native sandboxing (macOS sandbox-exec, Linux bubblewrap) + local HTTP/SOCKS proxies for domain filtering.
Why I built this: I work on Tusk Drift, a system to record and replay real traffic as API tests (https://github.com/Use-Tusk/tusk-drift-cli). I needed a way to sandbox the service under test during replays to block localhost outbound connections (Postgres, Redis) and force the app to use mocks instead of real services. I quickly realized that this could be a general purpose tool that would also be useful as a permission manager across CLI agents.
Limitations: Not strong containment against malware. Proxy-based filtering requires programs to respect `HTTP_PROXY`.
Curious if others have run into similar needs, and happy to answer any questions!
Currently it seems to allow read access by default and only allows to block some paths with with "denyRead"