Bound Claude Code safely with permissions and sandboxing

Two different defence layers

Permissions decide which actions can run freely or require confirmation. Sandboxing technically limits where processes can read, write or connect. Use both: approval addresses intent while isolation limits impact when intent or interpretation fails.

Start with minimum access

Allow only routine reads and verification commands the project needs. Keep broad shell patterns, system directories, network access and external mutations approval-gated or unavailable by default. Add exceptions only for a concrete need.

Protect filesystem and network separately

Write access inside a workspace says nothing about outbound traffic. Define required paths and hosts separately, and prevent credentials in the environment from reaching an unknown destination.

Be careful with exclusions

An excluded folder or command can create unexpected routes through symlinks, scripts and nested processes. Test effective behaviour from the agent environment rather than trusting configuration readability alone.

No. It limits impact but cannot judge product decisions, data quality or legitimate yet unwanted actions.

Treat web content as untrusted

Documentation, issues and tool output can contain instructions unrelated to the task. Never let external text automatically change project rules or permissions, and confirm actions that transmit or publish data.

Maintain and test the boundary

Test allowed and blocked scenarios, review rules when tooling changes and remove temporary exceptions. Record who may approve a permissions or sandbox configuration change.

{"permissions":{"allow":["Read(src/**)","Bash(pnpm test)"],"deny":["Read(.env*)"]}}

Make Claude Code permissions and sandbox verifiable

The decision review for Claude Code permissions and sandbox first focuses on one repository task with separate read, write, shell and network permissions visible before execution. Define the acceptable user outcome, essential inputs and authorised approver for Claude Code permissions and sandbox before the trial starts. Keep the first Claude Code permissions and sandbox trial small enough to separate causes from effects.

Build evidence for Claude Code permissions and sandbox around one realistic successful route and also simulate a broad wildcard, access to environment files and a network destination outside the approved task. For every Claude Code permissions and sandbox check, record the expected outcome, visible evidence and recovery action when it fails. The final decision question for Claude Code permissions and sandbox is: “Does sandboxing remove the need for human review?”

Claude Code permissions and sandbox: from trial to everyday operation

Assign Claude Code permissions and sandbox one operational owner, one subject reviewer and a clear fallback route. Treat the Claude Code permissions and sandbox checklist as separate evidenced steps, so punctuation or phrasing never becomes part of the process logic. Ask the relevant user to complete Claude Code permissions and sandbox without spoken help and record every point that still needs explanation or manual recovery.

Keep change rights, logging, support and review dates for Claude Code permissions and sandbox in one operating plan. Repeat the Claude Code permissions and sandbox trial after a change to source data, configuration, model, integration or user role. Expand Claude Code permissions and sandbox only when the team can also detect, contain and recover a broad wildcard, access to environment files and a network destination outside the approved task.

Stop the Claude Code permissions and sandbox rollout while a broad wildcard, access to environment files and a network destination outside the approved task is not reported visibly and recoverable by the assigned owner.