Claude Code 2.1.325 now asks before running sandboxed Bash commands

58 minutes ago

6 min read

Anthropic has changed one of the most consequential defaults in Claude Code. Starting with version 2.1.325, published to npm on November 13, 2026 at 20:07 UTC, Bash commands that run inside Claude Code's sandbox no longer execute automatically. They now go through the same permission flow as any other command, which means the agent stops and asks before running them unless an allow rule or a permission mode already covers the call. Developers who want the previous behavior have to opt back in with a single setting, `sandbox.autoAllowBashIfSandboxed: true`.

The change is listed in the official Claude Code changelog for 2.1.325 alongside several related tightenings: read-only git commands now ask first in repositories that are neither the project's nor trusted, scheduled tasks and `/loop` now ask before running skills that declare their own tools or hooks, and the sandbox refuses writes to `.claude` configuration in added directories. The same release fixes a security issue in how zstd-compressed responses are decoded and closes a gap in Bash permission checks where some compound commands could run without asking.

The release is the current `latest` version of the `@anthropic-ai/claude-code` npm package, while the package's `stable` tag still points to version 2.1.311, published on October 27. Users who follow the stable track will therefore meet the new prompts later, when that tag moves forward.

··········

CLAUDE CODE SANDBOX DEFAULTS BEFORE AND AFTER VERSION 2.1.325.

Until this release, turning on the Bash sandbox also meant that a command confined by the sandbox could run without a prompt, with the restrictions on file writes and network access acting as the safety boundary. Version 2.1.325 separates those two ideas. The sandbox still restricts what a command can touch, but whether the command runs at all is now decided by the normal permission rules, as it is for commands outside the sandbox.

Anthropic applies the same logic to organizations. When a company turns the sandbox on through managed settings, its developers will now see prompts for sandboxed commands unless the administrator also sets `sandbox.autoAllowBashIfSandboxed: true` in the highest-ranking managed source. Setting the flag in a lower-ranking file does not restore silent execution for those users.

........

Behavior	Before 2.1.325	From 2.1.325
Sandboxed Bash commands	Ran without a prompt	Follow the normal permission flow
Sandbox enabled by managed settings	Commands ran without prompts	Prompts unless the flag is set in the highest-ranking managed source
Read-only git in untrusted repositories	Ran without asking	Ask first unless the repository is added with `--add-dir`
Skills with `allowed-tools` or hooks in scheduled tasks and `/loop`	Ran unattended	Ask first unless `Skill(name)` is in `permissions.allow`
Sandboxed writes to `.claude` files in added directories	Not refused	Refused, as in the launch folder

........

The table reflects the changelog wording. Anthropic describes each item as a change in behavior and gives the opt-out for each one, so the old default is inferred from the new one rather than documented separately in the release.

··········

WHAT CHANGES FOR CLAUDE CODE USERS AND ADMINISTRATORS.

For an individual developer working interactively, the visible effect is more approval dialogs during sessions that lean on shell commands: test runs, builds, package installs and file inspection. Developers who already maintain allow rules for their common commands will notice little, because those rules continue to authorize the calls before any prompt appears. Developers who relied on the sandbox alone to keep sessions flowing will see the agent pause far more often until they either write rules or restore the old default.

Unattended workflows are the most exposed. A scheduled task, a `/loop` run or a headless job that hits a permission prompt has nobody to answer it, so it waits or stops. The changelog also notes a related change to "Always allow" in Desktop, IDE and SDK hosts: a rule alone is now offered only when saving it would actually allow that command again, so a scheduled task that relied on such a rule can now wait for the user. Teams that run Claude Code on a schedule should test those jobs on 2.1.325 before the stable channel catches up.

Read-only git commands follow the same direction. In a repository that is neither the project's nor one the user has trusted, read-only git commands now ask first. The changelog is specific about the fix: name the repository with the `--add-dir` flag, because listing it in the `additionalDirectories` setting does not exempt it from the prompt.

........

Situation	Setting or action named in the changelog
Keep sandboxed Bash running without prompts	`sandbox.autoAllowBashIfSandboxed: true`
Organization-wide sandbox via managed settings	Same flag, in the highest-ranking managed source
Read-only git in another repository	Add the repository with `--add-dir`
Scheduled task or `/loop` running a skill with tools or hooks	Add `Skill(name)` to `permissions.allow`

........

Administrators should treat the flag as a policy decision. Restoring automatic execution brings back the convenience of the previous release, but it also restores the assumption that sandbox confinement alone is enough to let a command run. Organizations that prefer explicit approval can leave the new default in place and publish allow rules for the commands their teams actually use. Our guide to Claude Code permissions, sandboxing and hooks explains how allow rules, permission modes and the sandbox fit together.

··········

CLAUDE CODE 2.1.325 SECURITY FIXES AND SANDBOX HARDENING.

The permission change arrives with a set of fixes that point in the same direction. The first entry in the changelog is a fix for a security issue in how zstd-compressed responses are decoded. Anthropic gives no further technical detail, no severity rating and no identifier for it, so the practical advice is simply to update.

Several fixes close paths through which commands could run or write without the expected checks. Anthropic says it fixed a gap in Bash permission checks where some compound commands could run without asking, cases where the Bash sandbox did not fully protect a worktree's settings and hooks or a linked worktree's shared git folder, and a case where sandboxed commands could write to the native updater's download folder. Relative deny and ask rules, such as a rule written for `Read(./.env)`, previously stopped covering the project after a change of directory; they now hold after a `cd` and also apply in added directories. Deny rules are now applied to permission approvals that arrive after a restart in self-hosted runner and `claude remote-control` sessions.

The release also reduces what helper processes can see. The programs that Claude Code's sandbox starts for its own use, such as its network bridge, now run without Claude Code's sign-in tokens and API keys in their environment, and ripgrep, local git commands and the sandbox runtime's helpers run without the mTLS client key's passphrase. Another fix stops background sessions started on a claude.ai login from using, and billing, an API key or token taken from the shell that launched the background service.

Plugins receive stronger warnings. The add-marketplace confirmations, plugin recommendation prompts and install warnings now state that plugins can run code on the user's computer with access to files and the shell, and plugin loading skips some unsafe paths and links inside a plugin's folder. The warning lands about two weeks after a malicious extension posing as Claude Code reached users of another editor's marketplace, a case we covered in our report on the fake Claude Code extension 2.1.313.

··········

CLAUDE CODE 2.1.323 AND CODE MODE FIXES IN THE SAME CYCLE.

Version 2.1.325 follows 2.1.323, published on November 12, which added Code Mode, an experimental opt-in in which Claude writes JavaScript to call its tools instead of invoking them one at a time. Code Mode is off by default, and the changelog points to its documentation both for turning it on and for turning it off across an organization. The 2.1.325 notes already contain three Code Mode fixes: scripts now respect a worktree entered with `EnterWorktree` and no longer write `~` paths into the project, words typed with a Yes at a permission dialog now reach Claude in Code Mode, and a resumed session that ended during a Code Mode script now waits for the next prompt instead of starting work by itself.

Version 2.1.323 also changed the context window that Claude Code assumes for a model ID it does not recognize from 200K to 1M tokens. Anthropic warns that sessions on other vendors' models with a smaller window can fail every turn once full, until `/clear`, and recommends setting `CLAUDE_CODE_DISABLE_1M_CONTEXT=1` before they fill. In 2.1.325, `CLAUDE_CODE_MAX_CONTEXT_TOKENS` also sets the window for unrecognized IDs that start with `claude-`, such as a gateway alias. The same 2.1.323 release made `/security-review` ask before running and made `--permission-mode auto` fall back to Manual mode, which asks first, when auto mode is unavailable.

··········

CLAUDE CODE PERMISSION CHANGES: CONFIRMED FACTS AND OPEN QUESTIONS.

The changelog establishes the new default, the exact setting that restores the old one, the rule for managed settings and the specific opt-outs for git, scheduled skills and added directories. The npm registry confirms that 2.1.325 is the current latest release and that the stable tag remains on 2.1.311, so the change has reached developers on the fast track first.

Anthropic has not published a separate explanation of why sandbox confinement no longer implies automatic approval, and it has not described the zstd decoding issue beyond one line. It has also not said when the stable tag will advance. For teams with scheduled or headless Claude Code jobs, the concrete conclusion is to decide now between the explicit flag and a set of allow rules, because on 2.1.325 a sandboxed command without either one waits for a human.

··········

·····

DATA STUDIOS

·····

datastudios.org