Fence logo
Fence

Lightweight sandbox for terminal agents.

Fence wraps any command in a pragmatic OS sandbox for macOS and Linux: default-deny outbound network, scoped filesystem access, dangerous command blocking, and reviewable policy for agents, CI, and unfamiliar repos.

GitHub stars badgeGitHub release badgeGitHub license badge
Install
macOS uses generated Seatbelt profiles via sandbox-exec, so there is no extra sandbox package to install first.
~/repo
$ fence -- claude --dangerously-skip-permissions
You
make the preview deploy flow more reliable
Claude
thinking...
$ touch .env
<- touch: .env: Permission denied
$ curl https://api.vercel.com/v9/projects
<- Connection blocked by network allowlist
$ git push origin HEAD
<- command blocked by policy: git push origin HEAD
Claude
Tightened the local deploy script and updated the tests. I could not write a local `.env`, call the Vercel API, or push from inside the fenced session, so secrets and remote-changing steps stayed explicit.

Quick start

Get one workflow working.

Install Fence with the instructions above. Start from the built-in code template, observe what your workflow actually needs, then run it normally with a policy you can keep. Here's an example for sandboxing Claude Code:

  1. 1

    Create a starter policy

    Start from the built-in code template for common coding workflows.

    $fence config init
  2. 2

    Run in monitor mode

    Wrap your agent or command so you can see what gets blocked.

    $fence -m claude
  3. 3

    Refine the policy

    Allow only the domains, paths, and commands your workflow actually needs.

  4. 4

    Run normally

    Once the policy feels right, run the same workflow without monitor mode.

    $fence claude
Optional shortcut

Already use Claude Code? Import its existing permissions instead:

$fence import --claude --save

Why Fence

Clear policy, real local workflows, and no VM overhead.

Fence is intentionally narrow: it lets you keep using the repos, tools, and local state you already have, while putting clear limits around what a command can touch. That gives you practical guardrails for agents and risky workflows without moving everything into a VM or container.

Default-deny outbound network

Block network access by default, then allowlist only the domains a repo or agent actually needs.

Path-scoped filesystem policy

Writes stay denied until you opt into specific paths, while sensitive targets remain protected.

Command-level guardrails

Stop risky commands like git push, npm publish, or destructive shells before they execute.

Monitor blocked attempts

Use -m to see what a workflow tried to access and tune the smallest policy that still works.

Templates that match real workflows

Start from the provided templates, then refine rules based on your needs.

Config inheritance without copy-paste

Inherit a built-in template or shared team config, then layer only the extra domains, paths, and command rules as required.

fence.jsonreviewable repo policy
{  "extends": "code",  "network": {    "allowedDomains": ["api.anthropic.com", "github.com"]  },  "filesystem": {    "allowWrite": ["."],    "denyRead": ["~/.ssh", ".env"]  },  "command": {    "deny": ["git push", "npm publish"]  }}

Platforms

Native on macOS and Linux.

Fence keeps one policy model across both OSes, but the sandbox backend and visibility stack adapt to each platform.

macOS

On macOS, Fence keeps the workflow close to normal local development: same repo, same local tools, and clear visibility when something gets blocked.

Sandbox engine
Generated Seatbelt profiles via sandbox-exec
Filesystem model
Path allow/deny rules plus macOS Unix socket allowlisting
Interactive sessions
allowPty support for terminal apps, editors, and TUIs
Visibility
Log-stream based violation visibility with no extra sandbox dependency

Agent compatibility

Fence wraps the agents you already use.

Default template

Start with code.

The code template gives CLI agents a practical coding baseline: common model APIs, Git hosts, and package registries are allowlisted; the workspace plus normal agent config and cache directories stay usable; and risky reads, writes, and commands like git push, npm publish, and sudo stay blocked by default.

Default launch

Use the built-in template directly when you want the shortest path into a guarded session.

$fence -t code -- claude
Already using a config that extends code?

Once your own policy inherits from the template, you can wrap the same agent with the shorter command.

$fence claude
Popular agents
Claude Code
Codex CLI
Cursor Agent
Amp
Droid
OpenCode
Gemini CLI
Pi

... and many more

Beyond these popular examples, Fence can also wrap other agent CLIs while keeping the same policy model across repos and CI jobs.

Comparison

Fence vs agent sandboxes vs containers.

Fence is built for real host-native workflows: the repos, tools, and local state you already have. Agent sandboxes stay product-specific, and containers can isolate more strongly, but usually with more setup and more friction.

CapabilityFenceAgent sandboxContainers
Works across CLI agents and plain commands
Policy you can commit and reuse across local dev and CI
Default-deny outbound with domain allowlisting
Scoped filesystem rules for host-repo workflows
Command-level blocking
No Docker or VM setup required
macOS and Linux host-native workflow
Yes
No
Partial or possible with extra setup

FAQ

Fence FAQ