Claude Code 2.1.325: five changes that can make unattended runs wait for permission

If you run Claude Code without anyone watching, in CI, on a schedule, or with /loop, one release is worth reading closely. Version 2.1.325 is the newest entry in Claude Code's changelog, read on 15 November 2026 (the changelog itself carries no dates). Several of its changes move the defaults toward asking for permission. For a person at the keyboard, that means an extra prompt. For a job nobody is watching, it can mean a job that neither finishes nor fails, because it's waiting for an answer.

The changelog says so itself, about one of them: "a scheduled task that relied on one can now wait for you". That's the failure to look for: nothing errors and nothing finishes, and there may be nothing in a log to tell you why.

What changed

Each of these is quoted whole from the changelog, because the scope of each is in the sentence.

1. Sandboxed Bash commands follow the normal permission flow by default

"Changed sandboxed Bash commands to follow the normal permission flow by default; set sandbox.autoAllowBashIfSandboxed: true to keep running them without prompts"

This is about commands run in Claude Code's sandbox, and the changelog names the setting that keeps them running without prompts. It doesn't mean every command now asks. For organisations that turn the sandbox on through managed settings, the changelog adds: "Changed managed settings that turn the sandbox on: to keep commands running without prompts, set sandbox.autoAllowBashIfSandboxed: true in your highest-ranking managed source". Note "highest-ranking managed source", not just any settings file.

2. Scheduled tasks and /loop ask before some skills

"Changed scheduled tasks and /loop to ask before running a skill that declares allowed-tools or hooks; add Skill(name) to permissions.allow to run it unattended"

Only skills that declare allowed-tools or hooks are affected. Other skills aren't.

3. Read-only git commands in other repositories ask first

"Changed read-only git commands to ask first in a repository that isn't the project's or one you trusted; name it with --add-dir, not the additionalDirectories setting, to run them without prompts"

This applies to a repository that isn't the project's own or one you've trusted. If your job reads another repository, the changelog names --add-dir as the way to keep it unattended.

4. "Always allow" in Desktop, IDE and SDK hosts

"Changed "Always allow" in Desktop, IDE and SDK hosts: a rule alone is offered only when saving it would allow that command again, so a scheduled task that relied on one can now wait for you"

5. Headless runs in mounted worktrees

"Changed -p and SDK runs in a worktree or submodule mounted into a container to apply .claude/settings.local.json allow rules only once the folder is trusted"

If you run Claude Code with -p or through the SDK in a container, and rely on local allow rules in a mounted worktree or submodule, those rules now wait for the folder to be trusted.

Also in this release

These five are the "Changed" items. The release also has fixes that move the same way, and one matters for unattended jobs: "Fixed a gap in Bash permission checks where some compound commands could run without asking; these now ask for permission". If a job chains commands together, it may now stop to ask where it didn't before. The full 2.1.325 entry has many more permission-related items than the ones listed here, so it's worth reading in full if you depend on unattended runs.

The changelog doesn't give a reason for these changes, and we won't guess at one. The same release also includes an unrelated security fix, "Fixed a security issue in how zstd-compressed responses are decoded", which is a separate item. The changelog doesn't link it to the permission changes above.

How to check your own setup

• List what runs unattended. CI jobs, scheduled tasks, /loop sessions, scripts that call claude -p or the SDK.
• Match each one against the five changes. Does it run Bash in the sandbox? Run a skill that declares allowed-tools or hooks? Read another repository with git? Rely on a saved "Always allow" in a Desktop, IDE or SDK host? Rely on local allow rules in a mounted worktree?
• Where the changelog names a setting, use it. It does for the first three changes above. For the other two, check how your host or container handles approvals and trust. Either way, read Claude Code's settings documentation before you change anything.
• Watch for jobs that run long, not just jobs that fail. A job waiting for permission doesn't error. Add a timeout or an alert for runs that take far longer than usual.
• Test after updating. After moving to 2.1.325, run each unattended job once the way it normally runs, while someone watches, and confirm it finishes without stopping to ask.

Source: Anthropic, Claude Code changelog, version 2.1.325 section, read 15 November 2026. The changelog does not carry release dates.