Key takeaways
- 794 GitHub stars, 31 forks, and roughly 60 tagged releases in under six months (created December 18, 2025; pushed June 11, 2026) — an unusually fast cadence for a security tool, with a Show HN that drew 78 points
- Container-free by design: macOS sandbox-exec (Seatbelt) and Linux bubblewrap enforce default-deny network and default-deny filesystem writes, with domain allowlisting layered on via local HTTP/SOCKS proxies
- Positioned as a permission manager for CLI coding agents — Claude Code, Codex, Amp, Gemini CLI, GitHub Copilot, OpenCode, Factory Droid — and explicitly framed as defense-in-depth, not hostile-code containment
FAQ
What is Fence?
Fence is an open-source CLI that wraps any command in a lightweight, container-free sandbox: outbound network is blocked by default, filesystem writes are denied by default, and dangerous commands can be blocked by policy — enforced with native OS primitives rather than Docker.
How much does Fence cost?
Free and open source under the Apache 2.0 license; there is no paid tier.
What platforms does Fence support?
macOS (via sandbox-exec/Seatbelt) and Linux (via bubblewrap plus socat for network bridging); Windows is reachable only through WSL via Nix.
How is Fence different from Anthropic's sandbox-runtime?
Fence credits sandbox-runtime as its inspiration but adds command deny rules, SSH command filtering, port exposure for inbound connections, and built-in templates, and it works with many agents beyond Claude Code.
Executive Summary
Fence is a lightweight, container-free sandbox: it wraps any command — fence -t code -- claude — in a policy boundary where outbound network is blocked by default, filesystem writes are denied by default, and specific commands like git push or rm -rf / can be denied outright, all enforced with native OS primitives (macOS sandbox-exec/Seatbelt, Linux bubblewrap) rather than Docker or VMs.[1] The README pitches it for semi-trusted code — package installs, build scripts, CI jobs, unfamiliar repos — and as defense-in-depth and a "permission manager" for CLI coding agents including Claude Code, Codex, Amp, Gemini CLI, GitHub Copilot, OpenCode, and Factory Droid.[1][2]
The project was built at Tusk, the AI testing company, where creator jy-tan needed to sandbox services under test during Tusk Drift traffic replays — blocking localhost outbound to Postgres and Redis to force the app onto mocks — and it has since moved from the Use-Tusk GitHub org into its own fencesandbox org with a dedicated docs site.[3][1][4] Created December 18, 2025, the repo sits at 794 stars and 31 forks as of June 11, 2026, with a commit pushed the same day and roughly 60 tagged releases (v0.1.60 shipped June 1, 2026) — a brisk pace for a six-month-old security tool.[1][5] It openly credits Anthropic's experimental sandbox-runtime as its inspiration.[1]
| Attribute | Value |
|---|---|
| Creator | jy-tan / Tusk; now an independent fencesandbox GitHub org[3][1] |
| Founded | December 18, 2025 (repo created)[1] |
| Funding | None disclosed for the project; built inside Tusk[3] |
| GitHub Stars | 794 (31 forks, 18 open issues) as of June 11, 2026[1] |
| License | Apache-2.0[1] |
| Language | Go[1] |
Product Overview
Usage is a prefix: fence curl https://example.com returns 403 because no domains are allowed by default; fence -t code npm install applies the built-in code template that allowlists npm, PyPI, and similar registries; fence -- claude --dangerously-skip-permissions runs Claude Code in YOLO mode with the OS, not the agent, holding the guardrails.[1] Policy lives in a JSONC fence.jsonc resolved from the current directory upward (falling back to ~/.config/fence/), with template inheritance via extends, repo-local overrides on top of a user's base config, and fence config show to inspect the merged chain.[1]
Key Capabilities
| Capability | Description |
|---|---|
| Network isolation | All outbound blocked by default; per-domain allowlists with wildcards; localhost inbound/outbound controlled separately[1][6] |
| Filesystem restrictions | Writes denied by default (allowWrite to opt in); denyWrite/denyRead overrides; always-protected targets like shell configs and git hooks[6] |
| Command blocking | Deny rules for commands like rm -rf / and git push; preflight intent parsing plus runtime execve path-based enforcement[1][6] |
| SSH command filtering | Control which hosts and commands are allowed over SSH[1] |
| Violation monitoring | -m flag logs blocked requests in real time; -d for debug detail[1] |
| Agent integration | Templates and hooks for Claude Code, Codex, Amp, Gemini CLI, Copilot, OpenCode, Factory Droid; fence import --claude converts existing Claude Code settings[2][1] |
| Go library | Usable as a Go package, not just a CLI[1] |
Technical Architecture
Fence is a policy-driven wrapper, not a container: on macOS it generates Seatbelt (sandbox-exec) profiles, on Linux it uses bubblewrap with socat for network bridging (bpftrace optionally adds filesystem-violation visibility), and repo topics also flag Landlock and seccomp.[1] Domain allowlisting is proxy-based — the OS sandbox blocks direct outbound, and local HTTP/SOCKS proxies plus HTTP_PROXY/HTTPS_PROXY/ALL_PROXY env vars selectively let allowed domains through, with an optional upstreamProxy (e.g. mitmproxy) for interactively inspecting grey-zone traffic.[6] Fence also sanitizes LD_* and DYLD_* environment variables to block library-injection persistence.[6]
Install is a one-liner on macOS/Linux (curl -fsSL https://cli.fencesandbox.com/install.sh | sh), Homebrew via the fencesandbox/tap, Nix, or go install.[1]
Key Technical Details
| Aspect | Detail |
|---|---|
| Deployment | Local CLI / Go library; macOS + Linux (Windows via WSL through Nix)[1] |
| Isolation | macOS Seatbelt, Linux bubblewrap + socat; no containers or VMs[1] |
| Model(s) | None — Fence is model-agnostic; it wraps whatever agent CLI you run[2] |
| Integrations | Claude Code, Codex, Amp, Gemini CLI, GitHub Copilot, OpenCode, Factory Droid; mitmproxy upstream[2][6] |
| Open Source | Apache-2.0, single repo on GitHub[1] |
Strengths
- Zero-container friction — no Docker daemon, no image builds, no mounted-volume ceremony; the sandbox is a command prefix, which is why it slots in front of any agent CLI without integration work.[1]
- Default-deny on both axes — network and filesystem writes both start closed, the conservative posture most agent wrappers skip; allowlists are explicit and inspectable via
fence config show.[1][6] - Honest, detailed threat model — the security docs explicitly disclaim hostile-code containment, resource limits, and exfiltration to allowed domains, and document exactly where the proxy approach fails (non-proxy-aware stacks, raw sockets).[6]
- Goes beyond its inspiration — relative to Anthropic's sandbox-runtime, Fence adds command deny rules, SSH command filtering, inbound port exposure, and built-in templates, per the creator on HN.[3][1]
- Battle-tested origin story — built to solve a real internal need at Tusk (isolating services under test during traffic replays), not as a speculative launch.[3]
- Fast iteration — roughly 60 releases between December 2025 and June 2026, with five releases in May–June 2026 alone.[5]
Cautions
- Not an isolation boundary against malice — Fence's own docs say it "is not designed to be a strong isolation boundary against actively malicious code that is attempting to escape"; kernel/OS exploits are out of scope.[6]
- Proxy-based allowlisting has holes — programs that ignore proxy env vars (Node.js native
http/https, raw sockets, custom protocol stacks) fail with connection errors rather than getting selective allow, and traffic to any allowed domain can carry exfiltrated data.[6] - No resource limits — CPU, memory, disk, and fork bombs are explicitly unaddressed, so it cannot safely host arbitrary untrusted user code the way microVM sandboxes can.[6]
- Nested sandboxes break — the creator confirmed nested bubblewrap sandboxes fail with permission errors, so wrapping applications that do their own namespace-based sandboxing is a problem.[3]
- Pre-1.0 with a fresh org move — version numbers are still v0.1.x, the repo just migrated from
Use-Tusktofencesandbox(requiring users to re-tap Homebrew and reinstall), and 18 issues are open against a small maintainer team.[1][5] - macOS dependency on a deprecated primitive — sandbox-exec has long been marked deprecated by Apple, the same foundation risk shared by every Seatbelt-based tool in this category.[1]
What Developers Say
Community discussion centers on the Show HN thread (78 points, 23 comments, early 2026); commenters mostly probed the boundaries of the tool rather than praising or panning it.[3]
"pretty close to anthropic's version, yes? or am I mistaken" — will_wright on Hacker News, questioning differentiation from sandbox-runtime[3]
"can i run user submitted untrusted code in this? and can it do a pip install if user wants?" — vivzkestrel on Hacker News[3]
"Is it also possible to block all filesystem access and only allow certain directories / files?" — uwemaurer on Hacker News[3]
"Unfortunately nested bubblewrap sandboxes don't work… Permission denied." — jy-tan, Fence creator, on a key limitation[3]
"Fence handles well supply-chain scripts that phone home, tools that write broadly across your filesystem, accidental secret leakage." — jy-tan, Fence creator (vendor voice, scoping the threat model)[3]
No substantive independent reviews beyond the HN thread exist as of June 2026; sentiment is curious-but-unproven rather than enthusiastic or critical.[3]
Pricing & Licensing
Licensing model: Apache-2.0; no paid tier, no hosted service, no telemetry-based monetization disclosed.[1]
Hidden costs: Linux requires installing bubblewrap and socat (bpftrace optional); policy tuning time when agents legitimately need domains or paths the defaults deny.[1]
Competitive Positioning
Direct Competitors
| Competitor | Differentiation |
|---|---|
| nono | Same container-free, native-OS-primitive niche; Fence's distinguishing surface is proxy-based domain allowlisting plus command deny rules, SSH filtering, and per-agent templates[1] |
| Litterbox | Container-based (Podman, Linux-only) full GUI dev environments with a confirming SSH agent; Fence is container-free, cross-platform (macOS + Linux), and wraps single commands instead of whole desktops[1] |
| Anthropic sandbox-runtime | Fence's acknowledged inspiration; Fence adds command deny rules, SSH command filtering, inbound port exposure, and templates, and targets agents beyond Claude Code[1][3] |
| Docker / devcontainers | Stronger isolation but heavyweight: daemons, images, volume mounts; Fence trades containment strength for zero-setup ergonomics[6] |
When to Choose Fence Over Alternatives
- Choose Fence when: you want one prefix command that puts default-deny network and filesystem policy around any coding agent or build script on macOS and Linux, with no container runtime installed.
- Choose nono when: you prefer its specific enforcement approach or ergonomics for the same local, container-free job — the two are the closest pair in this category.
- Choose Litterbox when: you are on Linux with Podman and want your entire GUI dev environment sandboxed, including SSH key confirmation prompts.
- Choose a microVM/container sandbox when: the code is genuinely untrusted or user-submitted — Fence's own docs rule that workload out.[6]
Ideal Customer Profile
Best fit:
- Developers running CLI coding agents (Claude Code, Codex, Amp, Gemini CLI) in permissive or auto-accept modes who want OS-level guardrails underneath[2]
- Anyone routinely running
npm install/pip install/ build scripts from unfamiliar repos and worried about phone-home or filesystem-wide writes[6] - Teams wanting embeddable policy via the Go library or repo-local
fence.jsonccommitted alongside the code[1]
Poor fit:
- Platforms executing arbitrary untrusted user code — no hostile-code containment, no resource limits[6]
- Windows-native developers (WSL only)[1]
- Workloads built on non-proxy-aware network stacks that need selective domain access rather than hard failure[6]
Viability Assessment
| Factor | Assessment |
|---|---|
| Financial Health | N/A as a free tool; backed by Tusk's internal need rather than project-specific funding[3] |
| Market Position | Early leader among container-free local agent sandboxes — 794 stars in under six months is strong for the niche[1] |
| Innovation Pace | High — ~60 releases since December 2025, active push on June 11, 2026[5][1] |
| Community/Ecosystem | Thin but real — 78-point Show HN, 31 forks, 3 watchers, 18 open issues; no major independent reviews yet[3][1] |
| Long-term Outlook | Hinges on the spun-out org sustaining maintenance beyond Tusk's internal use case, and on Apple's deprecated sandbox-exec surviving as a foundation[1] |
The spin-out from Use-Tusk into a dedicated fencesandbox org cuts both ways: it signals the maintainers see a project bigger than one company's testing pipeline, but it also resets distribution (Homebrew re-tap, new module path) and leaves governance and staffing undisclosed.[1] The release cadence and same-day pushes suggest healthy momentum as of June 2026.[5][1]
Bottom Line
Fence is the most fully-featured of the container-free local agent sandboxes: default-deny network and filesystem, command and SSH-level policy, per-agent templates, and an unusually honest security model, all behind a single command prefix. It is exactly the right tool for its stated job — reducing blast radius when a coding agent or install script does something surprising — and exactly the wrong tool for hosting hostile code, which its own docs say plainly.
Recommended for: developers running coding agents in auto-accept mode on macOS or Linux; anyone wanting supply-chain blast-radius reduction without adopting containers.
Not recommended for: untrusted user-code execution, Windows-native workflows, or anyone needing resource limits and kernel-grade isolation — use a microVM sandbox instead.
Outlook: Watch whether the independent fencesandbox org attracts contributors beyond Tusk, whether a v1.0 stabilizes the config surface, and how the project responds if Apple finally removes the deprecated sandbox-exec underpinning its macOS support.
Research by Ry Walker • methodology