Claude Code Auto Mode and Sandbox Settings: What to Turn On (and Leave Off), October 2026

The Claude Code changelog lists ten releases from 2.1.301 to 2.1.314 (read 2026-10-30; some version numbers in that range had no entry in what I read), and a surprising share of them touch permissions. If you only change three things, make them these: set defaultMode to auto in your user settings (not the project file), turn on permissions.blockWritesOutsideWorkingDirectories, and leave sandbox.allowNestedUserNamespaces off. The rest of this post is the reasoning, and a settings file to copy.

I read the Claude Code changelog, the settings page and the permission-modes page on 2026-10-30. I did not install or run these versions in this session, so everything below is what the docs say, not what I observed. Where the changelog is silent on an effect, I say so instead of filling the gap.

What is Claude Code auto mode, and how do you start it?

Auto mode is a permission mode where Claude runs most actions without prompting you, while a separate classifier model reviews each action first. The docs say the classifier blocks anything that escalates beyond your request, targets unrecognised infrastructure, or appears driven by hostile content Claude read. Explicit ask rules still force a prompt.

Blocked by default, per the docs: downloading and executing code (curl | bash), sending sensitive data to external endpoints, production deploys and migrations, force push and git reset --hard, terraform destroy, granting IAM or repo permissions, merging a pull request nobody approved, and printing live credentials into the transcript. Allowed by default: local file operations in the working directory, installing dependencies declared in lock files, read-only HTTP requests, and pushing to branches of the repository you're in unless the branch name marks a deploy target.

You enter it with Shift+Tab in the CLI, claude --permission-mode auto, or "defaultMode": "auto" in ~/.claude/settings.json. The docs add a trap: auto in .claude/settings.json or .claude/settings.local.json doesn't take effect, which is a common reason a session starts in Manual mode. The documented requirements on 2026-10-30: all plans, certain models per provider, and on Team and Enterprise admins can disable it with permissions.disableAutoMode. With Claude Code 2.1.283 or later, auto is the built-in starting mode for interactive terminal and VS Code sessions.

Limits worth knowing before you rely on it:

• Fallback. After 3 blocks in a row or 20 in total, auto mode pauses and prompting resumes.
• Your instructions aren't rules. If you tell Claude "don't push", the classifier may honour it, but the docs say boundaries aren't stored as rules, so compaction can drop them. For a hard guarantee, use a deny rule.
• Broad allow rules are dropped on entry. Bash(*), wildcarded interpreters and Agent allow rules are removed; narrow ones like Bash(npm test) stay.
• Protected paths such as .git, .claude and .bashrc go to the classifier instead of being auto-approved.
• Cost. Classifier calls count toward token usage and add a round trip before shell and network actions.
• It is not a sandbox. Anthropic recommends a sandbox or container as well.

What auto mode changes shipped in 2.1.301 to 2.1.314?

From the changelog:

Note that 2.1.312 stopped sending the claude_code.safety_event event, which 2.1.307 had added. If you build monitoring on it, check which version your team runs. The tool_decision attributes are the safer thing to depend on.

My take on /auto-mode-setup: run it once in a real project, then read what it wrote before trusting it. I haven't run it, and the changelog line says only that it reads your project and recent sessions. A tool that learns your environment from your history deserves a review of its output.

Which sandbox and write-protection settings matter?

Block file writes outside the project. 2.1.314 added permissions.blockWritesOutsideWorkingDirectories: Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode. Its sibling, permissions.blockReadsOutsideWorkingDirectories, exists too, and the settings page lists it as honoured when set to true from any scope even if a managed source says false (it requires 2.1.257 or later). The changelog does not say the write setting covers shell commands, so don't assume echo > ~/.bashrc is blocked. That is the sandbox's job.

Turn the sandbox on. The changelog notes that sandboxing is controlled by sandbox.enabled. Several recent fixes show why it's worth having on and updated: 2.1.309 fixed sandboxed Bash on macOS and Linux running the shell's startup files outside the sandbox before each command, and fixed sandboxed commands and auto-accepted edits being able to modify the MCP config file passed with --mcp-config. 2.1.314 fixed sandbox protections not applying to a worktree entered by claude -p --resume or --continue. If you're a few versions behind, those are reasons to update.

Leave nested user namespaces off. sandbox.allowNestedUserNamespaces (2.1.305) lets sandboxed commands on Linux create user namespaces, for Chromium or rootless podman. The changelog states this lets them get around the sandbox's file protections. That's the whole trade. Enable it only in a project that needs a browser or container inside the sandbox, and do it in that project's local settings, not globally. On Ubuntu, 2.1.310 improved /sandbox to name AppArmor's user-namespace restriction when it stops bubblewrap from starting.

Know what excludedCommands means. 2.1.314 corrected the description of sandbox.excludedCommands: it previously said listed commands always run outside the sandbox; it now says every command in a call must match an entry. Re-read your list with that in mind.

What changed for ultrareview, subagents and effort?

• claude ultrareview now requires workspace trust (2.1.309). It asks on a terminal and refuses otherwise. In scripts pass --trust-workspace (it takes no value, so put a PR number or base branch before it) or set CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK=1. 2.1.314 made /ultrareview check trust before running git, and with CI set an untrusted folder is refused at once. Think before setting the disable variable in CI: that check is there for untrusted repositories.
• Fork subagents are on by default in claude -p, the Agent SDK, the desktop app and VS Code (2.1.302), as they already were in the terminal. CLAUDE_CODE_FORK_SUBAGENT=0 turns them off. If you run headless jobs and want the old behaviour, that's the switch. See the subagents practical guide for what forks are good for.
• ultrathink runs the turn at xhigh effort on Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1 through Anthropic's API (2.1.311). Typed while Claude is working, it raises the rest of that turn. The changelog says nothing about cost; xhigh effort presumably uses more tokens, but I have no number, so measure it before putting ultrathink in a shared prompt.
• claude -p and SDK sessions with no permission mode now start in default on third-party providers, with telemetry off, or on a fresh install (2.1.302); --permission-mode auto keeps auto. An unattended job that used to run in auto without being told may now stop for permission.

A settings file to start from

Because auto is ignored in project settings, this belongs in ~/.claude/settings.json (the strict-JSON format the settings page describes; I checked it parses):

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "auto",
    "blockWritesOutsideWorkingDirectories": true,
    "blockReadsOutsideWorkingDirectories": true,
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  },
  "sandbox": {
    "enabled": true
  }
}

The deny entries come from the settings page's own example. A few notes on choices:

• blockReadsOutsideWorkingDirectories will make some shell commands ask for permission (2.1.310 improved auto mode's prompt to say exactly that before the first outside read). If you work across sibling repos, add them as additional directories rather than turning the block off.
• deny rules are your hard guarantee. Auto mode's classifier is judgement; a deny rule is not. Put anything you can name there.
• Settings files are strict JSON, so no comments or trailing commas, or Claude Code reports a Settings Error at next start.
• Run /status afterwards to confirm which files loaded.

Pair this with hooks for checks the settings can't express; the hooks guide covers that. Note the 2.1.314 fix: hooks matching Bash now run on shell commands started by the Monitor tool, but such hooks can block or ask, not approve or rewrite those commands. For the wider threat model of letting an agent run commands, read AI coding agent safety: sandbox and permissions.

Settings I would not touch without a reason

• CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK=1: it removes a trust prompt designed for untrusted code.
• sandbox.allowNestedUserNamespaces: weakens file protections, per the changelog.
• Broad Bash(*) allow rules: auto mode drops them on entry anyway, so they only confuse your mental model.
• bypassPermissions: the settings page says that since v2.1.257 it doesn't take effect from project or local files. Not a reason to use it elsewhere.

Sources

• Claude Code changelog, versions 2.1.300 to 2.1.314: code.claude.com/docs/en/changelog, read 2026-10-30 (the page was long and my fetch covered the start of it, so 2.1.300 notes were partial).
• Settings files and precedence: code.claude.com/docs/en/settings, read 2026-10-30.
• Auto mode: code.claude.com/docs/en/permission-modes, read 2026-10-30. The summary I received did not cover /auto-mode-setup, so that claim rests on the changelog line alone.