Show HN: Fence – Sandbox CLI commands with network/filesystem restrictions (github.com)
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!
12 comments
[ 4.3 ms ] story [ 40.0 ms ] threadCurrently it seems to allow read access by default and only allows to block some paths with with "denyRead"
We're working on similar containment problems but at the API/MCP layer at keypost.ai - enforcing what outbound calls an agent can make rather than what local filesystem/network it can access. The two layers complement each other well.
The "restrictions as code" pattern is powerful. Are you thinking about extending to other resource types (API calls, token budgets, etc.)?
I think Fence should stay a thin wrapper around OS primitives (sandbox-exec, bubblewrap, Landlock), so not much beyond what it does today. The one extension that probably makes sense is basic resource limits (CPU, memory, fork bombs, etc). But API semantics and MCP tool restrictions belong in a different layer.
https://github.com/anthropic-experimental/sandbox-runtime
This could allow finer control than the application's own sandbox offers. For example, Flatpak apps run in bubblewrap containers with all-or-nothing network permissions. Being able to restrict access by domain name would be useful.
- https://github.com/webcoyote/clodpod: sandboxes AI agents in a MacOS virtual machine
Note: I’m the author of both of these Apache open-source projects
I got tired of setting individual allow lists for each CLI, hopefully now I can run them all in Yolo mode while fence does the centralized sandboxing.