Claude Code 2.1.325 passa a pedir permissão para rodar Bash dentro do sandbox

O que mudou na versão 2.1.325

Claude Code 2.1.325 foi lançado em 13 de novembro de 2026, um dia antes deste texto. O changelog traz 139 entradas, das quais 84 começam com "Fixed": é um release de manutenção, não de recurso novo. A mudança que importa pra quem roda o agente sem ninguém olhando é um flip de padrão: comandos Bash executados dentro do sandbox do Claude Code paravam de pedir permissão antes, e agora pedem, como qualquer outro comando.

Antes desta versão, ativar o sandbox bastava pro agente rodar Bash sem perguntar nada: a lógica era que o próprio sandbox já restringia o que o comando podia tocar, então o prompt de permissão parecia redundante. A partir de 2.1.325, sandbox e permissão viraram duas checagens separadas, e você precisa das duas pra rodar sem supervisão. Quem depende disso, um cron job, um step de CI, qualquer processo que não vai estar ali pra clicar "sim", tem um switch pra voltar ao comportamento antigo: sandbox.autoAllowBashIfSandboxed: true, no settings.json do projeto.

Duas outras mudanças de permissão vieram junto. Tarefas agendadas e o comando /loop agora pausam antes de rodar qualquer skill que declare allowed-tools ou hooks próprios, a menos que você já tenha colocado Skill(name) na lista permissions.allow. E comandos git somente leitura, como git log e git show, passam a pedir permissão quando rodam fora do repositório onde você iniciou o Claude Code ou de um repositório já confiado, mesmo configurando additionalDirectories (quem usa a flag --add-dir continua isento).

A correção de segurança do release é enxuta: ela resolve um problema na forma como respostas comprimidas em zstd eram decodificadas. A Anthropic não informa quais versões foram afetadas, como o bug podia ser disparado, nem publica CVE ou nota de severidade. Isso não muda a recomendação: atualize mesmo sem saber o alcance exato do problema.

Por que isso importa pra quem roda agente com credencial da AWS

O ponto central do ângulo de segurança não está explícito no changelog, está no que o sandbox nunca garantiu sozinho. Um comando sandboxado ainda consegue ler arquivo dentro do escopo liberado, fazer chamada de rede por um caminho permitido e rodar algo destrutivo dentro do próprio limite, tudo isso sem precisar do seu "sim" explícito no modelo antigo.

Isso é relevante demais pra quem builda com Claude Code apontado pra uma conta AWS. Se o seu sandbox roda numa instância EC2, num container do CodeBuild ou em qualquer ambiente com uma IAM role anexada, um comando Bash com acesso de rede dentro desse sandbox consegue, em tese, bater no endpoint de metadata (169.254.169.254/latest/meta-data/iam/security-credentials/) e capturar a credencial temporária da role sem nunca gravar nada em disco. Essa é a minha leitura do risco, não está escrita no changelog da Anthropic, mas é exatamente o tipo de caminho que um "sandbox como fronteira de confiança" deixa aberto quando o comando roda sem pedir confirmação.

Dois fixes do mesmo release reforçam por que isso importava. Um fecha uma brecha nas checagens de permissão do Bash que deixava alguns comandos compostos rodarem sem perguntar. Outro corrige um caso em que uma regra de allow do Bash podia acabar executando um programa diferente do que ela nomeava.

Junte isso ao flip do sandbox e dá pra ver o padrão: o release inteiro é sobre fechar a distância entre o que você aprovou e o que realmente rodou. Se você escreveu uma regra de allow pensando que ela liberava só aws s3 ls numa conta de produção, esse segundo fix é exatamente o tipo de bug que você quer fechado antes, não depois.

O que quebra no seu pipeline de automação

Se você tem Claude Code rodando sem gente olhando, seja num EventBridge Scheduler disparando um job, num passo de CodeBuild ou num runner de CI, esse é o ponto que realmente te afeta, mais do que a linha de segurança.

• Tarefa agendada ou /loop que antes rodava uma skill do início ao fim agora pode travar numa pergunta que ninguém vai responder, se a skill declarar allowed-tools ou hooks e não estiver em permissions.allow.
• A opção "Always allow" em Desktop, IDE e SDK só aparece quando salvar aquela regra realmente vai liberar o mesmo comando de novo depois; um job que contava com um clique antigo de "always allow" pode voltar a esperar resposta onde antes não esperava.
• Comando git somente leitura contra um segundo repositório pode passar a pedir permissão, dependendo de ele ter sido adicionado via --add-dir ou via additionalDirectories.

Nenhuma dessas mudanças é igual ao ajuste de permissão para mods da versão 2.1.321, que foi na direção oposta e afrouxou um prompt. Este release aperta de volta, e os dois efeitos podem conviver no mesmo pipeline: um mod seu pode passar a rodar sem perguntar, enquanto uma skill que ele chama numa tarefa agendada passa a esperar você. A única forma de saber qual regra vale onde é checar as duas configurações, não presumir que uma cobre a outra.

Como ajustar sem reabrir a porta

Antes de atualizar qualquer coisa que roda sem supervisão, confira se o seu setup liga o sandbox e decida, job por job, se quer sandbox.autoAllowBashIfSandboxed: true ou se prefere ver o prompt. Em ambiente gerenciado por organização, essa chave precisa ir na fonte de managed settings de maior prioridade, não no config local, senão não pega.

1. Liste as skills que suas tarefas agendadas realmente tocam, inclusive as que você esqueceu que ainda estão no giro.
2. Adicione em permissions.allow as que declaram allowed-tools ou hooks antes do próximo run, não depois que um job travar.
3. Ligue sandbox.autoAllowBashIfSandboxed só no job que de fato não pode esperar por um "sim", não como solução padrão pra calar os prompts.
4. Revise as regras de allow do Bash que tocam aws ou qualquer CLI com acesso à sua conta: confirme que elas nomeiam exatamente o binário que você quer liberado.

Nada aqui pede rollout lento: são defaults de permissão, não um modelo novo com curva de aprendizado. A correção de segurança não tem CVE nem nota de severidade pública, então não dá pra pesar o risco específico, só atualizar.

Fonte: DEV Community — #claudecode