Claude Code's Sandbox Asks Again: Why autoAllowBashIfSandboxed Now Defaults to No

Version 2.1.325 sends sandboxed shell commands and unattended skills back through the permission prompt. Here's what changed, why it's right, and how to keep the speed without the blind spot.

A sandbox answers one question: how much damage can this command do? It has never answered the other one, which is whether the command should run at all.

For a while, Claude Code treated the first answer as if it settled the second. Turn on the Bash sandbox and, by default, Claude could run shell commands without asking you, because the operating system was fencing them in. That felt reasonable. It was also a quiet swap of "safe enough" for "approved."

On November 13, Anthropic undid that swap. Claude Code 2.1.325 changed sandboxed Bash commands "to follow the normal permission flow by default." If you want the old behavior back, you now have to set sandbox.autoAllowBashIfSandboxed: true yourself.

This means the prompt is back for a lot of people who had stopped seeing it. The reason it came back is worth understanding before you reach for the flag.

What a sandbox does, in plain terms

Think of the sandbox as a fenced yard. The dog can run around, dig, knock things over, and the fence keeps it out of the street. The fence does not decide whether the dog should be digging up the tomatoes.

Claude Code's sandboxing docs describe the fence precisely. The Bash sandbox is "a boundary that the operating system enforces around the shell commands Claude runs on your machine." On Linux and WSL2 that means a separate network namespace; on macOS it uses Apple's Seatbelt framework. Writes are limited to your working directory, a per-user temp folder and directories you've added. Network traffic has "no direct route out" and goes through a local proxy that checks each host against an allowed list, and the allowed domains "start empty."

Now look at what sits inside the yard with the dog. Per the same page, sandboxed commands can still read "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials." Environment variables are "inherited from Claude Code, including any secrets in its environment." And "the sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it." (MCP servers are the plug-ins that connect Claude to outside tools and data; hooks are your own scripts that run when certain events happen.)

None of that is a flaw. A sandbox that blocked reading your home directory would break half the commands you run. It does mean the fence was always about blast radius, not judgment. A sandboxed rm -rf on your project folder is still inside the yard. So is a script that reads your AWS credentials and writes them into a file in the repo, waiting for the next git push.

What changed in 2.1.325

The release, tagged on GitHub at 20:40 UTC on November 13, makes four permission changes worth knowing about.

Sandboxed Bash asks again by default. Before, sandboxing came with "auto-allow" mode: commands that ran inside the sandbox were approved automatically. Now the default is what the docs call "regular permissions mode," where "all Bash commands go through the regular permission flow, even when sandboxed."

Unattended skills ask first. Scheduled tasks and /loop (Claude Code's way of re-running a prompt on an interval inside an open session) now ask before running a skill that declares allowed-tools or hooks. To let one run unattended, the changelog says to add Skill(name) to permissions.allow.

Read-only git asks in strange repos. Even git log now prompts first in a repository that isn't the project's or one you trusted. You can add the directory with --add-dir to skip the prompt.

Several Bash permission gaps are closed. The changelog lists compound commands that could run without asking and an allow rule that could run a different program than the one it named. The same release fixes a security issue in how zstd-compressed responses were decoded.

Why the skill change matters more than it looks

The Bash change gets the attention. The skill change is the sharper one.

A skill is a folder of instructions Claude can load for a task, and its frontmatter can include an allowed-tools field. The skills docs say that field lists "tools Claude can use without asking permission during the turn that invokes this skill." Write allowed-tools: Bash(git commit *) in a skill, and when the skill runs, Claude can commit without a prompt for that turn.

That's handy when you're watching. Now picture /loop firing that skill every ten minutes while you're at lunch. The scheduled tasks page lists a loop's permission prompts as inherited from the session, so whatever the session already allowed, the loop allows too. A skill that grants itself tool access, firing on a timer, with nobody at the keyboard, is the exact case where a pre-approval turns into a standing order without anyone noticing.

The skills docs flag the trust problem directly: "Workspace trust doesn't gate this field," and "a skill can grant itself broad tool access, so review the allowed-tools of skills checked into a repository before you run Claude Code there." Hooks have a similar reach. A hook declared in a skill's frontmatter stays registered "for the rest of the session."

So 2.1.325 draws a line: a skill that hands out permissions or installs hooks can't do it on a timer until you've named it. That's one line of config for the skills you trust, and a prompt for everything else. It's a fair trade.

The cost: more prompts, and the temptation to turn them off

Here's the honest part. More prompts are annoying, and annoying guardrails get disabled.

If you'd built a workflow around sandboxed auto-approval (run tests, run linters, run the build, all without a click), 2.1.325 just made your afternoon slower. The fastest fix is to set autoAllowBashIfSandboxed: true and move on. I'd push back on that, for one reason: approval fatigue. A prompt you see forty times a day trains you to hit enter without reading. At that point you have neither speed nor safety.

The better fix is narrow allow rules, so the boring commands go through and the interesting ones still stop.

Put this into practice

Start by checking what you're actually running. Update Claude Code, then confirm the version:

claude --version

You want 2.1.325 or later. Then open your settings file (user settings live in your home directory's .claude/settings.json, project settings in the repo's .claude/settings.json) and decide which mode you want.

The short version of my recommendation: keep the new default, allow the handful of commands you run all day, and make anything that leaves your machine ask.

Option 1: keep the new default and write narrow rules. This is where most people should land. The permissions docs say rules follow the format Tool or Tool(specifier) and are "evaluated in order: deny, then ask, then allow." A starting point:

{
  "permissions": {
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)",
      "Bash(git status *)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)"
    ]
  }
}

Your test and lint runs go straight through. A push always stops, even if some broader allow rule would match, because "a matching ask rule prompts even when a more specific allow rule also matches the same call."

Option 2: restore auto-allow, but keep the brakes. If your team wants most sandboxed commands approved without a click, set the flag back and add ask rules for the commands that matter. The docs list exceptions that still prompt even then, such as rm aimed at a critical path:

{
  "sandbox": {
    "autoAllowBashIfSandboxed": true
  },
  "permissions": {
    "ask": ["Bash(git push *)"],
    "deny": ["Bash(git push --force *)"]
  }
}

This works because the docs say that even in auto-allow mode, a Bash deny rule still blocks, and "content-scoped ask rules like Bash(git push *) still force a prompt even for sandboxed commands." Note the trap the docs call out: a bare Bash ask rule is skipped for sandboxed commands in auto-allow mode. Make your ask rules specific.

For unattended skills: list only the skills you've read. If you have a skill called release-notes that you want /loop to run without stopping, the changelog's instruction is to add Skill(release-notes) to permissions.allow. Leave everything else asking.

For the escape hatch: when a sandboxed command fails, Claude can retry it outside the sandbox with a dangerouslyDisableSandbox parameter. If you want to see those retries every time, the docs suggest an ask rule for Bash(dangerouslyDisableSandbox:true), which "takes precedence over a matching allow rule." Watch your allow list here too: the docs say a matching allow rule, such as Bash(curl *), also approves the unsandboxed retry with no prompt. Or turn retries off entirely with "allowUnsandboxedCommands": false in your sandbox settings.

What to expect after the upgrade: more prompts for a day or two, then fewer as your allow list fills in. If you see a prompt you approve every single time, that command belongs in allow. If you see one you'd never approve, it belongs in deny.

The limitations

This change doesn't make Claude Code safe by itself, and it's worth being specific about the gaps.

The sandbox is off by default, per the docs, and on native Windows "Claude Code runs commands unsandboxed." If you never turned it on, the auto-allow question never applied to you.

The sandbox doesn't cover file tools, MCP servers or hooks, which run "with your full access." A prompt on Bash does nothing for a malicious MCP server you installed last week.

If the sandbox can't start, Claude Code runs commands without it unless you set sandbox.failIfUnavailable to true. Silent fallback is worth turning off on any machine that matters.

And prompts only help if someone reads them. In a CI job or a scheduled run with nobody watching, a prompt is just a stall. Those runs need explicit allow rules or they'll hang.

What this release is really saying

The interesting thing about 2.1.325 isn't any single setting. It's the direction. A containment layer used to double as an approval layer, and Anthropic just split them back apart. The same week, Cloudflare shipped hard spending caps, in beta for Workers and Durable Objects, that stop new invocations when a bill crosses a line, which is the same idea applied to money: the brake lives outside the thing doing the work.

You can disagree with the default. Plenty of solo developers will flip the flag back, and for a throwaway side project in a container, that's a defensible call. Just make it a decision rather than a reflex. Read your settings file this week, write the five allow rules that cover your boring commands, and let the prompt do its one job on the commands that aren't boring.

Sources: Claude Code v2.1.325 release notes (reviewed November 14, 2026), Claude Code CHANGELOG, Sandboxing docs, Permissions docs, Skills docs, Scheduled tasks docs, Cloudflare Spend Management.