Fence
A lightweight, container-free command sandbox that blocks network by default and restricts the filesystem — defense-in-depth for semi-trusted code and AI coding agents.
Evidence shows default-deny networking, configurable filesystem and command deny rules, and SSH filtering, consistent with least privilege (2); but no pre-execution confirmation mechanism (1), no sensitive-data guidance (1), no rollback/recovery path (1). Config visibility (config show, -m monitor, log file) supports data-flow transparency (2). Dependencies pinned in go.mod with a small surface (2). External effects constrained via deny rules (2). Attribution clear: Apache-2.0, copyright Tusk AI, credit to Anthropic sandbox-runtime (2).
README and CI workflows are consistent: CI verifies sandbox dependencies on Linux (bwrap/socat/subuid) and macOS (sandbox-exec), then runs build, lint, tests, and smoke tests (2, 2). Failure examples (403, blocked commands) and monitor mode indicate concrete error reporting (2), though all asserted, not executed.
Audience clearly stated: semi-trusted code, CI, AI coding agents, with a list of supported agents (3). Config inheritance, templates, and schema enable customization (2). Explicit macOS/Linux support (Nix incl. WSL); no native Windows (2). Boundaries are clear at config level, but sandbox-escape boundary is not elaborated in this evidence (2).
Well-organized docs: README, docs/, schema, architecture, hosted docs (3). Install instructions cover multiple channels including repo-migration notes (3). Rich examples (3). Full Apache-2.0 LICENSE (3). SECURITY.md defines 90-day disclosure and contact (2). Deductions: no CHANGELOG, version only via release badge (1); known limitations/security model only linked, not substantiated in evidence (1); repo renamed from Use-Tusk/fence, so naming was unstable (2).
config show separates chain info to stderr and JSON to stdout for piping (2). A container-free lightweight sandbox compatible with many agents has clear marginal value (3). Cost/benefit reasonable but no performance data in this evidence (2).
Claims about dependencies, platforms, and tests are partly corroborated by CI workflows (2); assertions traceable via config show and -m (2); facts vs inference distinguishable but nothing executed (2). Static review rests only on README/workflows/LICENSE/go.mod/SECURITY without the source code or docs bodies themselves, hence low confidence.
- Publisher identity is unverified and the repo migrated (Use-Tusk → fencesandbox); switch install channels per the README migration instructions to avoid stale taps/go install paths.
- Sandbox claims are unexecuted: sandbox-exec is deprecated on modern macOS — verify isolation strength on your target system; bwrap requires setuid/user-namespace setup, misconfiguration weakens isolation.
- No evidence of rollback/recovery or pre-execution confirmation; protection against destructive commands depends on deny-rule completeness — audit fence.c and inspect the effective config with `fence config show`.
- No CHANGELOG; version history is not statically traceable — consult Release notes before upgrading.
- Sensitive-data handling and sandbox-escape boundaries are only linked, not substantiated here; read docs/security-model.md before using for high-risk workloads.
What does this agent do, and when should you use it?
Fence is a CLI sandbox that wraps arbitrary commands in a controlled environment: all outbound network is blocked by default, and filesystem read/write access is governed by configurable rules. It achieves cross-platform isolation without containers, using sandbox-exec on macOS and bubblewrap with seccomp/Landlock on Linux. Beyond sandboxing, it acts as a permission manager for CLI coding agents such as Claude Code, Codex, and Gemini CLI, letting you allowlist domains, grant write paths, deny dangerous commands like rm -rf / and git push, and filter SSH commands. Configuration lives in fence.c/fence. with JSONC support and inheritance via extends, complemented by built-in templates, real-time violation monitoring (-m), and Claude Code permission import. The project is Apache-2.0 licensed, usable as both a CLI and a Go package, with docs at fencesandbox.com/docs.
Fence intercepts and wraps commands (e.g., fence curl https://example.com, fence -t code -- claude): network is fully blocked by default (403 Forbidden) except for domains listed in allowedDomains; filesystem operations follow allowWrite-style rules; command.deny blocks dangerous operations such as rm -rf /, git push, and npm publish, with SSH host/command filtering also supported. Config is discovered from fence.c in the current/parent directories or ~/.config/fence/fence.c, supports extends inheritance from templates like code and @base repo-local overrides; fence config show prints the config chain and merged JSON (pipeable to jq), fence config init scaffolds a starter config, and fence import --claude --save imports Claude Code permissions. Monitor mode (-m) logs blocked requests in real time, with --fence-log-file for logging and optional bpftrace on Linux for filesystem violation visibility.
- A developer running semi-trusted package installs like npm install who wants network off by default with only npm/pypi domains allowed, via the -t code template.
- A team executing code in CI jobs or freshly cloned unfamiliar repos, wanting to scope file writes and block git push.
- Users of AI coding agents (Claude Code, Codex, Gemini CLI, etc.) who want a permission layer over the agent's network, filesystem, and command actions (fence -t code -- claude).
- Teams with existing Claude Code permission setups who want to migrate via fence import --claude --save.
- Operations staff auditing sandbox enforcement, using fence -m --fence-log-file /tmp/fence.log to record violations.
- Corporate environments that need access to a private domain like private.company.com, permitted precisely through allowedDomains.
What are this agent's strengths and limitations?
- Container-free isolation via macOS sandbox-exec and Linux bubblewrap/Landlock/seccomp — far lower startup and deployment overhead than container-based alternatives.
- Default-deny networking with domain allowlists, path-level filesystem permissions, and dangerous-command blocking gives layered defense rather than a single switch.
- Built-in templates plus config inheritance (extends, @base overrides), and fence config show emits merged config as jq-friendly JSON for auditing and team sharing.
- Explicit support for mainstream coding agents (Claude Code, Codex, Gemini CLI, etc.) with hooks docs and Claude Code permission import.
- Split platform mechanisms: sandbox-exec on macOS versus bubblewrap and socat on Linux, so behavior and dependencies differ across platforms.
- Native Windows is not supported; Nix docs mention running only via WSL.
- Sandbox-escape strength lacks independent evidence; the README only claims default blocking, so review the security model docs for your risk profile.
- As a recently renamed project (from Use-Tusk/fence), community size and long-term maintenance need your own evaluation.
How do you install or deploy this agent?
macOS/Linux one-liner: curl -fsSL https://cli.fencesandbox.com/install.sh | sh. Homebrew (macOS): brew tap fencesandbox/tap && brew install fencesandbox/tap/fence. Nix: nix run nixpkgs#fence -- --help. Go: go install github.com/fencesandbox/fence/cmd/fence@latest. From source: git clone https://github.com/fencesandbox/fence && cd fence && go build -o fence ./cmd/fence. Note the project moved from github.com/Use-Tusk/fence to fencesandbox/fence — old Taps and go install paths must be migrated per the README. Linux requirements: bubblewrap (required), socat (required), bpftrace (optional).
How do you use this agent?
Basics: fence curl https://example.com (network blocked, returns 403); fence -c "echo hello && ls" (shell expansion); fence -d <cmd> (debug logging); fence -t code -- claude (run Claude Code under the code template); fence -m npm install (violation monitoring). Use -- to pass flags to the wrapped command, e.g. fence -- claude --dangerously-skip-permissions. Configuration: create a fence.c in the project or ~/.config/fence/, e.g. {"extends":"code","network":{"allowedDomains":["private.company.com"]},"filesystem":{"allowWrite":["."]},"command":{"deny":["git push","npm publish"]}}; inspect with fence config show, scaffold with fence config init.