Claude Code Sandbox Settings: filesystem.disabled and strictAllowlist Explained (2026)

Claude Code’s sandboxed Bash tool has always bundled two kinds of isolation into one boundary: what a command can touch on disk, and what it can reach over the network. Two recent releases pull that bundle apart and give you an escape hatch for hanging prompts. sandbox.filesystem.disabled, shipped in v2.1.216 (July 20, 2026), lets you turn off filesystem isolation while keeping network egress locked down. sandbox.network.strictAllowlist, shipped four days later in v2.1.219 (July 24, 2026), changes what happens when a sandboxed command tries to reach a domain that isn’t on your allowlist — instead of a permission prompt, it’s a silent deny.

Neither setting is a toggle for “more sandboxing” or “less sandboxing” in the abstract. They’re both about precision: letting you keep exactly the restriction you need and drop the one that’s getting in your way. This matters most in two situations — projects where you trust Claude Code with the filesystem but not with the network, and CI pipelines where there’s no human around to answer a prompt.

What Claude Code’s Sandbox Isolates by Default

Before touching either setting, it’s worth being precise about the baseline, per the official sandboxing documentation. When sandbox.enabled is true, Claude Code’s sandboxed Bash tool enforces two independent layers at the OS level (Seatbelt on macOS, bubblewrap on Linux and WSL2):

Filesystem isolation:

• Write access is restricted to the current working directory and the session temp directory ($TMPDIR is pointed there for sandboxed commands).
• Read access covers the entire machine by default, except explicitly denied paths — which notably means credential files like ~/.aws/credentials and ~/.ssh/ are readable unless you separately lock them down with sandbox.credentials.
• Modifying files outside the working directory — shell configs like ~/.bashrc, system binaries in /bin/, or Claude Code’s own settings.json files at every scope — is blocked without explicit permission.

Network isolation:

• No domains are pre-allowed by default. The first time a sandboxed command needs a new domain, Claude Code prompts for approval. As of v2.1.191, saying yes allows that host for the rest of the session, so you’re not re-prompted for the same domain twice.
• You can pre-allow domains with sandbox.network.allowedDomains to skip the prompt entirely, or block them outright with sandbox.network.deniedDomains (which always wins over an allowedDomains match, even a wildcard).
• A managed-settings-only setting, network.allowManagedDomainsOnly, already existed before this release: it forces a silent deny for any domain not in a managed-settings allowedDomains list. It requires an administrator to deploy managed settings — it’s not something an individual developer or a repo’s .claude/settings.json can turn on.

Both layers are enforced on every subprocess a sandboxed Bash command spawns — kubectl, terraform, npm, whatever — not just Claude’s own file-editing tools. That’s the important context for what the two new settings actually change: they don’t add a third layer, they let you selectively disable or tighten one of the two that already exist.

sandbox.filesystem.disabled: Keep the Network Boundary, Drop the Filesystem One

sandbox.filesystem.disabled does exactly what it says: it turns off the filesystem isolation layer while leaving network isolation fully intact. The canonical example from Anthropic’s docs:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "disabled": true
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

With this configuration, sandboxed commands get unrestricted read and write access to the host filesystem — no working-directory boundary, no denied paths — while their network egress stays confined to whatever’s in allowedDomains. The framing in the docs is direct: “Turn the layer off when you sandbox to control where commands connect rather than what they write.”

Three things worth knowing before you flip this:

It’s off by default, and it requires Claude Code v2.1.216 or later. It applies on every platform the sandbox runs on — macOS, Linux, WSL2.

It’s not settable from project config. Only user settings (~/.claude/settings.json), managed settings, or the CLI’s --settings flag can set filesystem.disabled. A repository’s .claude/settings.json or .claude/settings.local.json cannot — so a project you check out from someone else can’t silently widen your filesystem access. If managed settings configure any part of sandbox.filesystem, or list any sandbox.credentials.files entry, the lock tightens further: only managed settings can set the key at all, which stops a developer from overriding an administrator-deployed filesystem restriction.

Turning it off also turns off things you might not expect. The read protections from filesystem.denyRead and credentials.files stop applying, because both are enforced by the filesystem layer you just disabled (credentials.envVars deny/mask rules still apply, since env-var scrubbing is a separate mechanism). Sandboxed commands also stop getting the isolated session temp directory and inherit your shell’s regular $TMPDIR instead. And — this is the one to actually sit with — the deny rule that normally stops a sandboxed command from overwriting ~/.claude/settings.json or your shell startup files goes away too. Anthropic’s own warning is blunt about the implication: with filesystem isolation off and commands auto-allowed, a sandboxed command can write files that a later command reads or runs — a shell config file, something on $PATH, its own settings file — and use that to widen its own access on the next run. Locking network domains with allowManagedDomainsOnly narrows that risk (a compromised command still can’t exfiltrate what it wrote) but doesn’t remove it, since that lock only applies to commands running inside the sandbox in the first place.

The practical read: filesystem.disabled is for workloads you trust not to try to escalate their own access, where the risk you actually care about is data leaving the machine, not files changing on it.

sandbox.network.strictAllowlist: Deny Instead of Prompt

The second setting addresses the other half of the equation. Under default network isolation, a sandboxed command hitting an unlisted domain triggers a permission prompt — fine in an interactive terminal session, useless in a non-interactive one. sandbox.network.strictAllowlist, added in v2.1.219, changes that: instead of prompting for a host that isn’t on the allowlist, Claude Code denies it outright, without asking.

This is functionally the same behavior change that network.allowManagedDomainsOnly already provides — automatic deny instead of a prompt — but the two solve different deployment problems. allowManagedDomainsOnly is a managed-settings-only lockdown: it requires an administrator to push organization-wide policy, and once set, it also restricts which allowedDomains are honored (managed-settings entries only, ignoring user/project/local additions). strictAllowlist, going by its naming and its place alongside the other individually-settable keys under sandbox.network (allowedDomains, deniedDomains, httpProxyPort), targets the case where you don’t have — or don’t need — an organization-wide managed settings deployment. You just need one machine, one CI job, or one project to fail closed instead of hanging on a prompt nobody’s there to answer.

The syntax follows the same nesting convention as every other sandbox.network.* key:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "strictAllowlist": true,
      "allowedDomains": ["github.com", "registry.npmjs.org", "pypi.org"]
    }
  }
}

A caveat worth stating plainly: as of this writing, Claude Code’s full settings reference table hadn’t yet been updated with strictAllowlist’s dedicated row — it currently only appears in the v2.1.219 changelog entry, three days after release. The changelog wording itself is unambiguous about the core behavior (“deny non-allowlisted hosts for sandboxed commands without prompting”), and the JSON shape above follows the established pattern for boolean sandbox flags. But if you’re deploying this in a managed-settings context, verify the exact scope restrictions (which settings sources can set it, whether it merges the same way allowedDomains does) against the current Claude Code settings reference before you rely on it for a compliance requirement — the table there is the one Anthropic keeps current.

Practical Scenarios

Mixed-trust project. You’re running Claude Code against a large codebase you fully own and trust — you want it editing files anywhere in the repo, touching config, moving things around without asking each time. What you don’t trust is what a compromised dependency or a bad prompt injection in a fetched file might try to phone home to. That’s exactly the split filesystem.disabled plus a tight network.allowedDomains gives you: full local file access, but the only way data leaves the machine is through a domain you explicitly named. This is the scenario Anthropic’s own docs example targets directly.

CI and headless pipelines. Run claude -p in GitHub Actions or any other non-interactive context and the sandbox’s default network prompt is a dead end — there’s no terminal to answer it, and depending on your setup, the run either hangs until it times out or silently falls through to whatever fallback behavior you’ve configured. strictAllowlist turns that failure mode into an immediate, deterministic one: an unlisted host fails the request the moment it’s attempted, the same way a firewall rule would, instead of stalling the job. For teams that already run Claude Code in automated pipelines — see our guide on fixing Claude Code permission errors in GitHub Actions — this is the piece that makes sandboxed network egress behave predictably under automation instead of just interactively.

How These Interact With Existing Permission Settings

It’s worth being clear that sandbox settings and Claude Code’s permission rules are two separate systems that happen to cover overlapping ground, per the docs’ own framing:

• Permission rules (allow/deny/ask in settings.json, covered in the permission modes guide) are evaluated before a tool runs, based on the command string Claude proposes. They apply to every tool — Bash, Read, Edit, WebFetch, MCP.
• Sandboxing is OS-level enforcement on the running process, applying only to Bash and its child processes. It holds regardless of what the model intended to run, which is the entire point — it constrains the actual syscall, not the string Claude wrote.

Filesystem and network boundaries can be set through both systems, and Anthropic’s docs note that paths and domains from sandbox.filesystem/sandbox.network settings and from permission rules (Edit allow rules, WebFetch allow/deny rules) get merged into the final sandbox configuration. Read/Edit deny rules still block access to specific files independent of filesystem.disabled — that’s a permissions-layer restriction, not a sandbox one, so turning off filesystem isolation doesn’t touch it for the built-in file tools. It only removes the OS-level restriction on what subprocess commands like npm or terraform can write.

One more distinction that trips people up: neither of these settings is a permission mode. /sandbox’s auto-allow mode decides whether a Bash command runs without a prompt because the sandbox boundary contains it; auto mode decides whether a tool call runs at all via a classifier. They’re independent and can be combined — strictAllowlist doesn’t change whether Claude asks before running a command, only what happens once a sandboxed command tries to reach a network host that isn’t on the list.

FAQ

Does sandbox.filesystem.disabled disable the sandbox entirely? No. It only turns off the filesystem isolation layer. Network isolation — allowedDomains, deniedDomains, prompts for new hosts — keeps running exactly as before. Sandboxed commands still get unrestricted network behavior gated by whatever your network settings say.

Can I set sandbox.filesystem.disabled in my project’s .claude/settings.json so my whole team gets it? No, and that’s intentional. It’s only honored from user settings (~/.claude/settings.json), managed settings, or the --settings CLI flag — not from .claude/settings.json or .claude/settings.local.json. Anthropic’s docs are explicit that this stops a checked-out project from silently widening a developer’s filesystem access. Each developer (or an administrator, via managed settings) has to opt in individually.

What happens to strictAllowlist if a domain is in deniedDomains but not in allowedDomains? Explicit deny rules take precedence over any allow behavior in Claude Code’s sandbox network model, and that hasn’t changed with strictAllowlist — deniedDomains entries are merged from every settings source regardless of allowlist mode. The setting changes what happens for hosts that are simply unlisted, not how conflicts between explicit allow and deny entries resolve.

Do I need strictAllowlist if I already use allowManagedDomainsOnly? Not necessarily. allowManagedDomainsOnly is managed-settings-only and already forces a silent deny for anything outside a managed-settings allowlist — it also restricts which allowedDomains sources count. strictAllowlist targets the case where you don’t have (or don’t want) an org-wide managed deployment: a single project or CI job that needs deterministic denies without an administrator pushing policy. If you already run managed settings with the lockdown enabled, strictAllowlist doesn’t add anything on top of it for those sandboxed commands.

Is turning off filesystem isolation safe for an untrusted repository? No. Anthropic’s own warning is direct: with filesystem isolation off, a sandboxed command can write files a later command will read or execute — shell configs, $PATH executables, even Claude Code’s own settings files — and use that to widen its access on the next run. Locking allowedDomains narrows the blast radius but doesn’t close it. Reserve filesystem.disabled for code and workloads you already trust not to try to escalate.

Related Reading

• Claude Code Permission Modes and Rule Syntax: Complete Guide (2026)
• Claude Code in GitHub Actions: How to Fix Permission Errors
• Automated PR Reviews with Claude Code Headless Mode
• claude -p Troubleshooting: 5 Headless Mode Failures (2026)
• Claude Code Security Rules: OWASP Top 10 Compliant AGENTS.md Template
• Claude Code settings.json in Teams: How to Prevent Conflicts and Share Config Safely