Claude Code 2.1.325 adds Bash prompts, fixes security gaps

Claude Code 2.1.325, which Anthropic published on November 13, sends sandboxed Bash commands through the normal permission flow by default, according to the release notes on GitHub. Sessions that relied on the sandbox alone to run commands without prompts will start asking again unless sandbox.autoAllowBashIfSandboxed: true is set. Where managed settings turn the sandbox on, that line has to sit in the highest-ranking managed source.

The same release fixes a security issue in how zstd-compressed responses are decoded and closes several gaps in Bash permission checks. It also adds prompts that can leave scheduled and unattended runs waiting for a person.

Who gets the prompts back

The sandbox is off by default, Anthropic’s sandboxing documentation says. You turn it on with /sandbox in a session or with sandbox.enabled: true in a settings file such as ~/.claude/settings.json. If you never turned it on, none of your commands are sandboxed, so the new default doesn’t touch your sessions. The sandbox is a boundary the operating system enforces around the shell commands Claude runs: Bash, PowerShell and Monitor commands and the processes they start. Claude’s file tools, MCP servers and hooks run outside it. It works on macOS through the built-in Seatbelt framework and on Linux and WSL2 through bubblewrap and socat. On native Windows, commands run unsandboxed.

A bug report filed against version 2.1.175 noted that the published settings JSON schema lists autoAllowBashIfSandboxed with a default of true. The same reporter described server-managed settings that delivered both sandbox.enabled: true and autoAllowBashIfSandboxed: true, yet every Bash command outside a permissions.allow rule still brought up the permission dialog. For managed setups, the release notes now name the place for the key: the highest-ranking managed source.

By default the sandbox limits writes to the working directory, a per-user temp directory and added directories, the documentation says. In 2.1.325 it refuses sandboxed writes to .claude settings, skills, agents, commands and hooks in added directories, as it already did in the launch folder. A sandboxed git checkout, git stash or autostash pull that can’t update such protected files now leaves Claude a note explaining why.

Where unattended runs can now stall

Several changes add a question where none was asked before. A scheduled task that can’t get an answer will wait.

• Scheduled tasks and /loop ask before running a skill that declares allowed-tools or hooks. Adding Skill(name) to permissions.allow lets that skill run unattended.
• “Always allow” in Desktop, IDE and SDK hosts 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.
• Read-only git commands ask first in a repository that isn’t the project’s or one you trusted. To run them without prompts, name the repository with --add-dir; the additionalDirectories setting doesn’t count for this.
• -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.
• An isolated worktree session or agent is refused git bisect run, git maintenance register|start and scalar’s set-up commands, and is told what still works.

Two more changes matter for CI and service setups. claude -p with no cached account data now waits for that data before its first request, so a first run in a clean environment can start a few seconds later. And claude remote-control exits with status 4 when it stops by itself (single-session runs still exit 0) and 69 when it can’t register, so a service manager can restart it.

Plugin maintainers get one compatibility catch: a marketplace ref can now be the full ID of any commit on a branch or tag, but clients older than 2.1.325 can’t clone such a pin, and a marketplace pinned this way stops loading there. Plugin marketplace and plugin downloads also go through a CONNECT tunnel when ALL_PROXY is the only proxy set, and a proxy that refuses CONNECT now makes them fail.

Gateways and Foundry

Sessions on many third-party gateways and on Foundry were stopping with a context length error on every turn instead of compacting; 2.1.325 fixes that. CLAUDE_CODE_MAX_CONTEXT_TOKENS now also sets the context window of unrecognized model IDs that start with claude-, such as a gateway’s claude-sonnet-latest. The release also fixes a saved sonnet[1m] model setting being rewritten on a new install to a model ID the API rejects.

Permission gaps closed

Among the permission and credential fixes:

• Some compound Bash commands could run without asking; they now ask for permission.
• A Bash allow rule could, in one case, run a different program than the one it names.
• Some deny and ask rules didn’t apply to certain Bash commands, and relative rules such as Read(./.env) stopped covering the project after a cd. They now also apply in added directories.
• The Bash sandbox didn’t fully protect a worktree’s settings and hooks or a linked worktree’s shared git folder, and sandboxed commands could in some cases write to the native updater’s download folder.
• Background sessions started on a claude.ai login could use, and bill, an API key or token from the shell that started the background service.
• Token counting on Amazon Bedrock sent the conversation to Bedrock even when the allowedProviders managed setting doesn’t allow it.
• Some subagents could change an artifact that people outside your organization can see, or upload files to it, without asking.

Programs the 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. ripgrep, local git commands and the sandbox runtime’s helper programs also run without the mTLS client key’s passphrase.