Claude Code 2.1.325: sandboxed Bash now asks permission

Claude Code 2.1.325 (opens in a new tab), published on 13 November 2026, fixes a security issue in how zstd-compressed responses are decoded, so upgrade to it. Before you do, change your settings: the release makes three things ask for permission that used to run on their own. Sandboxed Bash commands now follow the normal permission flow; set sandbox.autoAllowBashIfSandboxed: true to keep them running without prompts, and under managed settings set it in your highest-ranking managed source. Scheduled tasks and /loop now ask before running a skill that declares allowed-tools or hooks; add Skill(name) to permissions.allow for each one. Read-only git commands now ask first in a repository that isn't the project's or one you trusted; name it with --add-dir. In a claude -p run with nobody to answer, an unanswered prompt means a denied command: the run continues without it, so a CI job doesn't stop at the step that no longer happens. As of 15 November, 2.1.325 is npm's latest and next, while stable is still 2.1.311, which has none of this. We checked every claim against the release notes, the changelog, the npm registry and the Claude Code docs on 15 November 2026; we did not run the new version.

What changed in Claude Code 2.1.325

The 2.1.325 release notes list 139 items: 88 fixes, 30 changes, 14 improvements, six additions and one removal. The first is the security fix: "Fixed a security issue in how zstd-compressed responses are decoded". The ones that change what runs without asking are among the 30 changes:

The registry pins the dates down. The npm registry (opens in a new tab) records 2.1.323 at 20:29 UTC on 12 November, 2.1.324 at 18:42 UTC on 13 November and 2.1.325 at 20:07 UTC the same day, 85 minutes later; GitHub published the release at 20:40 UTC. 2.1.324 has no GitHub release and no entry in the changelog (opens in a new tab), which goes from 2.1.323 straight to 2.1.325. Yet the settings reference (opens in a new tab) says of autoAllowBashIfSandboxed: "Default: false. Before v2.1.324, the default was true". So treat any machine on 2.1.324 as already changed, and 2.1.323 as the last version with the old defaults. It is the second permission default in a month to move under headless runs: Claude Code 2.1.299 to 2.1.302 in our October digest covers the release that changed which permission mode some claude -p runs start in, and why we pin the version in CI.

The rest of the security-relevant work sits in the fixes. Several close gaps in Bash permission checks: some compound commands ran without asking, a Bash allow rule could run a different program than the one it names, and some deny and ask rules didn't apply to certain Bash commands or, written as relative paths such as Read(./.env), stopped covering the project after a cd. Three tighten the sandbox: it now stops sandboxed commands writing to the native updater's download folder in some cases, fully protects a worktree's settings and hooks, and fully protects a linked worktree's shared git folder. The sandbox also now refuses writes to .claude settings, skills, agents, commands and hooks in added directories, as it already did in the launch folder, and starts its own helper programs, such as its network bridge, without Claude Code's sign-in tokens and API keys in their environment.

What autoAllowBashIfSandboxed does

sandbox.autoAllowBashIfSandboxed decides whether a command that runs inside the sandbox needs approval. The sandboxing docs (opens in a new tab) call true auto-allow mode: "Claude Code approves a command automatically, with no prompt, when the command runs inside the sandbox." With false, the regular permissions mode, "All Bash commands go through the regular permission flow, even when sandboxed." The settings reference adds the limits of auto-allow: deny rules and content-scoped ask rules such as Bash(git push *) still apply, a bare Bash ask rule is skipped for sandboxed commands, and a command that can't run in the sandbox goes through the normal flow either way. The key changes the approval step in front of the sandbox, not what the sandbox lets a command read, write or reach.

Who is affected and how to tell

You are affected if a machine or runner moves to 2.1.324 or later and one of these is true:

• You turned the sandbox on and rely on it to skip prompts. Interactive sessions start asking for each sandboxed command that no allow rule covers. If your team chose the sandbox so developers could work without approving every npm test, that is the change they will notice first.
• Your organisation enables the sandbox through managed settings. Every developer under that policy gets prompts until the policy itself sets autoAllowBashIfSandboxed.
• You run Claude Code unattended: claude -p in CI, a cron job, an Agent SDK app, a scheduled task or a /loop. Per the headless docs (opens in a new tab), a claude -p run in Manual mode denies a call that needs approval unless a PermissionRequest hook or a --permission-prompt-tool approves it, and since 2.1.302 a -p run starts in Manual mode when nothing sets a mode. So in plain CI the job doesn't hang: the command is denied, and the work it was meant to do doesn't happen. An Agent SDK app with a canUseTool callback, or a run with a permission prompt tool, is different: per the docs on permission prompts in unattended runs (opens in a new tab), the run waits for that host to answer.
• Your scheduled tasks or loops call skills that declare allowed-tools or hooks. A skill's allowed-tools grants those tools without approval for the turn that invokes it, the skills docs (opens in a new tab) say, which is exactly why a scheduled fire now asks before running one.

Three commands tell you where you stand on a given machine. claude --version prints the version. claude doctor shows the install and the last auto-update attempt. /status inside a session shows the Setting sources line, which names the managed source in force, such as Enterprise managed settings (file).

The release channel decides when the change reaches you. Native installs follow latest by default; with autoUpdatesChannel: "stable" they follow a version that the setup docs (opens in a new tab) say is "typically about one week old, skipping releases with major regressions". On 15 November 2026 the registry's stable tag points at 2.1.311, published on 26 October. Homebrew's claude-code cask tracks stable and claude-code@latest tracks latest; Homebrew, WinGet, apt, dnf and apk installs don't update themselves by default.

How to upgrade Claude Code to 2.1.325 without new prompts

1. Find every install and its channel

   On each laptop, runner image and server, run claude --version and claude doctor. Note which follow latest (they may already be on 2.1.325) and which follow stable or a pinned version (2.1.311 or older on 15 November). CI images that install @anthropic-ai/claude-code@latest pick up the change on their next build.

2. Decide on sandbox auto-allow and set it where it wins

   If you want sandboxed commands to keep running without prompts, set sandbox.autoAllowBashIfSandboxed to true next to sandbox.enabled. For a team, put it in the committed .claude/settings.json; for one person, in ~/.claude/settings.json. Under managed settings, add it to the sandbox block of the source that /status names, which is the highest-ranked one.

3. Allow the skills your scheduled tasks and loops run

   For every skill a scheduled task or /loop invokes that declares allowed-tools or hooks in its frontmatter, add Skill(name) to permissions.allow, or Skill(name *) when it takes arguments. Allow only the skills you mean to run unattended.

4. Name extra repositories and check runner paths

   If Claude runs read-only git commands in a second repository, start the session with --add-dir <path>; the additionalDirectories setting no longer stops the prompt. On self-hosted runners, make sure the session folder and repository path are not symbolic links.

5. Make unattended runs fail loudly

   Add --permission-prompts none to scheduled claude -p jobs, or set permissions.denyInsteadOfPrompting: true in user or managed settings, so a run never waits on a prompt nobody will answer. With --output-format stream-json, read the permission_denials list in the final result and fail the job when it isn't empty.

6. Upgrade, then run each job once while watching

   Run claude update, or npm install -g @anthropic-ai/claude-code@2.1.325 for npm installs. Then run one CI job, one scheduled task and one interactive session with the sandbox on, and confirm none of them prompts or reports a denial you didn't expect.

The settings for a team that wants the old behaviour, in .claude/settings.json (replace nightly-report with your skill's name):

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true
  },
  "permissions": {
    "allow": ["Skill(nightly-report)"]
  }
}

Managed settings: which source is highest-ranking

"Highest-ranking managed source" has a precise meaning. The managed settings docs (opens in a new tab) rank the sources in this order: remote settings from claude.ai or a Claude apps gateway, then MDM or OS policies (the macOS plist or the HKLM registry key), then the managed settings files (managed-settings.json with managed-settings.d/*.json), then the Windows HKCU registry. By default (managedSourcesBehavior: "first-wins"), Claude Code uses the highest-ranked source that delivers at least one policy key and ignores the rest, without a warning. autoAllowBashIfSandboxed is not one of the few keys read from every source, so a value in a lower source does nothing.

In practice: if your organisation uses server-managed settings from the claude.ai console and also ships a managed-settings.json, the key belongs in the console's policy. If the file is your only source, it goes in the file, at /Library/Application Support/ClaudeCode/managed-settings.json on macOS, /etc/claude-code/managed-settings.json on Linux and WSL, or C:\Program Files\ClaudeCode\managed-settings.json on Windows:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "autoAllowBashIfSandboxed": true
  }
}

Then check one machine: /status should name the source you edited, and a Skipped sources line names any source a higher one overrode. Setting the key in managed settings has a second effect: the sandboxing docs note that under an admin-required sandbox a repository's files can still set autoAllowBashIfSandboxed, and setting it in managed settings keeps a repository from changing it.

What to watch out for

• Auto-allow is a choice, not a restore button. Anthropic made prompting the default. If you turn auto-allow back on, also set allowUnsandboxedCommands: false (strict sandbox mode in /sandbox), which per the sandboxing docs (opens in a new tab) makes Claude Code ignore the dangerouslyDisableSandbox retry, so a command that fails in the sandbox can't simply run outside it.
• No advisory for the zstd fix. As of 15 November 2026, the release notes link no advisory and give no CVE, affected versions or severity, so we give none either. Watch the repository's security advisories (opens in a new tab) in case one is published later.
• Stable stays behind. A team on stable has the old defaults and lacks the 2.1.325 fixes until the channel moves to 2.1.325 or later. Moving to 2.1.325 early means taking the new defaults at the same time, so do the steps above first. With autoUpdatesChannel: "stable", a native install moves back to the stable version even when yours is newer, unless you set minimumVersion.
• Native Windows has no sandbox. Per the sandboxing docs (opens in a new tab), the sandbox runs on macOS, Linux and WSL2; on native Windows Claude Code runs commands unsandboxed, and they take the normal permission flow anyway.
• Smaller changes for unattended runs. Also in the 2.1.325 release notes linked above: "Always allow" in Desktop, IDE and SDK hosts now offers a rule alone only when saving it would allow that command again, so a scheduled task that relied on one can now wait for you. claude -p with no cached account data now waits for it before the first request, so a first run in a clean CI container can start a few seconds later. -p and SDK runs in a worktree or submodule mounted into a container apply .claude/settings.local.json allow rules only once the folder is trusted. Claude Code on the web, cloud scheduled tasks and Cowork cloud sessions now start despite sandbox.failIfUnavailable, because the hosted container has no command sandbox.

We read every source on 15 November 2026. Claude Code ships most days, so check the changelog for anything newer before you roll out.

Further reading