Cursor 3.24 pede confirmacao antes de exclusoes perigosas, mas o Run Everything permanece em silencio

O erro mais desagradavel de um agente nao e gerar codigo defeituoso, mas executar um comando que apaga silenciosamente a coisa errada. Basta um rm -rf mal calculado ou um curinga que se expanda mais do que o esperado para metade do projeto desaparecer. Nas versoes mais recentes, o Cursor reduziu parte desse risco, mas apenas se o proprio usuario nao desativar a protecao.

O que mudou na versao 3.24

Segundo as notas de lancamento do Cursor, a partir da versao 3.24 o modo Auto-review pede permissao antes de exclusoes arriscadas. Quatro casos entram nessa categoria: exclusao recursiva, exclusao forcada, exclusao com curingas e situacoes em que o destino real pode ser diferente daquele especificado no comando.

O ultimo caso e o mais traiçoeiro. Suponha que o agente pretenda limpar a pasta de build, mas o caminho seja montado a partir de uma variavel vazia ou que aponte para um nivel acima. O comando parece inofensivo, mas pode excluir algo completamente diferente. Agora, nesse momento, o Cursor interrompe a operacao e aguarda a confirmacao do usuario.

Onde nao ha protecao

O modo Run Everything funciona de outra forma. Segundo a documentacao do Cursor, nele o agente executa todos os comandos em sequencia, sem sandbox nem classificador de riscos. As restricoes so existem quando o proprio usuario as define no permissions.json.

Na pratica, trata-se de um unico interruptor. Enquanto ele estiver ativado, a pergunta “tem certeza?” nao aparecera em nenhuma circunstancia, nem mesmo para um comando que elimina um diretorio. Isso pode ser conveniente para experimentos rapidos em um repositorio descartavel. Em um projeto de trabalho sem backup, e uma aposta de que o agente nao cometera nenhum erro.

Se a velocidade ainda for necessaria, e mais sensato definir limites no permissions.json—especificando o que o agente pode ou nao executar—do que desativar totalmente a protecao. Assim, o modo sem perguntas pelo menos nao se estende a operacoes perigosas.

Um habito simples: fazer commit antes de alterar

O autor da publicacao recomenda duas coisas. A primeira e manter o Auto-review como modo padrao. A segunda e fazer um commit antes de pedir ao agente uma alteracao de grande porte.

A segunda recomendacao e importante por causa do funcionamento dos checkpoints do Cursor. Eles sao armazenados localmente e separadamente do git. Sua funcao e reverter as alteracoes do agente, nao manter o historico do projeto. Apenas o git preserva um historico permanente. Portanto, um checkpoint nao pode ser considerado substituto de um commit: se o proprio diretorio ou o ambiente de trabalho for danificado, o unico ponto de restauracao confiavel estara no repositorio.

Na pratica, o procedimento e o seguinte:

• antes de atribuir uma tarefa grande ao agente, registre o estado atual em um commit;
• mantenha o Auto-review ativado, especialmente em projetos com dados importantes;
• se usar o Run Everything, restrinja as permissoes no permissions.json;
• encare a reversao por checkpoint como uma conveniencia, nao como um seguro.

Limitacoes e contexto

E importante deixar claro: isto nao e um estudo nem um benchmark, mas uma nota breve baseada nas notas de lancamento e na documentacao. A publicacao nao informa exatamente como o Cursor define uma exclusao “arriscada” nem com que confiabilidade detecta todas as variacoes. Portanto, tambem nao se deve confiar totalmente no Auto-review: ele reduz o risco, mas nao elimina a necessidade de disciplina com commits.

A publicacao e parcialmente promocional: ela da continuidade a serie animada “Vibe Coder and Bug”, cujo quinto episodio aborda este tema, e convida os leitores para o clube NeyroMakers. O autor tambem detalha o custo do episodio: cerca de $5 aos precos da API, o equivalente a 0,5% do limite semanal da assinatura, alem de aproximadamente 9 centavos pela narracao no ElevenLabs. Claude escreveu o roteiro e a animacao no Claude Code.

Conclusao

Se voce trabalha com agentes no Cursor, reserve um minuto para verificar em qual modo eles estao sendo executados. Se estiverem no Run Everything e nao houver restricoes no permissions.json, na pratica voce autorizou o agente a fazer qualquer coisa. Volte para o Auto-review e crie o habito de fazer um commit antes de tarefas grandes. Custa muito pouco e protege contra a categoria mais desagradavel de erros.