O YOLO mode do Cursor em 2026: Auto-review, Allowlist e Run Everything explicados

O Cursor acabou com o YOLO mode?

Não. O YOLO mode do Cursor, introduzido na versão 0.44 em dezembro de 2024, passou a chamar-se Auto-run em março de 2025 e sobrevive como o modo Run Everything, em Settings > Agents > Approvals & Execution. A predefinição desde o Cursor 3.6 (maio de 2026) é o Auto-review, e é por isso que a antiga caixa de verificação YOLO desapareceu. O percurso completo, segundo o registo de alterações do Cursor:

Fontes: o registo de alterações do Cursor e a documentação dos modos de execução, consultados a 18 de outubro de 2026.

Se seguiste um tutorial de 2025 e não encontras o interruptor "YOLO" ou "Auto-run", a razão é esta. Os modos vivem agora em Settings > Agents > Approvals & Execution.

O que permitem os modos de auto-run do Cursor?

O Cursor tem hoje três modos de execução, herdeiros da antiga definição Auto-run. O Auto-review corre as chamadas da allowlist e os comandos de shell que cabem na sandbox, e um modelo classificador julga o resto. O Allowlist corre apenas o que está na tua lista e pede aprovação para tudo o resto. O Run Everything corre todas as chamadas de ferramentas sem sandbox, sem classificador e sem aprovação. Os três aplicam-se aos comandos de shell, às chamadas de ferramentas MCP e aos pedidos web.

A tabela esconde três pormenores que decidem, na prática, quão seguro é cada modo.

Primeiro, as chamadas da allowlist não passam pela sandbox. A documentação dos modos de execução do Cursor é explícita: as chamadas de shell, Fetch e MCP que estão na allowlist correm fora dela. Uma entrada abrangente como npx, zsh ou até find dá ao agente permissões totais para tudo o que comece por ela. A própria equipa do Cursor usou esses três exemplos quando explicou por que razão construiu a sandbox em vez de uma allowlist mais granular.

Segundo, o classificador é um modelo a julgar outro modelo. No Auto-review, o Cursor envia tudo o que não está na allowlist nem cabe na sandbox para um classificador (o Cursor indica o Gemini 3.5 Flash Lite, com o Haiku como alternativa). Segundo a empresa, o classificador bloqueia cerca de 4 % das ações. A documentação acrescenta duas frases que convém ter presentes: "o Auto-review não é uma fronteira de segurança" e "o classificador pode cometer erros".

Terceiro, o Ask Every Time ainda existe para alguns utilizadores. Os novos utilizadores não o podem escolher desde a 3.5; o equivalente é o Allowlist com a lista vazia. Quem o tinha mantém-no, e a equipa do Cursor ainda o recomendava em outubro de 2026, depois de um disco apagado.

Como se ativa hoje o YOLO mode no Cursor?

Para ativar o YOLO mode no Cursor, abre Settings > Agents > Approvals & Execution e escolhe Run Everything. É esse o comportamento YOLO: sem pedidos de aprovação, sem sandbox, sem classificador. Se a opção não aparecer, é provável que um administrador da equipa a tenha desativado (os administradores Enterprise podem esconder o Run Everything e bloquear o modo), ou então a tua versão do Cursor é anterior aos modos atuais.

Na CLI do Cursor, --yolo (alias --force) e o comando /auto-run ligam o Run Everything; desde fevereiro de 2026, --yolo aprova automaticamente "de forma consistente nas aprovações de confiança, de MCP e de comandos". Já --auto-review e /auto-review selecionam o Auto-review.

Lê as duas secções seguintes antes de o ligares: as proteções que parecem relevantes para o Run Everything cobrem menos do que os nomes sugerem.

O que bloqueia realmente a sandbox do Cursor?

Em macOS e Linux, a sandbox do Cursor limita as escritas dos comandos de shell ao workspace e bloqueia o acesso à rede, exceto aos domínios que as tuas definições permitem. Protege contra escrita ficheiros como .git/hooks e .cursor/*.json. Por omissão não limita as leituras, e os comandos da allowlist nem sequer passam por ela. No Windows nativo, as shells continuam sem sandbox em outubro de 2026.

A sandbox é aplicada pelo sistema operativo, não pelo modelo, e é por isso que aguenta quando o agente está a ser manipulado. Em macOS, o Cursor usa o Seatbelt através de sandbox-exec. Em Linux usa Landlock e seccomp, e precisa do kernel 6.2 ou posterior com user namespaces sem privilégios; num kernel mais antigo, o Cursor passa a pedir aprovação antes de cada comando. No Windows nativo, a equipa do Cursor declarou em julho, e de novo em outubro de 2026, que os comandos de terminal não correm numa sandbox; o caminho documentado é o WSL2 ou um dev container.

O que um comando na sandbox pode e não pode fazer, com as predefinições do Cursor:

• Escritas: apenas dentro do workspace. Alguns caminhos continuam protegidos contra escrita mesmo aí: .cursor/*.json, .git/hooks/, .git/config, .vscode/ e .cursorignore.
• Rede: bloqueada, depois aberta conforme a tua definição de rede. A definição predefinida acrescenta a lista de domínios de desenvolvimento do Cursor, que inclui github.com, *.googleapis.com e registry.npmjs.org. Os endereços privados e o endpoint de metadados da cloud continuam bloqueados.
• Leituras: a fronteira de leitura predefinida é o sistema inteiro, e a referência do Cursor indica que, com ela, ~/.ssh fica "sempre legível". Só desde a 3.23 podes definir a fronteira como o workspace.
• Ficheiros temporários: /tmp e as pastas temporárias da plataforma são graváveis, a não ser que desligues essa opção.

E três maneiras de sair dela, todas documentadas:

1. A allowlist, como vimos: as chamadas da allowlist nunca entram na sandbox.
2. A nova tentativa. Quando um comando falha por causa de uma restrição da sandbox, o agente pode voltar a corrê-lo fora dela. No Auto-review, é o classificador que revê essa nova tentativa; nos outros modos, é a ti que o Cursor pergunta.
3. A configuração do próprio repositório. O .cursor/sandbox.json de um projeto tem prioridade sobre o teu, e "type": "insecure_none" desativa a sandbox por completo. As políticas dos administradores da equipa não podem ser enfraquecidas por ficheiros locais, mas um programador a solo não tem administrador.

A sandbox também já teve fugas reais, todas corrigidas: escrever git hooks para correr código fora dela (CVE-2026-26268, corrigida na 2.5), um diretório de trabalho e symlinks que apontavam para fora do workspace (CVE-2026-50548 e CVE-2026-50549, corrigidas na 3.0), e um wrapper de virtualenv Python executado por uma extensão do editor (CVE-2026-73217, corrigida na 3.1.2). Mantém o Cursor atualizado. O nosso guia sobre fugas à sandbox em agentes de código descreve o padrão em várias ferramentas.

O modo Run Everything (YOLO) do Cursor é seguro?

Numa máquina que te faça falta, não. O Run Everything não tem sandbox nem classificador, por isso o agente age com a tua identidade, os teus tokens e os teus ficheiros, e a única coisa entre um comando errado e o seu efeito é o modelo decidir não o correr. O fórum do Cursor reúne relatos de discos inteiros apagados neste modo em outubro de 2026. É razoável numa máquina que possas deitar fora, e arriscado em qualquer outro sítio.

O próprio fórum do Cursor mostra o que isso dá na prática. Entre março e outubro de 2026, pelo menos seis utilizadores de Windows relataram ter perdido um disco ou a maior parte dos ficheiros por causa de um comando do agente, vários deles com o mesmo padrão: um cmd /c "rmdir /s /q ..." cujas aspas falharam, de modo que o caminho ficou reduzido à raiz do disco. A equipa do Cursor disse que correspondia a "um problema que já estamos a acompanhar". Dois desses relatos chegaram na mesma semana de outubro de 2026: a 13 de outubro, um utilizador perdeu um disco em modo Auto-review, e a equipa respondeu que o Auto-review "devia ter parado um comando recursivo como esse e perguntado primeiro"; a 17 de outubro, um utilizador perdeu um disco de 1 TB em modo Run Everything, no qual, nas palavras da equipa, "todas as chamadas de ferramentas correm automaticamente, sem aprovação, sandbox nem classificador". Em abril de 2026, o The Register noticiou que um agente do Cursor apagou a base de dados de produção de uma startup e as respetivas cópias de segurança, ao chamar uma API de alojamento com um token que encontrou num ficheiro sem relação com a tarefa. O artigo não diz que modo de execução estava ligado.

Duas proteções que parecem feitas para estes casos, e que não ajudaram:

• A File-Deletion Protection cobre a ferramenta de eliminação de ficheiros do próprio agente. A equipa confirmou em outubro de 2026 que não se aplica "a comandos de terminal como rd ou rmdir". As eliminações feitas a partir do terminal também "NÃO estão cobertas pelos checkpoints do Cursor nem pelo histórico local", por isso não há forma de as desfazer.
• A External-File Protection impede o agente de criar ou alterar ficheiros fora do workspace através das suas ferramentas de ficheiros. Segundo o Cursor, "não bloqueia a leitura de ficheiros fora do workspace", e não controla o que faz um comando de terminal.

O Cursor tem vindo a apertar as regras: desde agosto de 2026, o Auto-review bloqueia as eliminações recursivas e forçadas em vez de as correr automaticamente, e a CLI de 8 de outubro de 2026 pergunta antes de eliminações "cujo alvo possa resolver-se de forma diferente do que está escrito". O relato de 13 de outubro mostra por que razão a documentação apresenta isto como best-effort, sem garantia.

Os nossos próprios dados sobre agentes sem guarda apontam no mesmo sentido. No nosso estudo anterior, em que os agentes construíam uma plataforma sobre uma base de dados aplicacional em funcionamento, duas configurações sem guarda executaram DROP SCHEMA nessa base dezoito vezes no total.

6+

discos ou pastas de Windows apagados por um agente do Cursor, relatados no fórum de março a outubro de 2026

4 %

percentagem das ações que, segundo o Cursor, o classificador do Auto-review bloqueia

18

execuções de DROP SCHEMA numa base de dados em funcionamento, por agentes sem guarda, no nosso estudo anterior

Por que razão a allowlist não é uma fronteira de segurança?

A allowlist verifica o texto de um comando, e o mesmo comando pode escrever-se de muitas maneiras. A documentação do Cursor di-lo sem rodeios: "A allowlist é um mecanismo best-effort, não uma fronteira de segurança. Agentes determinados ou uma prompt injection podem contorná-la." Eis como funciona hoje a correspondência:

• As entradas são prefixos e distinguem maiúsculas de minúsculas: git corresponde a git status, mas não a gitk. npm:install* separa o comando de um padrão de argumentos. Não há regex.
• Uma cadeia é verificada comando a comando: cd api && npm test | tail -20 só corre sozinho se cd, npm e tail estiverem, cada um, na lista.
• Os comandos da allowlist correm fora da sandbox, por isso uma única entrada abrangente desfaz a sandbox para tudo aquilo de que é prefixo.

O historial de contornos é longo e público. Na era do YOLO, os comandos encadeados escapavam às duas listas, e foi por isso que o Cursor abandonou a denylist na 1.3. Desde então, o Cursor publicou avisos de segurança para um contorno da allowlist através de backticks e de $(...) (CVE-2025-54131), para built-ins da shell que corriam sem aparecer na lista (CVE-2026-22708) e para execução de comandos em "Use AllowList" através de prompt injection vinda de um site (CVE-2026-31854). Em agosto de 2026, um utilizador mostrou duas formas de PowerShell que corriam sozinhas comandos arbitrários por trás de uma entrada da allowlist; a equipa do Cursor encaminhou-as internamente e, no fim de setembro, disse que os blocos de script passaram a pedir sempre aprovação.

Por que razão o auto-run do Cursor ou a minha allowlist não funcionam?

Se o Cursor continua a pedir aprovação ou parece ignorar a tua allowlist, a causa costuma ser uma destas:

• Uma terminalAllowlist não vazia em ~/.cursor/permissions.json fixa o modo em Allowlist e torna o Auto-review indisponível (equipa do Cursor, agosto de 2026).
• Um comando encadeado só corre sem pedido de aprovação se cada comando que o compõe estiver na lista.
• Em Linux, a sandbox precisa do kernel 6.2 ou posterior com user namespaces sem privilégios. Sem isso, o Cursor pede aprovação antes de cada comando.
• Um administrador da equipa bloqueou o modo de execução ou escondeu o Run Everything.
• No antigo modo Run in Sandbox, a allowlist nem sequer era aplicada, porque, segundo o Cursor, "a sandbox foi pensada para substituir a allowlist".

O .cursorignore protege o .env no Cursor?

Só em parte: um comando de terminal executado fora da sandbox pode continuar a fazer cat .env. O .cursorignore esconde ficheiros das ferramentas de ficheiros do agente, do Tab e das menções @, e a lista de exclusões predefinida do Cursor já inclui .env*. Mas a documentação é direta quanto ao resto: "As ferramentas de terminal e de servidor MCP usadas pelo Agent não conseguem bloquear o acesso a código abrangido pelo .cursorignore." Dentro da sandbox, os ficheiros listados no .cursorignore ficam ilegíveis, por isso acrescenta tu próprio .env* a esse ficheiro em vez de contares com a lista predefinida. Fora da sandbox, ou seja, no Run Everything, nos comandos da allowlist, nas saídas aprovadas e no Windows nativo, cat .env funciona.

Se um ficheiro não pode, em caso algum, chegar ao modelo, mantém-no fora do workspace ou trava a própria leitura, que é o que fazem as duas secções seguintes. Para a mesma pergunta no Claude Code, vê o que o Claude Code envia à Anthropic.

Que modo de execução do Cursor deves usar?

Hoje, numa máquina de desenvolvimento, esta é a configuração que usaríamos:

1. macOS ou Linux: Auto-review com a sandbox ligada. Limita a allowlist a comandos só de leitura (git status, git diff, ls) e define-a na interface das definições em vez de a pores no permissions.json, se quiseres que o Auto-review continue disponível.
2. Fecha as leituras e a rede em ~/.cursor/sandbox.json (a fronteira de leitura exige o Cursor 3.23 ou posterior), e escolhe a definição de rede que usa apenas o sandbox.json se não quiseres os domínios predefinidos do Cursor:

{
  "readBoundary": "workspace",
  "networkPolicy": {
    "default": "deny",
    "allow": ["registry.npmjs.org", "pypi.org", "files.pythonhosted.org"]
  }
}

Se uma toolchain precisar de um ficheiro fora do projeto, acrescenta-o a additionalReadPaths em vez de voltares a abrir o sistema inteiro. 3. Windows nativo: Allowlist com a lista vazia, ou passa o projeto para o WSL2 ou para um dev container, onde a sandbox existe. 4. Equipas: impõe a configuração de forma centralizada. O próprio guia de hardening do Cursor recomenda definir o modo de execução da organização "como Auto-review (não Run Everything)", com a sandbox ativada, e distribuir os hooks a partir do dashboard. Atenção: nos grupos da organização, prevalece a definição de sandbox mais permissiva. 5. Run Everything só onde a máquina é descartável:

Contentor ou VM novos, clone descartávelNenhum token de longa duração nem credenciais cloud lá dentroSaída de rede limitada aos registries de que precisasEntão, e só então, Run Everything

Os Cloud Agents do Cursor já seguem este modelo: cada um corre na sua própria microVM e nunca pede aprovação, com o acesso à internet ligado por omissão, a não ser que o restrinjas.

Os hooks do Cursor continuam a correr no modo Run Everything?

Sim, e é isso que faz deles o único controlo que sobrevive a todos os modos de execução. Um hook é um script que o Cursor chama antes de uma ação; pode responder deny, e a ação não corre. Questionada a 17 de outubro de 2026 sobre como proteger uma configuração Run Everything contra eliminações recursivas, a equipa do Cursor respondeu: "A principal salvaguarda aí é o hook."

Eis um hook mínimo ao nível do utilizador que recusa eliminações recursivas em todas as shells que o Cursor usa. Em ~/.cursor/hooks.json:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      { "command": "node ./hooks/block-recursive-delete.mjs", "timeout": 5, "failClosed": true }
    ]
  }
}

E ~/.cursor/hooks/block-recursive-delete.mjs (os caminhos dos hooks de utilizador resolvem-se a partir de ~/.cursor/):

let raw = "";
for await (const chunk of process.stdin) raw += chunk;
const { command = "" } = JSON.parse(raw || "{}");

const RECURSIVE_DELETE = [
  /\brm\s+(-[a-zA-Z]*[rR][a-zA-Z]*|--recursive)\b/, // rm -rf, rm -r, rm --recursive
  /\b(rmdir|rd)\s+\/s\b/i,                         // cmd: rmdir /s, rd /s
  /\bdel\s+(\/\w\s+)*\/s\b/i,                      // cmd: del /s
  /\bRemove-Item\b[^|;&]*-Recurse\b/i,             // PowerShell
];

if (RECURSIVE_DELETE.some((re) => re.test(command))) {
  console.log(JSON.stringify({
    permission: "deny",
    user_message: `Blocked a recursive delete: ${command}`,
    agent_message: "Recursive deletes are blocked on this machine. Delete files by explicit path, or ask the user to run the command.",
  }));
} else {
  console.log(JSON.stringify({ permission: "allow" }));
}

Três limites a conhecer antes de confiares nele, todos indicados pela equipa do Cursor:

• Só o deny é aplicado. Em março de 2026, a equipa escreveu que "os hooks só aplicam a permissão deny. Tanto allow como ask são basicamente ignorados." É por isso que o script responde allow a tudo o resto: deixa a decisão ao teu modo de execução. Não contes com o ask para fazer voltar um pedido de aprovação.
• Uma race condition conhecida pode fazer perder um deny. Em julho de 2026, a equipa confirmou que, por causa de uma race condition, um hook preToolUse que devolve deny pode não ser respeitado e o comando corre na mesma. E acrescentou: "por favor, não dependam apenas de um hook deny como bloqueio absoluto." Em setembro, o problema continuava em aberto.
• Os hooks não veem o modo de execução. O script não pode tornar-se mais restritivo só em Run Everything.

E um limite do próprio método: um padrão é um alarme, não uma fronteira. Apanha as formas que escreveste, falha uma eliminação escondida num ficheiro de script ou escrita de outra maneira, e também dispara com comandos inofensivos: testámo-lo com um conjunto de comandos de exemplo e recusou rm -rf node_modules e git rm -r --cached juntamente com as verdadeiras eliminações em massa. Mantém a sandbox por baixo.

A brecha que nenhum modo de execução fecha

Todas as definições deste guia controlam o que o Cursor pode executar. Nenhuma controla o que o Cursor escreve, e a maior parte do risco do código escrito por IA está no diff, não no terminal. O Auto-review deixa o agente guardar, sem pestanejar, um endpoint sem verificação de autorização, um handler de reembolsos sem limite ou uma query construída por concatenação de strings, porque nenhum deles é um comando. São falhas de lógica de negócio, e uma definição de terminal não as consegue ver. Os agentes também começam cada sessão sem as regras da tua equipa, a não ser que alguma coisa lhas ponha à frente no momento em que escrevem.

É essa a camada que o VibeDefend acrescenta dentro do Cursor. Um único comando instala-o na máquina: serve as tuas regras de negócio e de segurança ao agente enquanto ele escreve, verifica o diff antes do commit e corre os seus guardas como um hook do Cursor antes de cada chamada de ferramenta, seja qual for o modo de execução. Por omissão, os guardas recusam leituras de ficheiros .env, de chaves SSH e de credenciais cloud, rm -rf na raiz ou na pasta pessoal, force-pushes, instruções DROP e downloads encaminhados para uma shell. O guarda é o mesmo tipo de alarme que o hook acima, mantido para ti, com os mesmos limites: no nosso estudo controlado de 24 de agosto de 2026, verificou 1 769 comandos de shell e recusou dezassete (um caso real, três aplicações corretas da política e treze falsos positivos). No próprio código, a configuração com a camada implementou à letra 57 de 64 detalhes de regra avaliados (89 %), contra 7 de 55 (13 %) com um ficheiro de regras mantido à mão e 8 de 65 (12 %) sem nada.

Se corres o Cursor em Run Everything de propósito, num contentor, com um guarda no hook, tens uma configuração defensável. Se o corres assim no teu portátil porque os pedidos de aprovação te irritavam, lê o nosso guia de segurança do Cursor, compara com o que o --yolo do Codex retira e com o --dangerously-skip-permissions do Claude Code, e depois fala connosco.

Perguntas frequentes

O YOLO mode desapareceu do Cursor?

Não. O YOLO mode passou a chamar-se Auto-run em março de 2025. O seu comportamento de "correr tudo sem perguntar" é hoje o modo Run Everything, em Settings > Agents > Approvals & Execution. Desde o Cursor 3.6, o modo predefinido é o Auto-review.

Como ativar o YOLO mode no Cursor?

Abre Settings > Agents > Approvals & Execution e escolhe Run Everything. Na CLI do Cursor, usa --yolo (alias --force) ou /auto-run. Se a opção não aparecer, é provável que um administrador da equipa a tenha desativado, ou então a tua versão do Cursor é anterior aos modos atuais.

O que é o Auto-review do Cursor?

O Auto-review é o modo de execução predefinido do Cursor desde a versão 3.6 (29 de maio de 2026). As chamadas da allowlist correm de imediato, os comandos de shell que podem ir para a sandbox correm lá dentro, e um modelo classificador decide o resto: permite, redireciona ou pergunta-te. Abrange as chamadas de shell, MCP e Fetch. A documentação do Cursor diz que não é uma fronteira de segurança.

Qual é a diferença entre Auto-review e Run Everything?

O Auto-review corre as chamadas da allowlist, corre os comandos de shell na sandbox sempre que pode e envia tudo o resto para um modelo classificador, que pode permiti-lo, sugerir outra abordagem ou perguntar-te. O Run Everything corre todas as chamadas de ferramentas sem sandbox e sem classificador.

É seguro usar o Run Everything?

Só numa máquina descartável: um contentor ou uma VM novos, sem credenciais de longa duração e com a rede limitada. Num posto de trabalho, deixa o agente agir com a tua identidade, e o fórum do Cursor tem relatos de discos inteiros apagados neste modo em outubro de 2026.

O que bloqueia a sandbox do Cursor?

Em macOS e Linux, limita as escritas dos comandos de shell ao workspace, bloqueia a rede exceto para os domínios que as tuas definições permitem e protege ficheiros como .cursor/*.json e .git/hooks. Por omissão, não restringe as leituras fora do workspace; o Cursor 3.23 acrescentou uma fronteira de leitura Workspace. No Windows nativo, as shells continuam sem sandbox em outubro de 2026.

Porque é que o Cursor ignora a minha allowlist ou o auto-run não funciona?

As causas mais comuns: uma terminalAllowlist não vazia em ~/.cursor/permissions.json fixa o modo em Allowlist e desativa o Auto-review; um comando encadeado só corre sozinho se cada comando que o compõe estiver na allowlist; em Linux, um kernel anterior ao 6.2, ou que não permita user namespaces sem privilégios, faz o Cursor pedir aprovação antes de cada comando; e no antigo modo Run in Sandbox a allowlist nem sequer era aplicada.

O auto-run também vale para as ferramentas MCP?

Sim. As chamadas de ferramentas MCP seguem os mesmos modos de execução que os comandos de terminal. No Auto-review, as ferramentas MCP da allowlist (entradas server:tool, com wildcards permitidos) correm de imediato e as restantes vão para o classificador. No Run Everything, correm todas.

O .cursorignore impede o Cursor de ler o meu ficheiro .env?

A partir do terminal, não. O .cursorignore esconde ficheiros das ferramentas de ficheiros do agente e das menções, e o .env* está na lista de exclusões predefinida do Cursor, mas a documentação do Cursor afirma que as ferramentas de terminal e MCP não conseguem bloquear o acesso a ficheiros ignorados. Um comando na sandbox não consegue ler os ficheiros listados no .cursorignore; um comando da allowlist, o Run Everything ou uma shell do Windows nativo conseguem.