How do I sandbox Claude Code terminal access?

Install failproof ai with npm install -g failproofai and run failproofai policies --install. The default policies constrain reads to the project root with block-read-outside-cwd, block every destructive command class (rm -rf, sudo, curl | sh, terraform destroy, force push, .env reads), and sanitize keys that appear in tool output. No container or VM required.

Is a policy sandbox as safe as a container?

A policy sandbox catches the failure modes that actually happen - destructive command classes the model picked, secrets it read by mistake, branches it pushed to. A container adds a kernel boundary on top, which is useful if you also care about exploits in compiled binaries. The two stack cleanly. Most teams start with policies because they install in two commands and require zero workflow change.

Can I confine Claude Code reads to the project root?

Yes. block-read-outside-cwd is a PreToolUse policy that refuses any read tool call or bash invocation that targets a path outside the project root. You can add explicit allowlist entries (the cargo cache, the go module cache, ~/.aws/config) for paths the agent legitimately needs.

block-secrets-write refuses writes to .key, .pem, and other secret-shaped files. block-env-files refuses writes to .env files. block-rm-rf refuses recursive deletion outside the safe-path allowlist. Together these stop the most destructive write classes without blocking the agent from doing real work in source files.

How to Sandbox Claude Code Terminal Access

Why a container isn't the only answer

The reflexive instinct is “put claude code in a container.” That works, but it's heavy. You need to mount the project, wire up your git credentials, deal with file-permission mismatches, keep the image current. The agent loop also slows down because every shell call now crosses a process boundary you didn't need.

A policy sandbox is the lighter version. Almost every “the agent did something terrible” incident reduces to a small set of command classes: recursive deletion, sudo escalation, curl | sh, force pushes, terraform destroy, DROP TABLE, .env reads. Block the classes and the failure mode goes away. No kernel boundary needed.

The three sandbox layers

failproof ai composes the sandbox out of three hook layers, each doing one job.

PreToolUse: refuse unsafe calls before they run

block-read-outside-cwd - constrains reads to project root. Exceptions allowed (e.g. ~/.aws/config)
block-secrets-write - refuses writes to .key, .pem, and other secret-shaped files
block-rm-rf, block-sudo, block-curl-pipe-sh - the destructive-command core set
block-env-files, protect-env-vars - refuses .env and printenv-style dumps
block-push-master, block-work-on-main, block-force-push - git safety
block-terraform, block-kubectl, block-aws-cli, block-gcloud, block-az-cli, block-helm, block-gh-pipeline - opt-in infra blockers

PostToolUse: sanitize what comes back

sanitize-api-keys (Anthropic, OpenAI, GitHub, AWS, Stripe, Google), sanitize-jwt, sanitize-connection-strings, sanitize-private-key-content, sanitize-bearer-tokens

If a secret made it past the PreToolUse layer, the sanitizers redact it before the result re-enters the agent context. The model never sees the raw value, so it can't propagate it.

Stop: gate the way out

require-commit-before-stop - refuses to end with uncommitted changes
require-push-before-stop - refuses to end with unpushed commits
require-pr-before-stop - requires an open PR
require-no-conflicts-before-stop - refuses to end with a conflicted PR
require-ci-green-before-stop - refuses to end with red CI

Install (two commands)

The default set is the sandbox for a developer machine. For a production-adjacent project, enable the cloud and infra blockers from the dashboard at http://localhost:8020.

When you also want a container

Stack them. The container gives you a kernel boundary against whatever binaries the agent compiles and runs. The policy sandbox gives you fine-grained refusal at the command level - the container can't tell the difference between rm -rf /tmp/build and rm -rf /home/dev/project, but failproof can. Use both for agents driving production deploys; use policies only for day-to-day dev.

Tightening the sandbox per project

Drop a .failproofai.json at the project root to override the default policy set. The schema is documented at docs.befailproof.ai/configuration. Common overrides:

Block npm publish hard (promote warn-package-publish to deny)
Allow rm -rf .next by adding it to block-rm-rf's safe-path list
Disable require-ci-green-before-stop on a repo without CI
Add a custom JS policy that blocks npm install <non-pinned>

Get started

book a demo →