DEV Community

Ahab
Ahab

Posted on • Originally published at indieseek.co

Claude Code 2.1.216 Sandbox Security Checklist

#ai #claudecode #security #programming

Claude Code 2.1.216 sandbox and worktree security checklist

Quick answer

Claude Code v2.1.216, released July 20, 2026, adds sandbox.filesystem.disabled, which lets you skip Claude Code's filesystem isolation while retaining network egress control. The same release fixes several boundary failures involving worktree-isolated subagents, symlinked .claude paths, rewind operations, and resumed background-agent restrictions.

Upgrade before relying on those boundaries, but do not switch off filesystem isolation merely to reduce friction. Anthropic's sandbox documentation says effective isolation needs both filesystem and network controls. Use the new exception only when another layer—such as a disposable container or VM—already confines filesystem access.

Use this release gate:

upgrade to 2.1.216
-> choose an isolation profile
-> run five non-destructive boundary tests
-> compare logs and sentinel hashes
-> promote gradually
Enter fullscreen mode Exit fullscreen mode

Who this is for

This guide is for developers running Claude Code locally, in CI, or through background agents, especially when using worktrees, scheduled tasks, workflows, custom sandbox settings, or long-lived sessions.

It complements the broader untrusted-repository sandbox checklist. That guide defines the trust boundary; this one verifies the concrete changes in v2.1.216. After the environment is safe, use the explicit /verify and /code-review finish gate for output quality.

What changed

The release note confirms five changes that deserve regression coverage:

Area Confirmed change Upgrade question
Sandbox configuration sandbox.filesystem.disabled can skip filesystem isolation while keeping network egress control Is another layer actually containing disk access?
Worktree isolation Isolated subagents can no longer redirect Git into the shared checkout with git -C, --git-dir, GIT_DIR, or GIT_WORK_TREE Can a test agent still reach the parent checkout?
Configuration writes Workflow and scheduled-task writes no longer follow a symlink at .claude Does an outside sentinel remain unchanged?
Rewind /rewind skips symlinked or hard-linked tracked paths and reports the skipped count Are external files protected and skips visible?
Resumed agents Background sessions restore the original agent prompt and tool restrictions instead of reverting to defaults Do restrictions survive stop and resume?

These are fixes to Claude Code's enforcement and state restoration. They do not make every command safe, inspect encrypted traffic, or isolate built-in file tools. Anthropic documents sandboxing as an OS-level boundary for Bash and its child processes; Read, Edit, Write, computer use, and MCP tools have separate controls.

Choose the right isolation profile

Profile Filesystem Network Use when
Default Claude Code sandbox Domain allowlist Normal local development
Compatibility exception External container or VM; Claude filesystem isolation disabled Claude network sandbox remains enabled A required tool conflicts with filesystem isolation and the outer runtime is disposable
Managed hard gate Claude sandbox plus container policy Managed allowlist and inspected proxy when required CI or enterprise workloads with enforceable policy

For the default profile, prefer narrow sandbox.filesystem.allowWrite entries over excluding an entire command. For a hard gate, enable sandbox.failIfUnavailable and disable the unsandboxed escape hatch with allowUnsandboxedCommands: false.

The compatibility profile may look like this on v2.1.216:

{
  "sandbox": {
    "enabled": true,
    "filesystem": { "disabled": true },
    "network": {
      "allowedDomains": ["registry.npmjs.org"]
    },
    "allowUnsandboxedCommands": false
  }
}
Enter fullscreen mode Exit fullscreen mode

Treat that configuration as a transfer of responsibility, not a security improvement. The container or VM must prevent writes to host credentials, shell startup files, other repositories, and deployment configuration.

Five-case regression matrix

Run the tests in a disposable repository with fake data. Never point a security fixture at real credentials or a production checkout.

Case Safe probe Pass condition
Network egress Request one allowed host and one harmless unlisted host Allowed request succeeds; unlisted request is blocked or prompts according to policy
Worktree redirect From an isolated subagent, run read-only git status variants using -C, --git-dir, GIT_DIR, and GIT_WORK_TREE aimed at a parent test checkout The subagent does not operate on the shared checkout
.claude symlink In a fixture repo, point .claude at an outside directory containing a hashed sentinel, then attempt to save a test workflow or scheduled task No outside file is created or changed
Rewind links Put a symlink and hard link in the fixture, change tracked content, then run /rewind Linked external targets keep their hash; Claude reports skipped paths
Restriction restore Start a background agent with one harmless tool denied, stop it, resume it, then ask for that tool The original denial still applies after resume

Record the Claude Code version, operating system, settings scopes, fixture commit, commands, prompts, exit status, prompts shown, and sentinel hashes. A pass without evidence is difficult to distinguish from a test that never reached the intended path.

Upgrade workflow

  1. Capture the current policy and run claude --version. Do not edit sandbox rules and upgrade the binary in the same unexplained change.
  2. Upgrade to v2.1.216 or newer stable release, then reopen sessions so they load the new code and settings.
  3. Run the five fixtures with the default full sandbox first. If a tool is incompatible, try a narrow allowWrite path before disabling filesystem isolation.
  4. If the compatibility exception is unavoidable, run Claude Code inside a disposable container or VM, keep the network allowlist narrow, and repeat every fixture.
  5. Canary the configuration on one low-risk repository. Watch denied operations, unexpected prompts, writes outside the repo, network destinations, and resumed-agent behavior before wider rollout.

Use this compact evidence record:

Claude Code isolation evidence
- version / OS:
- settings scope and profile:
- fixture commit:
- egress allow and deny result:
- worktree redirect result:
- symlink and hard-link sentinel hashes:
- resumed-agent restriction result:
- remaining exception and owner:
Enter fullscreen mode Exit fullscreen mode

Common mistakes

  • Reading filesystem.disabled as a recommended default instead of a compatibility escape hatch.
  • Keeping network filtering but allowing a broad domain that can receive arbitrary uploaded data.
  • Testing worktree isolation with a real shared checkout or commands that modify history.
  • Assuming Bash sandbox rules also govern Read, Edit, Write, computer use, and every MCP tool.
  • Resuming an old background session without checking whether its prompt and tool restrictions were restored.
  • Treating a successful upgrade as proof that existing managed settings, hooks, and containers still compose safely.

FAQ

Should I set sandbox.filesystem.disabled to true?

Usually no. Use it only when a separate filesystem boundary is already enforced and you have a concrete compatibility problem. For normal local development, retain both filesystem and network isolation.

Does network isolation prevent every exfiltration path?

No. Anthropic notes that the built-in proxy filters by domain and does not inspect encrypted traffic. Broad allowed domains and powerful Unix sockets can weaken the boundary. Use a TLS-inspecting proxy or stronger outer isolation when your threat model requires it.

Do the worktree fixes protect the parent repository automatically?

They close specific redirection paths named in the release. You should still keep unrelated worktree changes, credentials, Git configuration, hooks, and deployment actions outside an untrusted agent's authority.

Is v2.1.216 enough for unattended coding agents?

It is a useful security upgrade, not a complete unattended-run policy. Keep deterministic tests, scoped credentials, network controls, an irreversible-action gate, and recorded evidence.

Sources

Top comments (0)