Claude Code 2.1.325 shipped November 13 and fixed a security issue in how it decodes zstd-compressed responses
Sandboxed Bash commands now ask for permission by default instead of running unasked inside the sandbox
Scheduled tasks and /loop now pause before running any skill that declares allowed-tools or hooks
One setting, sandbox.autoAllowBashIfSandboxed, brings back the old auto-run behavior for unattended automation
Claude Code 2.1.325 shipped on November 13, and the part that actually changes how you work isn't the security fix buried partway down the changelog. It's a default flip: Bash commands running inside Claude Code's sandbox used to execute without asking, and now they stop and ask like everything else does. If you've built any unattended automation on top of sandboxed Bash, this release either breaks your next scheduled run or adds a permission prompt nobody's there to answer.
What Changed in Claude Code 2.1.325?
The short version: one security fix, two permission defaults that flip how unattended Claude Code behaves, and a changelog that runs past 130 other entries underneath those three.
The security fix is a single line: "Fixed a security issue in how zstd-compressed responses are decoded." Anthropic doesn't say which versions were affected, how it could have been triggered, or whether it was found internally or reported in. That's typical for a security bullet in this changelog, and it means there's nothing concrete to act on beyond updating. There's no CVE number attached, no severity rating, nothing to weigh against your own risk tolerance.
You just update and move on.
The two behavior changes are more interesting because they're both about permission defaults, and both land on the side of asking more, not less. Sandboxed Bash commands now follow the normal permission flow by default. Before this release, anything running inside Claude Code's sandbox got a pass because the sandbox itself was treated as the safety boundary. Now the sandbox and the permission prompt are separate checks, and you need both to run unattended.
Separately, scheduled tasks and /loop now pause before running a skill that declares its own allowed-tools or hooks. A skill that can grant itself tool access or hook into other events is a bigger trust decision than a plain skill, and Anthropic decided that decision shouldn't happen silently inside something you're not watching.
The rest of the release is mostly fixes: 84 of its 139 changelog entries start with "Fixed." A few close actual permission gaps rather than just bugs, which I'll get to below.
There's also a smaller permission change worth flagging on its own: read-only git commands now ask first in a repository that isn't the one you started Claude Code in or one you've already trusted. If your workflow runs git log or git show against a second repo you added with --add-dir, that still works without a prompt. If you were relying on the additionalDirectories setting for the same thing, that path no longer skips the ask, so it's worth checking which one your setup actually uses before you run into a prompt mid-task.
Why Did Sandboxed Bash Permissions Flip?
The one-sentence answer is that the sandbox was never meant to be a substitute for asking you first, and this release stops treating it like one.
Before 2.1.325, running Claude Code with the sandbox turned on meant Bash commands executed inside that sandbox without a prompt. The logic made sense on paper: the sandbox already restricts what a command can touch, so asking again felt redundant. The problem is that a sandboxed command can still read files, make network calls through an allowed path, or run something destructive within its own scope, and none of that needs your explicit yes under the old default.
Two of the fixes in this same release make the case for why that mattered. One closes "a gap in Bash permission checks where some compound commands could run without asking." Another fixes a case where "a Bash allow rule could run a different program than the one it names." Put those next to the sandbox default flip and a pattern shows up: this release is about closing the distance between what you approved and what actually ran.
If you depend on sandboxed Bash running without a prompt, for a cron job, a CI step, or any process that can't sit and wait for you to click yes, the fix is one setting: sandbox.autoAllowBashIfSandboxed: true. Set it in your project settings and the old behavior comes back. If your organization turns the sandbox on through managed settings, the same key has to go in your highest-ranking managed source, not your local config, or it won't take.
I'd rather set that flag explicitly than rely on a default I didn't choose. A setting you wrote down is something you can find again in six months.
A default you never noticed is something you find out about when a job fails at 3am, and by then you're debugging the wrong layer entirely. You start by suspecting the script, then the schedule, then eventually the permission model underneath both of them, and that last step is the one that actually explains the failure.
What Does This Mean for Scheduled Tasks and Automation?
If you run anything on a schedule, this is the part of the release that actually touches your setup, not the security line.
Scheduled tasks and /loop now ask before running a skill that declares allowed-tools or hooks, unless you've already added Skill(name) to your permissions.allow list. That's a small change in wording and a real change in behavior: a scheduled job that used to run a skill end to end can now stall on a question nobody's awake to answer. I covered a close cousin of this problem when /loop's sibling, scheduled MCP tasks, got a deny setting instead of a silent hang in Claude Code 2.1.319 Adds MCP Task Backgrounding and a Deny Setting. Same failure mode, different trigger.
There's a related change worth knowing about even if it doesn't block anything outright. "Always allow" in Desktop, IDE and SDK hosts now only gets offered as an option when saving that rule would actually let the same command run again later. A scheduled task that leaned on an "always allow" click from a previous run can end up waiting on you where it didn't before, because the option to skip that wait simply isn't offered anymore in that case.
None of this is the mod permission change from Claude Code 2.1.321 Lets Mods Skip the Permission Prompt, which went the other direction and loosened a prompt. This release tightens one back.
Read both if you're running anything unattended, because the net effect of the two together isn't obvious from either changelog entry alone. A mod you wrote might now run without asking, while a skill it calls on a schedule might stop and wait. Those two defaults can sit in the same pipeline and point in opposite directions, and the only way to know which one applies where is to check both settings yourself rather than assume either release fully covers the other.
Should You Update Today?
Yes, for the security fix alone, and you don't need to understand the exploit to justify that: a decoder bug that needed a patch is reason enough on its own.
What I'd do before running the update on anything scheduled: check whether your setup turns the sandbox on, and if it does, decide now whether you want sandbox.autoAllowBashIfSandboxed: true set or whether you'd rather see the prompts. I'd rather see the prompts on anything I run by hand, and set the auto-allow flag only on the one job that truly can't wait for a yes.
For skills with allowed-tools or hooks running inside a scheduled task or /loop, add them to permissions.allow before you need them, not after a run fails. That's a five-minute check against whatever skills your automation actually touches, and it's cheaper to do once than to debug a stalled job that silently timed out waiting for an answer.
List out every skill your scheduled jobs touch, not just the obvious ones. A skill you added months ago for a one-off task can still be in a loop's rotation today, declaring hooks you forgot it had, and it's the forgotten ones that stall a run at the worst possible time.
What I'd wait on: nothing here needs a slow rollout. These are permission defaults, not a new model or a new feature with its own learning curve. The settings that restore old behavior are documented in the changelog itself, and this release doesn't make writing against Claude Code's sandbox feel any different day to day. It just makes the sandbox ask more often than it used to, which is the direction I'd want it erring on by default anyway.
One number worth keeping in view: 84 of 139 changelog entries in this release are plain bug fixes, not new features. That ratio is a reasonable proxy for how much of Anthropic's attention on Claude Code right now is maintenance rather than new surface area, and for a tool this many people run unattended, that's the right place for the attention to go.
Bottom Line
Claude Code 2.1.325 is a maintenance release with one real security fix and two permission defaults that both tighten rather than loosen. The security fix needs no decision from you beyond updating. The permission defaults do: if you run sandboxed Bash or skills with their own tool access inside a scheduled task, check your settings before your next scheduled run, not after it stalls.
Set sandbox.autoAllowBashIfSandboxed: true only where you've decided a job genuinely can't wait for an answer, not as a blanket fix to make prompts go away. Add the skills your automation depends on to permissions.allow ahead of time. Everything else in this release, the other 130-plus entries, is the kind of cleanup that doesn't change how you work so much as it removes one more way things could have quietly gone wrong.
I'd take a release like this over a flashy one most weeks. A new feature is something you choose to adopt. A closed permission gap is something that was already running against you whether you knew it or not.
Top comments (0)