Claude Code’s Sandbox Still Needs Both File and Network Boundaries

Configure Claude Code’s Bash sandbox as an execution boundary, not as a switch for eliminating prompts. Auto-allow and regular-permissions modes enforce the same filesystem and network restrictions; the difference is whether commands that remain inside those boundaries require approval.

A hardened baseline confines writes to the repository and session temporary directory, blocks reads of credentials, limits outbound connections to required destinations, and disables unsandboxed retries. Permission rules remain a separate control for consequential operations such as pushing code, publishing packages, or deploying.

Start with both escape paths

A filesystem boundary limits what a compromised command can read or modify. A network boundary limits where that command can send data or retrieve additional code. Neither substitutes for the other.

Anthropic’s sandboxing architecture combines OS-enforced filesystem isolation with a proxy-controlled network boundary. Anthropic explains that network isolation alone leaves a compromised process able to alter host resources, while filesystem isolation alone leaves accessible data exposed to exfiltration.

Define the required access before adding exceptions. Routine repository work may need to edit the checkout, create build artifacts, use temporary storage, and reach selected package or source hosts. That does not imply access to SSH material, cloud credentials, shell startup files, unrelated repositories, Docker control sockets, or production endpoints.

Build a minimal hardened profile

The official Claude Code sandbox documentation confirms that /sandbox opens the configuration panel, macOS uses Seatbelt, and Linux and WSL2 use bubblewrap; native Windows is unsupported. It also documents the two modes, the normal permission fallback, default writable locations, network controls, credential rules, and strict fallback settings.

1. Start Claude Code from the repository root. The working directory and its descendants become the default project write scope, alongside a separate session temporary directory.
2. Enable the sandbox. Select auto-allow when commands inside the boundary may run without individual approval; select regular permissions when every Bash command should still follow normal approval handling.
3. Set failIfUnavailable to true wherever sandboxing is mandatory. Without that setting, a missing dependency or unsupported platform produces a warning and commands can run unsandboxed.
4. Set allowUnsandboxedCommands to false for a strict profile. This disables retries using dangerouslyDisableSandbox; commands must then remain sandboxed or be explicitly listed as excluded.
5. Add only the write paths and network destinations required by the workflow. Each exception expands what a command and its child processes can reach.

Organizations should enforce non-negotiable controls through managed settings. Filesystem path arrays from different settings scopes are merged rather than replaced, so a narrow managed list can otherwise be widened by user or project entries; managed-only restrictions are available where developers must not expand the policy.

Make the filesystem boundary protect reads as well as writes

By default, sandboxed commands can write to the working directory and session temporary directory. They can also read much of the host filesystem, including credential locations unless those paths are expressly protected. Write confinement alone is therefore not a confidentiality boundary.

Use sandbox.credentials or filesystem.denyRead for SSH keys, cloud credentials, environment files, signing material, and other secrets. Grant additional writes only to the smallest stable path a tool genuinely needs, such as a dedicated build cache, rather than a home directory or broad parent path.

Be especially cautious with writable shell startup files, executables on the shell search path, and configuration loaded by later commands. A process may plant a change that executes after the restricted command ends. Access to a Docker socket is similarly powerful because it exposes a host service rather than an ordinary project file.

Keep network access destination-specific

No network domains are pre-approved by default. A new destination can trigger approval, while allowedDomains can pre-authorize known hosts. For a fixed boundary, strictAllowlist denies destinations outside the effective allowlist instead of prompting; centrally managed environments can use allowManagedDomainsOnly to accept only administrator-defined entries.

A package workflow may require both a registry and separate artifact hosts, so establish the actual destination set before locking the list. Remove temporary entries when the workflow changes, and keep production APIs, deployment control planes, arbitrary webhooks, and personal storage outside the ordinary development policy.

An approved domain remains a possible exfiltration destination. The built-in proxy filters by hostname and does not inspect TLS traffic by default, so a reputable code-hosting or storage service is not automatically a safe destination for every workload. Higher-assurance environments may need an organization-controlled proxy or the documented TLS-termination controls.

Separate isolation from approval policy

Claude Code’s permission rules control which tools and commands may run, with deny rules evaluated before ask and allow rules. The Bash sandbox instead constrains the filesystem and network access of an executing command and its child processes; built-in Read, Edit, Write, WebFetch, and MCP tools remain subject to their own permission boundaries.

In auto-allow mode, a Bash command that stays inside the sandbox can run without a general Bash prompt. Explicit deny rules still apply, and content-scoped ask rules such as Bash(git push *) can still force confirmation. Regular-permissions mode preserves the same isolation while sending every Bash command through the regular permission flow.

A command blocked by the sandbox does not silently gain host access. If unsandboxed retries are enabled, Claude Code may propose rerunning it outside the sandbox, where the normal permission flow evaluates it. That is a visible fallback, but approval would still remove the sandbox boundary for that execution; disabling unsandboxed commands closes the path.

Match the policy to the workflow

• Repository editing and tests: allow writes to the checkout and session temporary directory, protect credentials, and permit only the destinations the tests require.
• Package installation: add the verified registry and artifact hosts while keeping install scripts under the same filesystem restrictions.
• Deployment: keep production endpoints outside the routine development allowlist and retain ask or deny rules for push, publish, infrastructure, and deployment commands.
• Incompatible tools: prefer a narrow path or domain exception. If exclusion from sandboxing is unavoidable, treat the command as host-level execution and retain the regular permission gate.

Fewer prompts mean that more commands fit inside a predefined boundary; they do not mean Claude Code has unrestricted host access. The defensible configuration lets routine work proceed inside both boundaries while unusual file access, new network destinations, and consequential operations remain blocked or deliberately approved.

Also read:

• Figma’s Design Agent Is Open Beta—Paid Access Still Has Boundaries
• Claude Code vs OpenAI Codex: What Published Coding Tests Actually Show
• The Network Perimeter Is Not Enough—Every Access Request Becomes a Boundary